Going live
Going live is a deliberate switch, not a flag flip. Everything you built in sandbox stays the same; you add the live resources the virtual path did not need, then swap the key.
-
Prove the loop in sandbox. Send → follow the webhook to a terminal state → reconcile against the wallet, all with a
sk_test_key. Handle failures, duplicate events, and timeouts. -
Register live sender IDs. For each country you send SMS to (
GH,NG), register a sender ID and wait for it to becomeactive. Approval is a manual carrier/regulator review with no fixed turnaround — start early. -
Verify live email domains. Publish SPF, DKIM, and DMARC and verify the domain before using a live
from— see Domains & DNS. -
Fund the wallet in the correct currency. Live sends fail closed when funds cannot be reserved.
-
Create a live webhook endpoint and store its signing secret in your secret manager. Live and sandbox endpoints are separate.
-
Confirm consent handling. Ensure your promotional audience opted in, and that your transactional and promotional traffic use the right message class.
-
Swap the key. Replace
sk_test_withsk_live_in your server secret manager. The SDK picks up the live environment from the prefix — no code change. -
Do a controlled first send to a consenting recipient and reconcile the delivery, the terminal webhook, and the wallet ledger entry before you ramp volume.
What changes, what does not
Section titled “What changes, what does not”| Stays the same | Becomes required live |
|---|---|
| Your code, keys aside | A funded wallet in the right currency |
| Definitions and their keys | An active sender ID per country (SMS) |
| Idempotency and webhook logic | A verified sending domain (email) |
| Cost and rendering behaviour | Real consent and quiet-hours compliance |