AttendBeacon
Open the workspace

Concepts

Idempotency

Send an Idempotency-Key with a POST, and a retry after a lost connection is answered with the first answer instead of registering somebody twice.

Why

A connection can drop after AttendBeacon registered somebody but before your code heard so. Sent again, the same POST would issue a second ticket. With an Idempotency-Key it does not: the second request gets the first one's answer.

How

Make a key of your own for each request (a UUID is ideal) and send it with the POST. Keep it with the request until you have an answer, and send the same key with every retry.

curl -X POST "https://attendbeacon.com/api/v1/events/b3ac0000-0000-4000-8000-000000000001/registrations" \
  -H "Authorization: Bearer $ATTENDBEACON_KEY" \
  -H "Idempotency-Key: 6f1c2a9e-4b7d-4c0f-8e3a-5b9d1c7e0f42" \
  -H "Content-Type: application/json" \
  -d '{ "ticketTypeId": "b3ac0006-0000-4000-8000-000000000001", "firstName": "Anna", "lastName": "de Vries", "email": "anna.devries@example.com" }'

What is kept, and for how long

The first answer to a key (its status, Location and body) is kept for 24 hours and given again to any request with the same key, method, path and body. A replayed answer carries Idempotent-Replayed: true.

SituationAnswer
A retry of a request that was answeredThe first answer, with Idempotent-Replayed: true
A retry while the first is still being handled409 idempotencyKeyInUse, with Retry-After: 1
The same key with another method, path or body422 idempotencyKeyReused: use a new key for a new request
A key longer than 255 characters, or with spaces400 invalidIdempotencyKey
The first request failed on AttendBeacon's side (5xx)Nothing is kept, so the retry is handled afresh

A key belongs to the API key that sent it: two integrations cannot collide. The answers kept may name a person; when that person deletes their data, the answers naming them are deleted too.

Which calls

Every POST takes an Idempotency-Key: registering, issuing tickets, cancelling, checking in, creating events, sessions, discount codes and webhooks. PATCH, PUT and DELETE are safe to repeat by their nature; PATCH takes If-Match instead, so a change made in between is not overwritten (Errors, preconditionFailed).

The guides and this site are in your language. The API reference's own descriptions are in English, as the API itself speaks.