Send events

Records a batch of events, returning a result per item.

The one way to send an event; a single event is a batch of one.

Batch whenever you can. Fifty events in one request cost little more than one event on its own. Sending them one at a time is the slowest way to use this endpoint.

An event or property the environment has not defined is refused (event.not_found, event.unknown_property) unless the environment has discovery switched on in the dashboard, in which case it is defined from this occurrence: the type is the JSON kind, a date is a string until declared, and a discovered property is optional. Once defined, the type holds either way.

A 200 does not mean everything was accepted. Items are independent: each is applied or refused on its own and reported in results, in the order submitted. Check rejected, or the per-item accepted flag. The response is only non-2xx when the batch itself is malformed (empty or over the size limit), or when other requests kept creating the same players at the same instant (409 event_batch.concurrent_update, nothing written, send it again). Sending from several of your own workers at once, and retries that overlap the request they retry, are expected and are sorted out for you; the 409 is the rare case left over.

A number keeps 8 decimal places and up to 20 digits before the point. Anything wider is refused per item (event.property_value_out_of_range); send an identifier as a string.

Send an idempotencyKey per item if you retry. Retrying a partially-accepted batch re-sends the accepted items too; with a key they replay, without one they apply twice.

Response Body

curl -X POST "https://example.com/v1/events" \  -H "Content-Type: application/json" \  -d '{    "events": null  }'

{  "accepted": 0,  "rejected": 0,  "results": [    {      "index": 0,      "accepted": true,      "eventId": null,      "errors": [        {          "code": "string",          "message": "string"        }      ]    }  ]}