reconify-python batches events, reads every item result,
retries without duplicating evidence, and carries provider lookup data where a payment
integration exists. This page covers all four.
Build an event batch
A batch carries between 1 and 500 events. Events from the same business operation share areference, and entity_id identifies the wallet, order, or other entity the flow
monitors.
amount from Decimal, never from floating-point
arithmetic for money.
Send the batch
One call submits the whole batch:Handle every result
The response carries one result per input event, in the same order:accepted: Reconify stored the event.duplicate: Reconify already stored the same ID and payload. Treat it as delivered.rejected: Reconify did not store that item. Fix the field or identity conflict before sending it again.
202 when some items are rejected. Do not treat a
successful request as proof that every item was accepted. Avoid logging the
event payload, reference, entity_id, or amount.
Retry delivery safely
The SDK does not retry ingestion by default. Enable POST retries only when every event in the batch has a stableid and you will resend the same payload.
duplicate when an earlier attempt stored the event. Reusing
an ID with different content returns idempotency_conflict, which points at the
producer’s identity mapping rather than at delivery, so an unchanged retry solves nothing.
Add payment provider data
After you configure a payment integration in the dashboard, copy its opaque integration reference into apayment.initiated event:
integration_ref selects the saved connection. The provider transaction ID or
reference tells Reconify what to look up. See Payment integrations
for supported lookup fields and connector behavior.
Next
Send events
The language-neutral contract, results, and retry rules.
Prepare for production
Review batching, security, observability, and operations.