Skip to main content

Go-Live Checklist

Contract and version​

  • Test standard Order creation and Create an Order with Rates.
  • Verify standard and create-and-rate single-order paths; each is not batch processing.
  • Confirm Create an Order with Rates uses a wrapped order body and creates one Order per request.

Credentials​

  • Store credentials server-side and redact them from logs. (Client best practice.)
  • Test the bounded refresh/re-authentication path.
  • Switch from your Sandbox key to your Production key and exchange it for a new token. See Move to Production.
  • Point MAILHUB_API_BASE_URL at https://api.mailhub.com, and confirm no Sandbox base URL survives in any deployed configuration.
  • Re-request Rates in Production rather than carrying a Sandbox result across.

Account/Sub-account scope​

  • Review the complete 12-operation Sub-account matrix.
  • Keep selected scope explicit; do not treat the header as authorization.

Request validation​

  • Validate inputs against the current API Reference.
  • Correct validation failures before sending a changed request.

Order creation flows​

  • Confirm standard Order creation without rating.
  • Confirm Create an Order with Rates creates one Order with Rates, not multiple Orders.
  • Understand that a create-and-rate no-Rate 422 may follow persisted Order creation.

Rate selection​

  • Select a returned rate.id in application logic; do not infer ranking or availability guarantees.

Label purchase​

  • Retain postageLabel.id from a successful purchase response — not the root data.id.
  • Handle 202 as still running: read the Order for labelId and LabelCreated, rather than treating it as a failure.
  • After an ambiguous outcome, repeat only the same purchase request; it replays instead of buying a second Label. Changing the request while a purchase is active returns 409. See Buy a Label.
  • Handle the two bounded exceptions: a Label cancelled before its result reached you is not replaced by a repeat, and an unresolved carrier outcome refuses a new purchase until it settles.

Binary download​

  • Handle 200 as binary and branch on actual Content-Type.
  • Handle 202 as pending/still generating, and wait for the Retry-After value that response gives instead of an interval of your own.

Cancellation​

  • Treat cancellation timeout/lost-response outcomes as ambiguous.
  • Do not assume refund, provider confirmation, or universal repeat safety.

Timeouts and retries​

  • Set finite timeout and retry budgets. (Client best practice.)
  • Keep V1/V2 Order creation and Label cancellation out of blind-repeat paths.
  • Treat Label purchase as the one documented exception, and only for an unchanged request. See Retries and Ambiguous Outcomes.

Logging and security​

  • Record sanitized route/status/identifier context; redact secrets and binary bodies. (Client best practice.)
  • Generate internal diagnostic identifiers without expecting a Mailhub correlation header.

Postman and release review​

Unsupported-capability review​

  • Do not assume tracking, webhooks, SDKs, public reconciliation, or a safe live Label test environment.

Next steps​