manage-scoped token, in the dashboard under Customers, or by the customers themselves in the portal. All three surfaces operate on the same objects, so an endpoint a customer adds in the portal is immediately visible to your API and your team.
Customers
Customers are identified by anexternalId you choose: your database’s account id, an org slug, whatever you already use.
201 when the customer is new and 200 with the existing customer otherwise, so you can call it from a signup flow without checking first. A customer carries an optional display name and free-form metadata.
You don’t have to pre-create customers. Creating an endpoint for an unknown
externalId creates the customer at the same time.
Endpoints
201 response contains the endpoint and its whsec_... signing secret. The secret is returned only on creation; store it or show it to your customer right away. It remains available later through the secret routes and the portal.
The other routes follow the same pattern:
GET /v1/customers/{externalId}/endpoints lists a customer’s endpoints, and GET, PATCH, and DELETE /v1/endpoints/{id} operate on one. Updates apply to pending retries as well, so correcting a mistyped URL also redirects the backlog.
Pause and resume
endpoint_gone.
URL safety
Endpoint URLs are validated when set and checked again when a connection is opened.localhost, .local names, and private or reserved IP ranges are rejected with 422, and DNS answers are re-checked at dial time, so an endpoint cannot be pointed at your internal network. To receive webhooks on a development machine, use a public target such as a Repost bucket forwarded to localhost with the CLI.
Continue
Signing
How the endpoint’s secret signs deliveries, and how to rotate it.
Delivery & retries
What happens to each endpoint’s deliveries, attempt by attempt.
Customer portal
Let customers manage these endpoints themselves.