SMS and MMS API Readiness

Before a number can send application-to-person SMS or MMS reliably, three things must be true: the number is on your account, SMS is enabled for the number, and the number is assigned to the correct approved 10DLC campaign. For API-based integrations, your API key must also carry the right messaging scopes for the messaging APIs enabled on your account.

Voice routing does not make a number ready for messaging. A number can be fully working for calls and still be unable to send A2P messages until SMS and campaign registration are complete.

Readiness Checklist

Use this checklist before launching a messaging integration:

1. The sending number is assigned to your WARP account.
2. SMS is enabled on the number.
3. Your Brand is registered.
4. Your Campaign is created, accurate, and approved.
5. The sending number is assigned to that Campaign.
6. Your message content matches the Campaign use case and sample messages.
7. Your recipient consent, opt-out, and help flows are working.
8. Your API key includes the scopes needed to send and read message status.

If any item is missing, fix that before treating delivery problems as an outage.

API Key Scopes

For a sending integration, use least privilege. Give the key only the scopes it needs.

Common scope patterns:

• messaging:send for message-sending APIs when enabled on your account.
• messaging:read for message status or history APIs when enabled on your account.
• messaging:campaigns:read to inspect Brand, Campaign, and number assignment state.
• numbers:read to verify number ownership and SMS readiness.

Avoid granting write scopes to an API key unless the integration truly needs to change configuration. If the key only sends and checks status, it should not need numbers:write or messaging:campaigns:write.

Campaign Assignment

Assign each SMS-enabled number to the Campaign that matches the messages it sends. A number should not be reused for unrelated traffic. For example, do not use a two-factor authentication campaign to send marketing messages.

If your business has multiple message types, create the right campaigns and assign numbers intentionally. This protects deliverability and keeps your registrations accurate.

Consent and Recipient Commands

Your system must collect opt-in before sending. It must also honor opt-out requests, usually STOP, and provide help responses, usually HELP.

Consent is not just a registration field. It must match what your product actually does. If your live traffic ignores opt-outs or sends content outside the registered use case, carriers can filter or block it even if the campaign was initially approved.

Troubleshooting Blocked or Failed Messages

Start with readiness, not code:

• Confirm the number is assigned to your account.
• Confirm SMS is enabled on the number.
• Confirm the campaign is approved.
• Confirm the number is assigned to that campaign.
• Confirm the API key has the messaging scopes required for the API you are using.
• Confirm your traffic matches the registered use case and sample messages.
• Confirm recipients opted in and opt-outs are honored.

If all of those are true and delivery still fails, gather message IDs, timestamps, sending numbers, recipient numbers, and campaign ID before contacting support.

Scopes and API Reference

Messaging send and status scopes:

• messaging:send for send APIs enabled on your account.
• messaging:read for message status and history APIs enabled on your account.
• If you do not see a documented send or status endpoint for your account, confirm API availability with support before building the integration.

Number SMS readiness:

• numbers:read to inspect number state.
• numbers:write to update SMS enablement.
• PATCH /v1/numbers/:tn/sms
• DELETE /v1/numbers/:tn/sms

10DLC assignment:

• messaging:campaigns:read to inspect campaigns and assigned numbers.
• messaging:campaigns:write to assign or remove campaign numbers.
• GET /v1/messaging/campaigns/:id/numbers
• POST /v1/messaging/campaigns/:id/numbers
• DELETE /v1/messaging/campaigns/:id/numbers