Webhooks
There are none. What to use instead, and why the difference matters for gates.
The Feed Builder API has no webhooks
There is no callback URL to register, no signed delivery, and no endpoint that accepts one. Nothing in this API will ever make an outbound request to you. If you have seen a webhook described for String, it belongs to a different product.
This page exists so that the answer is "not available", rather than you searching for an endpoint that is not there.
Use the stream, or poll
| You are building… | Use |
|---|---|
| A UI where someone watches the build | GET /v1/builds/{id}/events (server-sent events) |
| A backend job that checks in periodically | GET /v1/builds/{id}, comparing version |
| A dashboard over many builds | GET /v1/builds, whose summaries carry pending_gate_id and pending_gate_kind |
GET /v1/builds is the cheapest way to answer "is anything of mine waiting on me?" across every build at once — the
summary rows carry the pending gate without fetching each build.
Why this matters more here than on a typical API
A supervised build stops at a gate and stays stopped. It is not a job that finishes on its own while you get on
with something else: until somebody answers, nothing happens, and the run sits in awaiting_input indefinitely.
Without a webhook, noticing that state is your side's job. Whatever you build, make sure something notices
status == "awaiting_input" and routes it to a person — an unanswered gate is the most common reason a build
appears to have stalled.
If you connect over SSE, build.gate.raised gives you that signal immediately. If you poll, poll often enough that a
person is not waiting on your cron.
Delivery of the finished feed
The built feed itself is not delivered through this API at all. Approving the publish_review gate registers a
delivery subscription, and the data arrives through that. This API's GET /v1/builds/{id}/sample returns sample rows
only — see Limits.