Skip to main content

Endpoint

Send one or more users, each with their identifiers and a list of events, in a single request. The API validates each user independently and accepts valid users even if others in the batch fail validation.
Base URL: https://api.revbridge.ai (production) or https://api-dev.revbridge.ai (development).

Request format

Headers

Body

Fields

Response format

202 — Accepted

Returned when at least one user passes validation. The response includes counts and any per-user errors.

400 — Bad Request

Returned when the payload is invalid or all users fail validation.

401 — Unauthorized

Returned when the API key is missing or invalid.

413 — Payload Too Large

Returned when the request body exceeds 10 MB.

503 — Service Unavailable

Returned when the service is temporarily unable to process requests. Retry with exponential backoff.

Partial acceptance

The Events API uses partial acceptance: valid users are processed even if other users in the same request fail validation. This means a single request can return 202 Accepted with both users_accepted > 0 and users_rejected > 0.
Always check the users_rejected field in the response. If it is greater than zero, inspect the errors array to understand which users failed and why.

Trace ID

Every response includes a trace_id. This unique identifier can be used to:
  • Correlate requests with RevBridge support for debugging
  • Log and track requests in your own systems
  • Match accepted events to their downstream effects
Store the trace_id from every API response in your logs. It significantly speeds up troubleshooting.

Examples

Simple event

Send a single purchase event for one user.

Batch request — multiple users

Send events for multiple users in a single request for better performance.

Multiple events per user

A single user can have multiple events in one request. This is useful for sending a batch of historical events.

Custom event properties

Any key-value pairs beyond the standard fields are stored as custom event properties.

User properties

Use user_properties to accumulate profile attributes over time. Unlike identifiers (which are set once), user properties are merged across events — the latest value for each key always wins. This is useful for tracking attributes that change over time and can arrive sparsely across different events.
User properties are accumulated over time using a last-write-wins strategy. If you send loyalty_tier: "gold" in one event and loyalty_tier: "platinum" in a later event, the profile will show "platinum". Properties not included in a request are left unchanged.
Key differences between identifiers, user_properties, and event properties: