Send events
POST finished conversations from a stack of your own.
Use this when your stack has no connector of its own, or when you built the sender yourself.
The request
One POST with an ingest key. Every batch here is read with the generic contract, whatever platform the conversation came from. The event payload reference
bash
curl -X POST "https://app.evidova.com/ingest/v1/events" \
-H "authorization: Bearer ak_live_..." \
-H "content-type: application/json" \
--data '{"events":[{"thread_id":"contact-4812","type":"message.sent","ts":1755820800000,"payload":{"role":"assistant","text":"Your order ships tomorrow."},"source":{"platform_msg_id":"msg-7731"}}]}'The body is one event, an array of events, or an object with an events array.
The ceilings
| Body size | 8 MiB per request. Above that, 413, and use bulk import instead |
|---|---|
| Events per payload | 5000. A larger one is refused when we parse it, which is after the 202 has gone back, so split the batch before you send it |
| A client-limited key | Files the whole batch under that client |
What we send back
202, with the id we filed the body under. Nothing about scoring is in that answer: we parse and score after we have replied.
json
{ "status": "accepted", "raw_id": "..." }| 202 | Stored. Parsing and scoring happen after this. |
|---|---|
| 401 | The key is missing, revoked, or does not carry the ingest scope. |
| 413 | The batch is above 8 MiB. Send fewer events, or use bulk import. |
Read next
- Backfill history · Upload an export, so a score has history behind it from the first day.
- Connections · What a connection carries, why an API key cannot create one, and the two settings that decide whether it gets scored.
- Event payload reference · The event shape to send: required fields, accepted fields, and what happens to the rest.