Skip to main content
Telnyx sends webhooks to notify your application about messaging events in real time — inbound messages, delivery status updates, and errors. This guide covers every event type, payload structure, signature verification, and best practices for production webhook handling.

Prerequisites

How webhook delivery works

1

An event occurs

A message is received by your number, or a sent message changes status (queued → sent → delivered).
2

Telnyx sends a POST request

An HTTP POST with a JSON payload is sent to your configured webhook URL.
3

Your server responds

Return a 2xx status code within 2 seconds to acknowledge receipt.
4

Failover and retries

If your server doesn’t respond in time, Telnyx retries (up to 3 attempts per URL) and then tries your failover URL if configured.

Webhook URL hierarchy

Telnyx determines where to send webhooks using this priority order:
  1. Per-message URLswebhook_url and webhook_failover_url in the send message request body
  2. Messaging profile URLs — Configured on the messaging profile
  3. No webhook — If neither is set, no webhook is delivered (events are still available in Message Detail Records)

Webhook event types

Telnyx messaging produces the following webhook events:

Payload structure

All messaging webhooks share this top-level structure:

Event examples

Inbound message (message.received)

Triggered when your Telnyx number receives an SMS or MMS:
MMS messages include a media array with URLs, content types, and file sizes:
MMS media links expire after 30 days. Download and store media files if you need long-term access.

Message sent (message.sent)

Triggered when an outbound message has been accepted by the downstream carrier:

Delivery receipt (message.finalized)

Triggered when a message reaches a terminal delivery state:

Delivery statuses

The to[].status field in message.finalized events indicates the final delivery outcome:
When a message fails, the errors array in the payload contains details:
Common error codes:For a complete list, see the Error Codes reference.

Webhook signature verification

Telnyx signs every webhook using Ed25519 public key cryptography so you can verify that requests genuinely come from Telnyx. This is strongly recommended for production deployments. Each webhook request includes two headers: The signature is computed over the string {timestamp}|{json_payload}.

Get your public key

Find your public key in the Mission Control Portal under Keys & Credentials → Public Key.

Verification examples

Timestamp tolerance: To prevent replay attacks, reject webhooks where telnyx-timestamp is more than 5 minutes old.

Handling webhooks in your application

Basic webhook handler


Retry behavior and error handling

Retry policy

Best practices for reliability

  1. Respond immediately — Return 200 before processing the event. Offload heavy logic to a background queue.
  2. Handle duplicates — Webhooks may be delivered more than once. Use the data.id field as an idempotency key.
  3. Handle out-of-order delivery — Events may arrive in a different order than they occurred. Use data.occurred_at timestamps to sequence events.
  4. Use HTTPS — Always use TLS-encrypted endpoints in production.
  5. Verify signatures — Validate telnyx-signature-ed25519 headers to prevent spoofing.

Webhook IP allowlist

If your server uses a firewall or ACL, allowlist the following Telnyx subnet:

Troubleshooting

  1. Check your messaging profile — Confirm a webhook URL is configured in the Portal or via the API.
  2. Test your endpoint — Send a test POST request with curl to ensure your server is accessible:
  3. Check ngrok — If using ngrok, verify the tunnel is running and the URL matches your profile configuration.
  4. Check firewall — Ensure 192.76.120.192/27 is allowlisted.
  5. Check Message Detail Records — Events are logged regardless of webhook delivery. Check MDRs in the portal.
This is expected behavior. Telnyx may deliver the same webhook more than once, especially during retries. Track processed event IDs (data.id) and skip duplicates:
For production, use a persistent store (Redis, database) instead of in-memory sets.
Telnyx does not guarantee delivery order. For example, message.finalized may arrive before message.sent. Use the data.occurred_at timestamp to determine event sequence, and design your logic to handle any arrival order.
  1. Ensure you’re reading the raw body — Parse the signature against the raw request body, not a re-serialized JSON object.
  2. Check your public key — Verify you’re using the correct public key from the Portal.
  3. Check timestamp tolerance — If you’re rejecting stale timestamps, ensure your server clock is synchronized (NTP).
Your endpoint must respond within 2 seconds. If your processing takes longer:
  • Return 200 immediately
  • Process the event asynchronously (use a message queue like Redis, RabbitMQ, or SQS)

Next steps

Receive Messages Tutorial

Step-by-step guide to building a webhook server

Send Your First Message

Send SMS and MMS with the Messaging API

Webhook Fundamentals

Platform-wide webhook concepts, signing, and retry behavior

Message Detail Records

Query historical message data and delivery statuses