The core expectation
When you send messages through Surge, carriers ask: whose brand is behind this message? The brand registered on the account must match the brand the message recipient expects to see as the sender. Every number should be registered to the business from which the end customer thinks they’re receiving a message. If the message is presented as coming from your platform, and the recipient opted in to messages from your platform, a single platform account can be the right fit. If the message is presented as coming from one of your customers, that customer’s business needs its own account, campaign, and number. For example, imagine a communication platform for dental offices called “DentalSoft” with customers like “ABC Dental” and “XYZ Dental.” DentalSoft could use one DentalSoft account for payment receipts or appointment reminders that clearly identify DentalSoft as the sender and rely on patient opt-in to DentalSoft. But if a patient opted in to messages from ABC Dental, or reasonably believes ABC Dental is messaging them directly, that number should be registered to ABC Dental. XYZ Dental would need its own account for the same reason.Why separate accounts matter
Compliance partitioning. If one of your customers gets flagged for spam, whether it’s a rogue employee or a misunderstanding, only their account is affected. Their campaign suspension doesn’t touch your other customers. A single shared account means a flag on one customer’s campaign can take down messaging for every customer. Cost attribution. Each account bills independently, so you can pass usage costs through to your customers without building a message-counting system on your end. Surge’s usage reports are already broken down by account. Scaling isolation. A customer with a sudden volume spike doesn’t consume rate-limit headroom for your other customers. Message delivery, error rates, and carrier relationships are isolated per account.The biggest gotcha
How to implement the pattern
1
Create an account when a customer signs up
Call Save
POST /accounts with the customer’s business name. Store the returned id alongside their record in your database — every subsequent call uses it.acct_01jrzhe8d9enptypyx360pcmxl against your customer’s row.2
Submit business information
Collect EIN, website, address, and authorized representative from the customer, then submit via
PATCH /accounts/{account_id}. Submit it all at once — partial submissions can’t enter review. See Register via API → Account fields for the full body shape.3
Create a campaign for their account
POST /accounts/{account_id}/campaigns with their use case, opt-in flow, and sample messages. The campaign reflects their brand, not yours. See Schema Reference → Campaign fields for required values.4
Purchase and attach a phone number
POST /accounts/{account_id}/phone_numbers. Once the campaign reaches active, Surge auto-attaches the number — see Attaching numbers.5
Send messages on their behalf
Use the customer’s account ID in the path. The platform API key authorizes the call:See POST /messages for the full request and response shapes.
You don’t need separate API keys per customer. One project-level API key authorizes every account in your project.
Checking registration status programmatically
When you create an account for a customer, you may not have all their business information up front. The status endpoint lets you check what’s still needed:fields_needed array tells you exactly what to collect before you can submit a campaign. Build this check into your onboarding flow so customers see a guided setup experience rather than a registration failure.