Sending activities
POST /v1/activities takes a batch of activities in the envelope, with any write key. The catalogue says which activities each key class may send; each activity page says it too, and carries its own example and form.
{
"debug": true,
"batch": [
{
"activity_id": "0192f1a4-7c3e-7b21-9d0a-5e3f8c2a1b45",
"activity": "made_cashless_payment",
"ts": "2026-10-17T21:14:05+02:00",
"identifiers": [{ "type": "chip", "value": "WB-0093", "namespace": "payvent" }],
"revenue": { "amount": "7.50", "currency": "EUR" },
"features": { "event_id": "3a114ef5-6105-48fd-aafc-0ae609d0536c", "point_of_sale": "Bar 3", "category": "drinks", "transaction_id": "trx_01M4XVBYC3FGXCPFRZEPGV20RZ" }
}
]
}
| Body field | Meaning |
|---|---|
batch | One or more activities. The request is accepted or refused as a whole. |
writeKey | A browser key, for a sender that cannot set the Authorization header. |
traceparent | W3C trace context, for a sender that cannot set the header. |
debug | Return the processor's verdict for each activity. |
What comes back
202 with accepted (how many activities are stored), trace_id and, with debug, verdicts: per activity accepted or quarantined with the reason and detail, the schema version it was checked against, and observed when the key is in observe mode. See validation for the reasons and for what is refused instead.
Idempotency and retries
Send the same activity_id twice and the second is dropped, however long after the first. Derive the id from the thing itself (uuidv5(system, record, activity) works well) and any retry is safe. On a 503 or a network error, retry the whole batch.
Try it
A cashless payment with a server key.
Sends this request from your browser. The key and the endpoint are kept in this browser only.