Documentation Index
Fetch the complete documentation index at: https://help-loyalife.xoxoday.com/llms.txt
Use this file to discover all available pages before exploring further.
Why Idempotency Matters
Network timeouts and ambiguous responses are unavoidable. Without idempotency, retrying a failed request can result in the same transaction being processed twice — awarding duplicate loyalty points. Loyalife’s transaction APIs support client-controlled idempotency via the_xoxo_api_client_idempotency field.
How It Works
- Generate once per logical submission — use an ID tied to the business event (e.g. purchase order ID, invoice ID, or a UUID you generate once for each intended processing attempt).
- Reuse on retries — if the first submission times out or returns an ambiguous response, retry with the same
_xoxo_api_client_idempotency. The platform will recognise the duplicate and not process it twice. - Generate a new ID for new submissions — only generate a new
_xoxo_api_client_idempotencywhen you genuinely intend a new business transaction.
transaction_id vs _xoxo_api_client_idempotency
| Field | Enforced as unique by LBMS? | Purpose |
|---|---|---|
transaction_id | No | Your business identifier for the row — used for your own reconciliation. |
_xoxo_api_client_idempotency | Program-dependent | Safe retry key — prevents double-processing on retries. |
Integration Checklist
Generate an idempotency key
Create a stable, unique key per logical business request — e.g. the purchase order ID.
On timeout or ambiguous response, retry
Reuse the same
_xoxo_api_client_idempotency. Do not generate a new one.On confirmed success or failure, move on
Use Poll Batch Status to confirm the outcome of a V2 batch submission.