Fern Definition isn’t recommended for new customers and Fern isn’t accepting feature requests for this format. It remains supported for existing users.
In Fern, you can specify webhooks in your API definition. The webhooks will be included in both the generated SDKs and the API documentation.
Each webhook defines:
GET or POST)You can inline the schema of the payload by doing the following:
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.
You can configure webhook signature verification directly in your Fern Definition using the webhook-signature block. 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 webhooks) or per-webhook (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).
These fields apply to both HMAC and asymmetric verification.
The signature verification method. Use hmac for symmetric key verification with shared secrets, or asymmetric for public key verification.
The HTTP header containing the signature. For example, x-webhook-signature or x-hub-signature-256.
The encoding format of the signature value in the header.
A prefix to strip from the signature header value before verification. For example, "sha256=" or "rsa=".
HTTP header containing the delivery timestamp.
Format of the timestamp value in the header.
Allowed clock skew in seconds. Requests with timestamps outside this window are rejected.
These fields apply when type is set to hmac.
The HMAC hash algorithm for signature computation. sha256 is recommended. sha1 is deprecated and should only be used for legacy compatibility.
Ordered list of payload components to concatenate before hashing. Available components:
String used to join the components. Use "." for timestamp-prefixed payloads or "" for direct concatenation.
These fields apply when type is set to asymmetric.
The asymmetric signing algorithm. rsa-sha256 and ecdsa-sha256 are widely supported defaults. ed25519 is a modern, efficient option.
JSON Web Key Set (JWKS) endpoint URL of the key retrieval service. Required when using JWKS-based key rotation; omit for static key verification.
HTTP header containing the key ID used to select the correct key from the JWKS endpoint.