Skip to main content

Trigger notifications in bulk.

POST 
/v1/events/bulk

Prefer this over looping on POST /v1/events/trigger when you have more than a handful of notifications: one HTTP round trip, one authentication check, and the events are published concurrently.

Each event is validated, routed and published exactly as a single trigger would be, so anything accepted here behaves identically to a single call. Events succeed or fail individually: the response reports each outcome by index, and a rejected event never blocks the rest of the batch. Check failedCount rather than the HTTP status.

Priority is ignored for bulk. Every event in a batch is published to the NOTIFY_BULK stream (notify.bulk.{channel} subject), regardless of the X-Priority-Override header. This is observable behaviour: a bulk campaign can never sit in front of another customer's password reset.

Rate limits still apply per to.subscriberId, so a batch aimed at one subscriber can exhaust that subscriber's budget and see later entries rejected while the rest of your traffic is unaffected.

An empty events array, or one longer than 5,000 entries, is rejected with 400 before anything is published.

Request​

Responses​

Batch processed — inspect failedCount and events for per-event outcomes

Response Headers
RateLimit

IETF draft-11 remaining budget and reset for each ingest policy. Advisory only.

RateLimit-Policy

IETF draft-11 policy for each ingest tier (workspace, subscriber, monthly quota).