Queue-level webhook_url in a Sume bulk body fails: set it per item

A Sume bulk request accepts concurrency, items and an optional idempotency_key, and the API rejects unknown top-level fields. So a webhook_url at the top of a bulk body fails the create. Register the URL on each item's communication.webhook_url instead; the queue object itself has no webhook.

Where each field lives

Each bulk item is the same body as a single run, so it can carry its own communication.webhook_url. Each child run then sends its own terminal format.run.terminal event when it completes or fails.

What this means for a 100-item batch

You get up to 100 deliveries, one per child that completes or fails, and none for canceled or skipped children. There is no event that says the whole queue finished.

• Point every item at the same URL, and map the delivery's run_id to your row with the index map you saved.
• To know the queue is done, poll status_url until status is completed, then check counts.failed and counts.canceled.
• Size the receiver for a burst: with concurrency: 16, many children can finish around the same time.

Building the body in code

Build the items in a loop and attach the same communication object to each one. Keep the queue envelope to its two required keys and the key, so a typo in a top-level field fails fast in your tests, not at 2 a.m.

A typo gets help from the API: for single runs, an unknown field returns 400 unknown_parameter with a suggestion when the name is close, such as webook_url for webhook_url.

Per-item webhooks also let you attach different settings to different rows, since each item is a full run body. A mixed batch can share one queue and one concurrency setting, with each item carrying its own output_schema and primary_output_key.

Tradeoff

Repeating the URL on 100 items is verbose, but it lets you route different rows to different receivers. If you want one signal for the batch, you build it: count the webhooks you receive, or poll the queue as the authority.