Configuring webhooks
To receive notifications for brands you need to either provide the webhooks at the creation of the brand or you may update an existing brand. In both cases you have to pass your webhooks in the webhookURL and webhookFailoverURL. webhookFailoverURL is optional. Here is an example of updating the webhooks of a brand:Don’t forget to update
YOUR_API_KEY here.Types of events
Overall structure of events
Here is an example of a webhook event:
The
meta object contains delivery metadata:
Brand events
Here is a list of all TCR events under the TCR_BRAND_UPDATE type:
Here is an example of a REGISTRATION notification:
Campaign events
Here is a list of TCR events under the TCR_EVENT type:
Here is an example of a campaign REGISTRATION failure notification:
Note: The
campaignId field in webhooks contains the Telnyx UUID, not the TCR campaign ID. The TCR campaign ID (e.g., C6X6M95) may appear in the description field.Phone number events
Phone numbers in webhook payloads use E.164 format (e.g.,
+16715455939), which includes the country code prefix.The
status field in STATUS_UPDATE notifications can be: ADDED, DELETED, PENDING, or FAILED.Campaign Appeals and Nudging Mechanisms
When campaigns are rejected, there are different flows for getting them back into the compliance review queue depending on the campaign type and rejection reason.Native Campaign Appeals
For native campaigns rejected due to external factors (e.g., website compliance issues), customers can use the campaign appeal endpoint after addressing the issues: API Endpoint:TELNYX_FAILED to TCR_ACCEPTED and re-enter the compliance review queue.
Partner Campaign Nudging
For partner campaigns, the appeal process involves the CSP (Campaign Service Provider) sending aCAMPAIGN_NUDGE event after reviewing and approving customer changes:
CAMPAIGN_NUDGE Webhook Payload Example:
Note:
CAMPAIGN_NUDGE events originate from TCR and use the TCR campaign ID format (e.g., C4D06C2F) in the campaignId field, unlike other campaign webhooks which use the Telnyx UUID.Campaign Appeal Scenarios
There are several specific scenarios where campaign appeals may be needed:1. Native Campaign Rejected for Content Issues
When a customer submits a native campaign and Telnyx rejects it due to issues with the campaign content (e.g., unclear sample messages), the customer can make adjustments to their campaign. Using the campaign update endpoint will automatically reset the campaign’s status toTCR_ACCEPTED so it goes back into the compliance team’s review queue.
2. Native Campaign Rejected for External Factors
When a customer submits a native campaign and Telnyx rejects it due to factors outside the campaign object (e.g., website compliance requirements), the customer must:- Fix the external issues (e.g., update website with required privacy policy).
- Use the appeal API endpoint to get their campaign back in the review queue.
3. Partner Campaign Rejected (Any Reason)
For partner campaigns rejected for either content issues or external factors, the process involves the CSP:- Customer makes required adjustments based on rejection reasons.
- CSP reviews the changes and approves them.
- CSP forwards a
CAMPAIGN_NUDGEevent to Telnyx. - Campaign status changes from
TELNYX_FAILEDtoTCR_ACCEPTEDand re-enters compliance review.
This nudging mechanism for partner campaigns cannot work with native campaigns.
4. DCA Rejection for External Factors
When Telnyx accepts a campaign but the Direct Connect Aggregator (DCA) rejects it due to external factors:- Customer makes required external changes (e.g., website updates).
- Customer notifies Telnyx via appropriate appeal mechanism (scenarios 2 or 3).
- Once Telnyx approves the changes, Telnyx generates a nudge webhook that the DCA receives.
- Campaign re-enters DCA review queue.
5. DCA Rejection for Content Issues
When the DCA rejects a campaign due to campaign content issues:- Customer updates campaign content (e.g., sample messages).
- Customer notifies Telnyx via appropriate appeal mechanism (scenarios 1 or 3).
- Once Telnyx approves the changes, Telnyx generates a nudge webhook that the DCA receives.
- Campaign re-enters DCA review queue.
Campaign status flow
The following diagram shows the campaign lifecycle including both success and failure paths:Success path statuses
Failure and suspension statuses
Campaign appeal status flow
The typical status flow for campaign appeals is:- Initial rejection: Campaign status becomes
TELNYX_FAILED. - Customer action: Customer addresses the rejection reasons.
- Appeal submission:
- Native campaigns: Use appeal API endpoint or campaign update.
- Partner campaigns: CSP sends
CAMPAIGN_NUDGE.
- Re-review: Campaign status changes to
TCR_ACCEPTEDand re-enters compliance review.
The nudging mechanism for partner campaigns cannot be used with native campaigns. Native campaigns must use the direct appeal API endpoint or campaign update functionality.
Process webhooks with SDK examples
Handle 10DLC event notifications in your application to track registration status, respond to failures, and automate workflows:Important: Always return a
200 response immediately, then process the webhook asynchronously. For production applications, use a message queue (Redis, RabbitMQ, SQS) to decouple webhook receipt from processing.Webhook delivery
Retry policy
If your webhook endpoint returns a non-2xx HTTP status code or times out, Telnyx will retry delivery. Themeta.attempt field in the webhook payload indicates which delivery attempt this is (starting at 1).
- Default retry attempts: 5
- Default retry interval: 30 seconds between attempts
Best practices
- Return 2xx quickly: Return a 200 response as soon as possible, then process the webhook asynchronously.
- Handle duplicates: Webhooks may be delivered more than once. Use the
idfield to deduplicate. - Use HTTPS: Always use HTTPS endpoints to ensure webhook data is encrypted in transit.
- Verify the source: Consider implementing signature verification for added security.
- Set up failover: Configure a
webhookFailoverURLto receive webhooks if your primary endpoint is unavailable.
Testing webhooks locally
During development, you can use tunneling tools to expose your local server to the internet for webhook testing:- ngrok: Run
ngrok http 3000to create a public URL that forwards to your local port 3000. - Cloudflare Tunnel: Use
cloudflared tunnelfor a similar tunneling solution. - localtunnel: Run
lt --port 3000for a quick temporary URL.
Glossary
Related resources
10DLC Quickstart
Get started with 10DLC brand and campaign registration.
10DLC Rate Limits
Understand throughput limits based on vetting scores.
Receive Webhooks
Set up a server to receive webhook notifications.
Message Detail Records
Track delivery status and troubleshoot issues.