One parser for Sume run webhooks and the poll response
A Sume run webhook payload is byte-identical to the data object from the poll endpoint, so one parser serves both. Handle outcome ok, degraded and error once.
Write one parser for Sume agent runs. The webhook payload is byte-identical to the data object returned by GET /v1/agent-runs/{id}, so the same code handles a delivery and a poll.
This follows Sume's Run webhooks and Agent Completions pages, read 2026-10-06.
What does the shared parser handle?
The table below lists each item as documented.
| Field | Values | Handler action |
|---|---|---|
outcome | ok | Store artifacts |
outcome | degraded | Store and flag for review |
outcome | error | Alert; do not retry blindly |
payload | null with payload_too_large | Poll for the full object |
Where do the two paths differ?
Only the envelope differs. A webhook adds signature headers you verify first; a poll needs a key with agent_completions:read. Canceled and skipped runs send no webhook, so poll for them. Poll as a backstop for deliveries that never arrived.
Sources
Related posts
More in Developers
- One output object for every episode: 1080x1920 at 30 fps in Timeline
Pin the same Timeline output block on every Shorts episode: 1080x1920 at 30 fps. Mixed-model clips then do not trigger the fps resample warning.
- One 6-minute b-roll, twelve Shorts episodes: source_in offsets
Slice one imported b-roll into twelve non-repeating 30-second episode backgrounds with Timeline 1.0 source_in, and plan the whole season unbilled in Python.
- One Sume API key per service: what it isolates and what it does not
Sume request budgets are per key and reads and writes are already separate. A key per service isolates revocation and scope, not generation capacity.
- GPT Image 2.5 Flare on Sume: the id is openai/gpt-image-2.5, no suffix
Flare is openai/gpt-image-2.5 on Sume's Image API and Sunburst is openai/gpt-image-2.5-sunburst. An id ending in -flare returns 404 model_not_found.
Written by Sume