跳到主要内容
Sursa Developers

POST/v1/webhooks/{webhook_id}/test

发送测试事件

test_webhook

立即发送一个带有 test: true 的事件，不受订阅和 Webhook 状态的影响，不按该 Webhook 的投递顺序，也不带 X-KB-Sequence。该事件不写入事件记录。type 可以是目录中的任意类型（默认为 webhook.ping）；data 取自规范 webhooks 部分中该事件的示例。失败不会重试，也不计入暂停阈值。响应是该次投递，包含接收端的响应码和错误。

身份验证

在 Authorization 请求头中传入 API 密钥：Authorization: Bearer <密钥>。

路径参数

  • webhook_idinteger必填

请求头参数

  • Idempotency-Keystring

    写操作安全重试所用的键：1 到 255 个可打印 ASCII 字符；建议每个逻辑操作使用一个 UUID v4。24 小时内使用同一个键重试不会再次执行操作，而是返回已保存的响应（状态、响应头和正文），并附带 Idempotency-Replayed: true 头。同一个键配合不同的方法、路径、Content-Type 或正文时返回 409 api.idempotency_mismatch；第一个请求仍在执行时返回 409 api.idempotency_in_progress，并附带 Retry-After: 1。收到 5xx 或 429 响应后，该键被释放，重试会再次执行操作。键的作用范围是组织和调用方（API 密钥、用户或自定义数据源密钥）。

    length ≥ 1, length ≤ 255

请求体

application/json

对象：WebhookTestRequest

响应

200已尝试投递（是否成功见 `status`）。

响应头

  • RateLimit-Policy

    当前生效的限制，格式遵循 IETF 草案 draft-ietf-httpapi-ratelimit-headers：以逗号分隔的项 "<name>";q=<quota>;w=<window in seconds>。key 是 API 密钥的请求速率（配额即突发量，时间窗口是配额完全恢复所需的时间；会话为 user，无凭据时为 ip）；minute、day 和 month 是组织按 UTC 计算的自然分钟、自然日和自然月的配额。

  • RateLimit

    RateLimit-Policy 中每项限制的剩余量："<name>";r=<remaining>;t=<seconds until reset>。

  • X-RateLimit-Limit

    RateLimit-Policy 中最严格一项（剩余请求数最少的一项）的限额。

  • X-RateLimit-Remaining

    最严格限制下的剩余请求数。

  • X-RateLimit-Reset

    距最严格限制重置的秒数。

  • Idempotency-Replayed

    为 true 时表示该响应是按此 Idempotency-Key 从已保存的响应重放的：操作没有再次执行。

application/json

对象：WebhookDelivery

  • expandedWebhookDeliveryExpanded
  • idinteger必填
  • webhook_idinteger必填
  • event_idstring必填

    事件 ID（evt_…），也会在 X-KB-Event-Id 头和投递正文中发送。

  • event_typeWebhookEventType必填
  • event_created_atstring (date-time)必填
  • attemptinteger必填

    已进行的投递尝试次数。

  • statusWebhookDeliveryStatus必填
  • response_codeinteger | null
  • duration_msinteger | null
  • next_retry_atstring (date-time) | null
  • errorstring | null
  • delivered_atstring (date-time) | null
  • created_atstring (date-time)必填
  • updated_atstring (date-time)必填
  • sequenceinteger | null

    在 Webhook 投递顺序中的编号（X-KB-Sequence）；测试投递为 null。

  • testboolean必填

    测试投递（POST /v1/webhooks/{webhook_id}/test）。

  • redelivery_ofinteger | null

    如果这是一次重新投递，则为原始投递。

  • error_codestring | null

    最后一次失败的中性代码：timeout、connection_failed、tls_error、private_address、unresolvable、redirect、http_error、request_failed、endpoint_disabled、event_expired；已取消的投递（cancelled）还可能带有 event_not_permitted（投递尝试时事件不在 Webhook 的权限之内，因为事件分发之后权限被收窄）或 event_unavailable（测试投递的正文已不可用）。

401未发送凭据（既没有会话 Cookie，也没有 API 密钥），或未找到该密钥。

