Webhooks
Fern 支持两种在 OpenAPI 规范中定义 webhooks 的方法:
- 使用 OpenAPI 3.1 的原生 webhook 支持(推荐)
- 使用 Fern 的
x-fern-webhook扩展
OpenAPI 3.1 webhooks
对于 OpenAPI 3.1 规范,使用 webhooks 顶级字段来定义您的 webhook 操作。每个 webhook 都需要一个 operationId 才能被 Fern 正确处理。
Fern webhook 扩展
对于 OpenAPI 3.0,使用 x-fern-webhook: true 扩展来定义 webhooks。Fern 会将 requestBody 视为 webhook 负载。
定义 webhook 时选择的路径可以是任意的。由于 webhooks 可以发送到任何服务器,Fern 会忽略路径。
生成 webhook 参考
Fern Docs 可以从您的定义中自动生成 webhook 参考文档。在您的 docs.yml 文件中进行设置。
您的 webhook 参考可以是单个文档页面:
或者您可以为每个 webhook 事件配置单独的文档页面:
有关如何在 docs.yml 中配置 webhook 参考的更多信息,请参阅生成 webhook 参考。
SDK 签名验证
使用 x-fern-webhook-signature 扩展来配置 webhook 签名验证。配置后,Fern 会生成 SDK 工具,允许用户验证 webhook 签名并确保事件来自您的 API。
配置可以在文档级别(适用于所有 webhook 端点)或每个端点(覆盖文档级别的默认设置)设置。两个级别都接受相同的配置选项。
Fern 支持两种验证方法:HMAC(使用共享密钥的对称密钥验证)和非对称(使用 RSA、ECDSA 或 Ed25519 密钥的公钥验证)。
文档级别
每端点覆盖
配置选项
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. Required when timestamp is configured.
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. When algorithm-header is set, this is the default used for requests that don’t carry the algorithm header.
algorithm-header.header
HTTP header that selects the HMAC algorithm per request, for providers that send the algorithm (and optionally a key ID) alongside each webhook instead of using one fixed algorithm. Generated SDKs add a request-level verifyRequest helper that reads this header.
algorithm-header is accepted in generators.yml under api.settings.webhook-signature and in a Fern Definition webhook-signature or webhook signature block. The OpenAPI x-fern-webhook-signature extension doesn’t support it yet.
algorithm-header.key-id-delimiter
Separator between a key ID and the algorithm in the header value, which then takes the form <key-id><delimiter><algorithm> (for example, key_123;HMAC_SHA256). The value is split on the last occurrence of the delimiter, and the key ID is passed to the caller to resolve the matching signing secret. When omitted, the whole header value is the algorithm. When algorithm-parameter is set, this instead separates the <name>=<value> pairs and defaults to ,.
algorithm-header.key-id-parameter
Name of the parameter that carries the key ID when the header is a list of <name>=<value> pairs, such as key for Twilio’s key=webhooks_sharedkey_<id>,algorithm=HMAC_SHA256. Applies only when algorithm-parameter is also set. The parameter’s value is passed to the caller to resolve the matching signing secret, and a request whose header lacks it fails verification.
algorithm-header.algorithm-parameter
Name of the parameter that carries the algorithm when the header is a list of <name>=<value> pairs, such as algorithm. Setting it switches the header to named-parameter parsing: the value is split on key-id-delimiter (default ,), names and values are trimmed, and parts without = are ignored. The algorithm parameter’s value is then matched against algorithms.
algorithm-header.algorithms
Allowed header values mapped to the HMAC algorithm each one selects, such as HMAC_SHA256: sha256. Header values are matched exactly, and a request with a value not listed here fails verification. Requires at least one entry.
payload-format.components
Ordered list of payload components to concatenate before hashing. When omitted, only the raw request body is signed. Available components:
payload-format.delimiter
String used to join the components. Use "." for timestamp-prefixed payloads or "" for direct concatenation. Required when payload-format.components is set.
body-hash-binding.algorithm
Hash algorithm applied to the raw request body. Independent of algorithm, which applies to the signature itself. Set body-hash-binding when the provider transmits a hash of the body alongside a signature computed over the notification URL.
body-hash-binding.encoding
Encoding of the transmitted body hash.
body-hash-binding.location.type
Where the body hash is transmitted. Query parameters on the notification URL are the only supported location.
body-hash-binding.location.name
Name of the query parameter carrying the body hash.
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.
payload-format.components
Ordered list of payload components to concatenate before signing. When omitted, only the raw request body is signed. Available components:
timestamp in the components list, the timestamp.tolerance check can’t protect against replay attacks because the timestamp is unauthenticated. Include timestamp to ensure replay protection.payload-format.delimiter
String used to join the components. Use "." for timestamp-prefixed payloads or "" for direct concatenation. Required when payload-format.components is set.
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.