GET /api/v2/events and receives events as a Server-Sent Events (SSE) stream. You control when to connect, how to resume after a disconnection, and how fast to consume events.
This approach is useful when you need to:
- Process events at your own pace without standing up a webhook endpoint.
- Replay events from a specific point in time for backfill or recovery.
- Integrate with systems that prefer polling over push-based delivery.
How the Events API works
When your application connects to the Events API, it receives a stream of SSE messages. Each message includes anid field that acts as an offset. If the connection drops, your application reconnects and provides the last offset it received. Auth0 resumes delivery from that point, so no events are lost.
The SSE stream includes the following message types:
Example SSE stream
Prerequisites
Before you begin, make sure you have:-
An Auth0 tenant with Events enabled. The number of Event Stream connections available depends on your plan:
-
A Management API access token with the
read:eventsscope. To learn more, read Management API Access Tokens.
Connect to the Events API
Open an SSE connection to the events endpoint on your tenant. The following example usescurl:
Query parameters
Use query parameters to filter or resume the stream:Resume after a disconnection
SSE connections can drop for many reasons: network issues, token expiration, or server-side connection cycling (Auth0 periodically closes connections for load balancing — typically every few minutes). Standard SSE client libraries handle this transparently by reconnecting and sending the last offset. There are two ways to supply the offset on reconnection:Last-Event-IDheader — the standard SSE reconnection mechanism. Most SSE client libraries set this header automatically when reconnecting.fromquery parameter — use this when your client does not support theLast-Event-IDheader.
Last-Event-ID header takes precedence.
Persist the latest
id value from every message (including offset-only messages) to durable storage. If your application restarts, use the persisted offset to resume delivery from where you left off.Handle message types
Real events
Messages where theevent field matches a known event type (for example, user.created) contain the full event payload in the data field. Parse the JSON and process the event according to your business logic.
Offset-only messages
Auth0 sendsoffset-only messages at regular intervals (on the heartbeat frequency) to advance your position in the stream. These messages do not contain an event payload. Update your stored offset when you receive them so that a future reconnection does not replay events you have already passed.
Error messages
Anevent: error message signals a terminal issue such as an expired offset or a server-side problem. After receiving this message, the stream closes. Your application should log the error, then reconnect with the appropriate offset or a fresh from_timestamp.
Heartbeats
Lines that begin with: are SSE comments used as heartbeats. They keep the connection alive through proxies and load balancers. No processing is required.
Server-side connection cycling
Auth0 periodically closes SSE connections for load-balancing purposes (typically every few minutes). This is expected behavior, not an error. Standard SSE client libraries (including theeventsource npm package) reconnect automatically using the Last-Event-ID header, so your application resumes from the correct offset without losing events.
If you build a custom SSE client, make sure it handles connection drops gracefully by persisting the latest offset and reconnecting with it.
Implement a consumer
The following Node.js example demonstrates a minimal Events API consumer that processes events and persists the offset to a file.The
eventsource npm package implements the SSE protocol and handles reconnection automatically using the Last-Event-ID header. If you use a different SSE library, verify that it supports automatic reconnection and offset forwarding.