Move to Production

The switch itself is small: different credentials, a different base URL, a new token. What takes care is everything you learned in Sandbox that should not travel with you.

Before you switch

Confirm your integration handles the contract, not one environment's results:

• You call the public operations as documented in the API Reference.
• You handle the Label purchase 200 / 202 outcomes and the 409 refusal.
• You read the Order after an ambiguous purchase outcome instead of guessing.
• You treat a lost Label cancellation response as ambiguous rather than repeating it.
• You keep credentials and tokens server-side.

Change credentials

Use your Production API key — the one beginning mh_live_ — in place of your Sandbox key.

Do not assume a Sandbox credential works in Production. The two keys are separate credentials with separate lifecycles, and each belongs to the API it was issued for.

Change the API base URL

Point your integration at the Production API base URL provided by Mailhub, through the same MAILHUB_API_BASE_URL configuration you already use. Nothing in your request-building code should need to change.

Re-authenticate

Exchange the Production API key for a new access token. Tokens are issued per environment: a Sandbox access token or refresh token has no meaning against Production, so start the token lifecycle fresh — see Authentication and Token Lifecycle.

Re-check carrier availability and rates

• Do not assume carrier availability is identical. Which carriers are on offer depends on your account's carrier configuration, and that is something to confirm rather than infer from a Sandbox result. See Carrier Availability.
• Do not reuse a Sandbox Rate as a Production quote. Request Rates again in Production and select from what comes back.
• Do not assume data created in Sandbox is available in Production. Build your Production validation on Orders and Shipments you create there.

Re-run your production validation

What carries over is the contract, not the results

The documented public API contract is the same in both environments: the same 12 public operations, the same request and response shapes, the same Label purchase 200 / 202 / replay / 409 contract, the same Label cancellation contract, the same Label download contract, and the same X-SubAccount-Id semantics. That is a statement about the documented contract — it is not a promise of identical runtime results, carriers, prices, provider environments, or billing.

Run your integration against the same twelve public operations in Production and confirm the outcomes there before you launch. The Go-Live Checklist is the authoritative list of what to verify, and Production Readiness covers the reliability boundaries your application owns.