Skip to main content
The sendbatch response confirms acceptance only. It carries a batchId, a count, and no per-message ids at all. Per-message results arrive as callbacks.

​
What arrives

A bare GET with a query string. There is no body at all.
statusText carries the messageId on success. That is the only place a batch gives you one, so if you need to correlate later receipts back to individual batch members, this callback is where you capture it.

​
One result per message, not one per batch

A batch of 500 produces up to 500 callbacks. Your endpoint should be cheap and idempotent — the same retry rules apply as for receipts, so a slow handler will be called again.

​
The silent failure

Unknown keys in batch_config are ignored, not refused.errback_url misspelled as errBack_url or error_url produces no 400. The batch is accepted, the messages are sent, and every per-message result goes nowhere. From the outside it looks exactly like a batch where nothing failed.This is the one place on the API where a typo does not produce an error, so verify it deliberately: send a batch containing one message you know will be refused — an unapproved sender ID is easiest — and confirm the callback lands.

​
Success, retries and timeouts

Identical to delivery receipts: At the default budget an unreachable endpoint occupies a thread for twenty minutes per callback — so an endpoint that is down during a large batch is expensive for your provider as well as useless to you.

​
What this is not

  • Not a delivery receipt. A batch callback says the message was accepted or refused at ingress. Whether it was delivered still comes from a dlr_url, which you set in globals so it applies to every message in the batch.
  • Not ordered. Results arrive as messages are processed, not in the order you listed them.

Batches

Scheduling, globals, and the expansion cap.

Delivery receipts

The outcome, as opposed to acceptance.