Webhooks
Fern supports two methods for defining webhooks in your OpenAPI specification:
- Using OpenAPI 3.1’s native webhook support (recommended)
- Using Fern’s
x-fern-webhookextension
OpenAPI 3.1 webhooks
For OpenAPI 3.1 specifications, use the webhooks top-level field to define your webhook operations. Each webhook requires an operationId to be properly processed by Fern.
Fern webhook extension
For OpenAPI 3.0, use the x-fern-webhook: true extension to define webhooks. Fern will treat the requestBody as the webhook payload.
The path that you choose when defining a webhook can be arbitrary. Since webhooks can be sent to any server, Fern just ignores the path.
Generate webhook reference
Fern Docs can automatically generate your webhook reference documentation from your definition. Set this up in your docs.yml file.
Your webhook reference can be a single documentation page:
Or you can configure individual documentation pages per webhook event:
For more information on how to configure your webhook reference in docs.yml, see Generate your webhook reference.
SDK signature verification
Use the x-fern-webhook-signature extension to configure webhook signature verification. When configured, Fern generates SDK utilities that allow users to verify webhook signatures and ensure events originate from your API.
Configuration can be set at the document level (applies to all webhook endpoints) or per-endpoint (overrides the document-level default). Both levels accept the same configuration options.
Fern supports two verification methods: HMAC (symmetric key verification using shared secrets) and Asymmetric (public key verification using RSA, ECDSA, or Ed25519 keys).
Document-level
Per-endpoint override
Configuration options
Common fields
These fields apply to both HMAC and asymmetric verification.
type
The signature verification method. Use hmac for symmetric key verification with shared secrets, or asymmetric for public key verification.
header
The HTTP header containing the signature. For example, x-webhook-signature or x-hub-signature-256.
encoding
The encoding format of the signature value in the header.
signature-prefix
A prefix to strip from the signature header value before verification. For example, "sha256=" or "rsa=".
timestamp.header
HTTP header containing the delivery timestamp.
timestamp.format
Format of the timestamp value in the header.
timestamp.tolerance
Allowed clock skew in seconds. Requests with timestamps outside this window are rejected.
HMAC fields
These fields apply when type is set to hmac.
algorithm
The HMAC hash algorithm for signature computation. sha256 is recommended. sha1 is deprecated and should only be used for legacy compatibility.
payload-format.components
Ordered list of payload components to concatenate before hashing. Available components:
payload-format.delimiter
String used to join the components. Use "." for timestamp-prefixed payloads or "" for direct concatenation.
Asymmetric fields
These fields apply when type is set to asymmetric.
asymmetric-algorithm
The asymmetric signing algorithm. rsa-sha256 and ecdsa-sha256 are widely supported defaults. ed25519 is a modern, efficient option.
jwks-url
JSON Web Key Set (JWKS) endpoint URL of the key retrieval service. Required when using JWKS-based key rotation; omit for static key verification.
key-id-header
HTTP header containing the key ID used to select the correct key from the JWKS endpoint.