Teammate continues a thread: why webhook_delivery.url reads null

When a Sume Agent turn reads a job that another member created, it can see the job's webhook delivery state, but webhook_delivery.url and webhook_delivery.last_error come back null. The turn sees whether delivery happened, not where the owner's callback points.

This follows from one read rule in Jobs and results: a job belongs to its workspace and to the member whose key or Agent turn created it. This page spells out that rule, because the null is easy to mistake for a missing webhook.

Who can read a job?

The docs give one rule for GET /v1/jobs/:id, /status, /result, /events and GET /v1/jobs. Usage is recorded against the creating member, and only that member can cancel the job.

Why is webhook_delivery.url null for a teammate's job?

The turn is allowed to read the job because it is in the thread, but the callback URL belongs to whoever submitted the job. The docs say the turn sees the delivery state and not the owner's callback endpoint, so url and last_error are null. The docs do not give a further reason, so treat it as a privacy boundary between members.

What you can still read is the rest of the delivery block: whether delivery is pending, delivering, delivered, retrying, failed or exhausted. The status vocabulary in Errors and rate limits lists those six values.

If you see null for the URL, do not conclude that no webhook was configured. Check the delivery status first. A delivered status with a null URL is the normal shape for a teammate's job read from a continued thread.

When does this show up in practice?

The docs name the scenario: an API-fired Format run made jobs in a thread, and a teammate who continues that thread can read the run's results, such as the voice and model of each narration job. That is deliberate, so a colleague can pick up work without asking for the original key.

It also explains the opposite surprise. A script using your own API key cannot read a teammate's job at all; for the key the rule is strictly the jobs its own member created, and everything else is 404 not_found. A thread_id filter on a list narrows the result and never widens what a key can read.

How do I check delivery from the receiver's side?

If you own the job, you can read the full delivery block with your own key. This request returns the job record, including webhook_delivery:

curl -sS https://api.sume.com/v1/jobs/job_123 \
  -H "Authorization: Bearer $SUME_API_KEY"

# then read .webhook_delivery.status, .webhook_delivery.url
# and .webhook_delivery.last_error from the response

What should I do when delivery looks stuck?

Use the owner's credentials for any action that touches delivery. The webhooks page documents POST /v1/jobs/{job_id}/webhook/redeliver with the jobs:write scope, which re-posts the real terminal event with a fresh timestamp and signature. Only the member who created the job can cancel it, and the same ownership logic means a teammate's turn is not the right place to fix their endpoint.

Keep polling status_url as the recovery path either way. The docs call a webhook a delivery optimization, not your only way to learn the outcome.