Twilio Source

When to use this source type

Choose the TWILIO source type when Twilio is the system sending webhook requests into FastHook. The source type keeps sender-specific setup close to the source: accepted methods, verification headers, challenge handling, and the exact credential fields are documented together so operators do not need to translate a generic HMAC form into a provider-specific contract.

FastHook verifies the source before accepted traffic is queued. A valid request is stored with verified: true, then connections route it to destinations. A bad signature, wrong token, or missing provider header is rejected as SOURCE_AUTH_FAILED. A method outside the allowed set is rejected as SOURCE_METHOD_NOT_ALLOWED.

FastHook configuration

In the dashboard, create a source, set Source Type to Twilio, keep Authenticate enabled when verification is required, and fill the fields below.

{
  "type": "TWILIO",
  "config": {
    "auth_type": "PROVIDER_SIGNATURE",
    "auth": {
      "provider": "TWILIO",
      "webhook_signing_secret": "auth-token"
    },
    "allowed_http_methods": ["POST","PUT","PATCH","DELETE"]
  }
}

curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "name": "Twilio production",
  "type": "TWILIO",
  "config": {
    "auth_type": "PROVIDER_SIGNATURE",
    "auth": {
      "provider": "TWILIO",
      "webhook_signing_secret": "auth-token"
    },
    "allowed_http_methods": [
      "POST",
      "PUT",
      "PATCH",
      "DELETE"
    ]
  }
}'

HTTP methods

This source accepts only the methods listed below. Keep the set narrow so provider mistakes and accidental test calls are visible as rejected requests instead of being silently accepted.

Headers and verification

FastHook verifies the provider-specific values below before the request is accepted. The comparison is done against the raw inbound request body or the exact provider-specific signing input described here.

FastHook verifies x-twilio-signature using the public request URL, form parameters when applicable, and bodySHA256 when Twilio sends it.

Provider setup checklist

1. Paste the exact generated FastHook Source URL into the Twilio callback setting.
2. Use the Twilio Auth Token in FastHook.
3. Avoid changing query parameters after Twilio is configured because the URL is part of the signature input.
4. Open Twilio webhook security documentation when you need the provider's event list, dashboard steps, or retry policy.

Supported event types and payload shape

FastHook stores the original Twilio request before routing so filters, transformations, retries, and replay decisions can use the same provider evidence. Use stable headers and payload fields for routing rather than relying on receiver-side logs alone.

• Messaging, voice, and status callback requests often use form fields and URL-aware signatures.
• Keep the public callback URL stable because Twilio includes URL data in its signature model.

Troubleshooting

• No request appears: the provider is not calling the generated FastHook Source URL, the source URL was copied before saving, or the provider has not completed its setup validation.
• 405 method rejected: the provider sent a method outside POST, PUT, PATCH, DELETE. Edit the source only if the provider documentation says that method is expected.
• 401 source auth failed: check the configured FastHook field, the provider signing secret, and the header names listed on this page.
• Signature mismatch: make sure the provider signs the same public Source URL it calls and that no proxy, parser, or manual resend changed the raw request body before FastHook received it.

Twilio source FAQ

Related docs

• Sources
• Source authentication
• Webhook signature validation
• Custom source responses
• Provider event routing