Go live

Move from the free trial to sending production traffic to real customers. Going live removes the trial limits, allowing you to send from your own sender to any recipient. You pay for the messages you send. These steps apply to both self-signup and managed accounts. If you have a managed account, you complete the steps yourself, with guidance and support from your Customer Success Managers and Solutions Engineers.

The steps assume you have already sent a working test message. If you have not, start with Send your first message. Follow these steps in order.

Choose your account structure

Decide how to organize your senders, API keys, and customers before you register senders and create production API keys. Changing the account structure is harder once production traffic is running. For a comparison of the options, see Account types and structures.

Choose the structure that fits how you work:

• One brand or business: Keep everything in one account. This is the default and needs no setup.
• Many customers that you serve through the API, for example as an agency or a platform: Use a multi-tenant setup (CPaaS X). You set it up yourself on a main account. You then onboard and manage each customer in the web interface or through the API, with one login.

You might use AgentOS products for several customers or brands, or each brand might need a separate account. In that case, contact your account manager to choose a setup. On a self-signup account, contact Support.

Move to a paying account

On a self-signup account, upgrade to a paying account by adding funds to your balance. Adding funds ends the free trial for your whole account.

On a managed account, agree on payment terms with your account manager, who then switches each channel to a paying account. Your account can be prepaid or postpaid. For both account types, see Continue after the trial.

Get your own sender

The free trial uses a shared test sender. For production, you need your own sender. To get one:

1. Get a sender. The sender type depends on the channel and country. It can be a phone number, an alphanumeric sender ID, an email domain, or a channel-specific sender. For how senders and registration fit together, see You send from a resource.
2. Complete any required registration. Many countries require sender registration and approval before you send. Requirements vary by channel and country. For SMS, see the rules for each country in SMS coverage and connectivity. For the US, see US sender registration for 10DLC, toll-free, and short codes. For other channels, see the compliance documentation for the channel.
3. Switch to your own sender. Before you send production traffic, confirm that your own sender is active. Then update your integration or your Broadcast campaigns to send from it.

Secure your account and API access

Before sending production traffic, secure access to your account. In Security settings, configure password and user inactivity rules. If your organization uses an identity provider, set up SSO as well. If enabled for your account, you can also require 2FA at every login. To restrict access to specific IP addresses, see IP safelisting.

If you send messages only through the web interface, skip the rest of this step. Otherwise, make sure your integration uses an API key with only the scopes it needs and the correct base URL. Store the API key as a secret, and keep it out of client-side code and version control. You can secure your integration further, for example, by using TLS encryption or restricting an API key to specific IP addresses.

Track delivery and handle failures

A successful send response means the message was accepted, not delivered. If you send only from the web interface, check the status of each message in Message logs.

If you send through the API, set up a webhook to receive delivery reports. To receive them for every message on a channel, use a webhook subscription. Make sure your integration handles intermediate and final statuses differently. When a message fails, the delivery report includes an error code and shows whether the error is permanent. Resend only when the error is not permanent.

Retry carefully. A send request might time out or return a server error. The message might already be accepted, and a retry can deliver it twice. Before you retry, check Message logs or wait for the delivery report.

Honor opt-outs and consent

Production messaging has compliance requirements beyond sender registration. Honor opt-outs, such as STOP replies, respect consent, and follow regional rules for content and timing. To stop sending to recipients who opt out, use the Blocklist. Rules vary by channel and country, so check the documentation for each channel you use.

Check the flooding filter and rate limits

Two kinds of limits can reject legitimate production traffic if your integration is not ready for them:

• Flooding filter (DCL): On by default. It rejects repeated identical or high-volume traffic to the same destination.
• Rate limits and throughput: API rate limits and channel throughput limit how fast you can send. The registration tier of a channel can also affect throughput, for example 10DLC throughput.

Start small and monitor delivery

Send a small share of production traffic first. Confirm that senders, delivery reports, and limits work as expected, then increase traffic step by step. This finds sender, throughput, or compliance issues before they affect all your customers. As traffic grows, follow delivery trends in dashboards and reports.