响应头

  • RateLimit-Policy

    当前生效的限制，格式遵循 IETF 草案 draft-ietf-httpapi-ratelimit-headers：以逗号分隔的项 "<name>";q=<quota>;w=<window in seconds>。key 是 API 密钥的请求速率（配额即突发量，时间窗口是配额完全恢复所需的时间；会话为 user，无凭据时为 ip）；minute、day 和 month 是组织按 UTC 计算的自然分钟、自然日和自然月的配额。

  • RateLimit

    RateLimit-Policy 中每项限制的剩余量："<name>";r=<remaining>;t=<seconds until reset>。

  • X-RateLimit-Limit

    RateLimit-Policy 中最严格一项（剩余请求数最少的一项）的限额。

  • X-RateLimit-Remaining

    最严格限制下的剩余请求数。

  • X-RateLimit-Reset

    距最严格限制重置的秒数。

application/json

对象：Error

403不允许执行该操作：角色权限不足、无权访问合集或卡片、请求在“View as”模式下执行，或组织已被暂停或删除（`detail` 为对象，包含 `code: org_suspended | org_deleted`）。

响应头

  • RateLimit-Policy

    当前生效的限制，格式遵循 IETF 草案 draft-ietf-httpapi-ratelimit-headers：以逗号分隔的项 "<name>";q=<quota>;w=<window in seconds>。key 是 API 密钥的请求速率（配额即突发量，时间窗口是配额完全恢复所需的时间；会话为 user，无凭据时为 ip）；minute、day 和 month 是组织按 UTC 计算的自然分钟、自然日和自然月的配额。

  • RateLimit

    RateLimit-Policy 中每项限制的剩余量："<name>";r=<remaining>;t=<seconds until reset>。

  • X-RateLimit-Limit

    RateLimit-Policy 中最严格一项（剩余请求数最少的一项）的限额。

  • X-RateLimit-Remaining

    最严格限制下的剩余请求数。

  • X-RateLimit-Reset

    距最严格限制重置的秒数。

application/json

对象：Error

404对象不存在或您无权访问。对于访问受限的对象，API 不会确认其是否存在。

响应头

  • RateLimit-Policy

    当前生效的限制，格式遵循 IETF 草案 draft-ietf-httpapi-ratelimit-headers：以逗号分隔的项 "<name>";q=<quota>;w=<window in seconds>。key 是 API 密钥的请求速率（配额即突发量，时间窗口是配额完全恢复所需的时间；会话为 user，无凭据时为 ip）；minute、day 和 month 是组织按 UTC 计算的自然分钟、自然日和自然月的配额。

  • RateLimit

    RateLimit-Policy 中每项限制的剩余量："<name>";r=<remaining>;t=<seconds until reset>。

  • X-RateLimit-Limit

    RateLimit-Policy 中最严格一项（剩余请求数最少的一项）的限额。

  • X-RateLimit-Remaining

    最严格限制下的剩余请求数。

  • X-RateLimit-Reset

    距最严格限制重置的秒数。

application/json

对象：Error

429请求过多（`api.rate_limited`）、组织每分钟、每天或每月的配额已用完（`api.quota_exceeded`；`error.details` 中包含 `quota`、`limit` 和 `reset_at`）、已达到组织的限额，或回答服务繁忙（`answers.engine_busy`）。请等待 `Retry-After` 头中给出的时间。

响应头

  • Retry-After

    重试请求前需要等待的秒数。

  • RateLimit-Policy

    当前生效的限制，格式遵循 IETF 草案 draft-ietf-httpapi-ratelimit-headers：以逗号分隔的项 "<name>";q=<quota>;w=<window in seconds>。key 是 API 密钥的请求速率（配额即突发量，时间窗口是配额完全恢复所需的时间；会话为 user，无凭据时为 ip）；minute、day 和 month 是组织按 UTC 计算的自然分钟、自然日和自然月的配额。

  • RateLimit

    RateLimit-Policy 中每项限制的剩余量："<name>";r=<remaining>;t=<seconds until reset>。

  • X-RateLimit-Limit

    RateLimit-Policy 中最严格一项（剩余请求数最少的一项）的限额。

  • X-RateLimit-Remaining

    最严格限制下的剩余请求数。

  • X-RateLimit-Reset

    距最严格限制重置的秒数。

application/json

对象：Error

错误码

除所有请求通用的错误码外，此接口还可能在 error.code 中返回以下错误码。

安全重试

每个 POST 和 PATCH 请求都传入 Idempotency-Key 头（例如一个 UUID）。24 小时内用同一个键重试时，返回已保存的响应，不会再次执行请求。

速率限制

响应带有 RateLimit 和 RateLimit-Policy 头，以及旧版的 X-RateLimit-Limit、X-RateLimit-Remaining 和 X-RateLimit-Reset 头。429 响应带有以秒为单位的 Retry-After：等待后重试。

← webhooks · API 参考