Integrations

Webhook Discord

Discord has several webhook-shaped flows. Incoming Discord webhook URLs post messages into Discord channels. Discord interaction webhooks send slash commands, components, modals, and PING validation requests to your app.

FastHook focuses on receiving and operating Discord interaction callbacks: it verifies Ed25519 signatures, handles PING validation, stores request evidence, and routes accepted interactions to destinations.

Discord webhook ingress contract with signature verification and routing.
For Discord interactions, verify the provider request first, then route command families to the services that own them.

Discord incoming webhooks vs interaction webhooks

Discord incoming webhooks are channel URLs used to post messages into Discord. They are useful for alerts and notifications, but they are not the same as Discord interaction webhooks. Interaction webhooks are callbacks that Discord sends to your application when a user runs a slash command, clicks a component, submits a modal, or when Discord validates the endpoint with a PING payload.

FastHook's Discord source type is for receiving Discord interaction callbacks. It verifiesx-signature-ed25519 and x-signature-timestamp with the Discord application public key before routing accepted requests to your command handlers.

Create a Discord webhook source

Create Discord source
curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer $FASTHOOK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Discord interactions",
    "type": "DISCORD",
    "config": {
      "auth_type": "PROVIDER_SIGNATURE",
      "auth": {
        "provider": "DISCORD",
        "public_key": "hex-application-public-key"
      },
      "allowed_http_methods": ["POST"]
    }
  }'

Route Discord interactions

Route by interaction type, command name, guild id, or application environment. Many teams keep moderation actions, customer commands, and admin-only commands on separate destination branches so retries and replay do not mix unrelated side effects.

  • Keep command handlers fast enough for Discord's response expectations.
  • Use internal job queues for long-running work after the interaction is accepted.
  • Store Discord interaction ids or FastHook event ids before applying side effects.
  • Use request evidence to debug PING validation before enabling normal interactions.

Debug Discord webhooks

  • Missing request: confirm Discord is using the generated FastHook source URL.
  • Invalid signature: confirm the application public key and raw request body handling.
  • PING issue: inspect the request and response path before enabling normal interactions.
  • Receiver failure: inspect destination attempts and retry only after the handler is fixed.

Discord webhook test payload

Discord interaction shape
{
  "type": 2,
  "id": "112233445566778899",
  "application_id": "998877665544332211",
  "guild_id": "123456789012345678",
  "channel_id": "234567890123456789",
  "data": {
    "name": "deploy",
    "type": 1,
    "options": [
      { "name": "environment", "value": "staging" }
    ]
  }
}

Discord routing examples

  • Route slash command names such as deploy, status, or incident to different handlers.
  • Route admin-only commands to destinations with stricter receiver authentication.
  • Route guild-specific interactions to workspace-specific services when several communities share one app.
  • Send unknown or experimental commands to a mock destination while testing new Discord workflows.

Discord operational notes

Discord validation failures often happen before application logic runs. Keep the raw body, signature headers, public key, and PING response path easy to inspect. Once validation succeeds, treat command handlers like any other webhook receiver: make side effects idempotent, store interaction ids, and retry only after reading the failed destination attempt.

Related guides