Source type

Discord Event Webhooks Source

Discord Event Webhook sources receive signed application lifecycle, entitlement, lobby, and Social SDK event notifications over HTTP.

DISCORD_EVENTSPOSTApplication Public KeyCommunication
Discord sends webhook traffic to a FastHook source, FastHook validates the provider contract, records the request, and routes accepted events through connections to destinations.DiscordProviderPOSTSetup + eventsFastHookSource URLDISCORD_EVENTSProvider credentialPING/204Verify before queue401 on auth failure405 on wrong methodAcceptedRequestverified: trueConnections route the accepted request to destinationsFilters, transformations, retries, replay, and destination signatures stay downstream from source verification.Provider setupValidate firstPING / 204
FastHook keeps the provider-facing contract on the source. Accepted requests are stored before routing, while rejected requests keep enough evidence to debug signature, method, and challenge failures.

When to use this source type

Choose the DISCORD_EVENTS source type when Discord 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 Discord Event Webhooks, keep Authenticate enabled when verification is required, and fill the fields below.

Source Type

DISCORD_EVENTS

Allowed methods

POST

Authentication

Provider signature

Application Public Key

Copy this value from Discord and store it on the FastHook source.

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

PING validation before event delivery

Some providers do not send normal event payloads first. They validate the callback URL or subscription contract before delivery starts, so keep the methods listed below enabled during setup.

  1. Discord sends a signed Event Webhook PING payload with type 0.
  2. FastHook verifies the Ed25519 signature and returns the required empty 204 response.
  3. After validation succeeds, Discord sends signed event payloads with type 1; FastHook queues them and acknowledges each delivery with 204.

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.

POST

Special response: Discord Event Webhook PING payloads with type 0 receive an empty 204 response. Verified event payloads are queued and also acknowledged with 204.

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.

x-signature-ed25519

Ed25519 signature in hex.

x-signature-timestamp

Timestamp concatenated with the raw body before verification.

FastHook verifies the Ed25519 signature over timestamp + raw body using the Discord application public key before acknowledging or queueing the request.

Provider setup checklist

  1. In Discord Developer Portal > General Information, copy the Application Public Key into FastHook.
  2. In Discord Developer Portal > Webhook Events, set Webhook Events Endpoint URL to the generated FastHook Source URL.
  3. Enable Events in the Discord Developer Portal and subscribe only to the event families your application needs.
  4. Use a separate source from Discord Interactions because the two endpoint protocols assign different meanings to payload type values.
  5. Confirm the signed type 0 endpoint test receives an empty HTTP 204 response.
  6. Open Discord Webhook Events documentation when you need the provider's event list, dashboard steps, or retry policy.

Supported event types and payload shape

FastHook stores the original Discord 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.

  • Discord Event Webhooks route by event.type, application_id, installation context, entitlement id, lobby id, or user id.
  • Keep Event Webhooks on a separate source from Interactions because payload type values have different protocol meanings.

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. 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.

Discord Event Webhooks source FAQ

What should I inspect first when Discord delivery fails?

Start with FastHook Requests to confirm the provider reached the source and passed verification. Then open the routed Event and destination Attempts when ingress succeeded but downstream delivery failed.

Can I retry or replay Discord webhook traffic?

Yes, after the receiver or route is fixed. Confirm idempotency with provider delivery ids or business object ids before replaying traffic that can create external side effects.

Related docs