You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 5f54fb2
Browse filesBrowse the repository at this point in the historyBrowse files
feat(webapp,core): webhook response contracts, GET verification and verify tokens
## Summary
Hosted webhook sources can now describe how the provider expects to be
answered, and the ingress honors it. This is the server side for
providers like Discord and WhatsApp, whose SDK sources follow in a later
release.
- A verifier artifact can declare a response contract as data: the
status code for a handshake answer (`respondStatus`), and the codes
returned for accepted deliveries and rejected signatures
(`response.acceptedStatus`, `response.rejectedStatus`). The ingress and
the dashboard's send action map every outcome through the same helper,
so a source that needs 204 on success and 401 on a bad signature gets
exactly that.
- A verifier artifact can declare a GET verification flow
(`getHandshake`) for providers that confirm a callback URL with a
challenge, such as Meta's `hub.challenge`. The ingress answers GET on
the endpoint URL against a dedicated verify token, which you generate
and reveal from the endpoint's Connect panel. The token is its own
credential, separate from the signing secret.
- HMAC verifiers can read the signed timestamp from a body field. The
Linear provider uses it for a 60 second replay window on
`webhookTimestamp`; deliveries are deduplicated on the signed request
itself, so a replay with a different unsigned delivery header is still
recognised as a duplicate.
- The dashboard's test-send re-signs a recorded sample with the current
timestamp, so sources with a body-timestamp replay window accept it.
- An admin API action bootstraps delivery partitions in the configured
webhook database before enablement. It is safe to repeat and preserves
existing partitions. Bootstrap and daily maintenance can use
`WEBHOOK_DATABASE_DIRECT_URL` with separate owner credentials while
application queries use `WEBHOOK_DATABASE_URL`. When the direct URL is
unset, partition operations reuse the webhook writer.
- The index worker protocol gains a message for duplicate webhook ids,
so the CLI can report which files define the same id. The CLI side of
this ships with the SDK release that adds `webhook()`.
Mono-RevId: 54862ef81ec5adc311aa42783020fedc4b8c3ba9
Webhook verifier artifacts can now declare the provider's response contract as data: a handshake `respondStatus`, the status codes returned for accepted deliveries and rejected signatures, and a GET verification flow (`getHandshake`) for providers that confirm a callback URL with a challenge. HMAC verifiers can read the timestamp from a body field, which the Linear provider config uses for its replay window, and the dashboard's test-send re-signs a recorded sample as of now so it passes that window.
Copy file name to clipboardExpand all lines: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.webhooks.endpoints.$endpointParam/route.tsx
0 commit comments