Webhooks

Pealboard does not send webhooks to a caller in v1. There is no way to register a URL and no event this API will call it with. If you were looking for the API pushing a notification about a change to your own service, it does not exist yet.

This is separate from Pealboard receiving webhooks from GitHub, which is how its own cache stays current — that is described in GitHub and is not something an integrator configures or calls.

Outbound webhooks are on the roadmap for v1.1, not v1. There is no public roadmap page yet; when they ship, the entry will appear in the developer changelog.

Poll instead

Until then, learn about change by asking for it, on a schedule.

A window of change, with updated_since:

curl "https://api.pealboard.com/v1/issues?updated_since=-15m&limit=100" \
  -H "Authorization: Bearer pb_AbCdEf0123456789AbCdEf0123456789AbCdEf01"

Page through the result with cursor the same as any list, then record the time you polled for next time. See Pagination.

A saved view, if the filter you want to watch is already one a workspace uses:

curl https://api.pealboard.com/v1/views/3fae5b2a-6c9e-4b2b-9c39-2e5e5b7a1a11/run \
  -H "Authorization: Bearer pb_AbCdEf0123456789AbCdEf0123456789AbCdEf01"

GET /v1/views/{viewId}/run runs a saved view’s own filter, sort and grouping and returns the same paged shape as GET /v1/issues; it takes only cursor and limit, not an override of the view’s filter. A view whose own filter already includes an updatedSince window — set when the view was created or edited, the same field GET /v1/issues calls updated_since — runs as a rolling window every time it is polled.

Reads never touch GitHub — every list and every view runs against Pealboard’s own cache, so polling costs nothing against GitHub’s rate limit, only against Pealboard’s own per-credential one. See Rate limits.