Pagination and retries

Lists return has_more and next_cursor. Pass the cursor back to continue. Treat it as opaque — it encodes a position, not an offset, so nothing is skipped or repeated when rows are added mid-page.

curl "https://app.360nook.com/api/v1/contacts?limit=100&cursor=$NEXT" \
  -H "Authorization: Bearer $KEY"

Retrying safely

The network cannot tell you whether your request never arrived or the response never came back. Retrying is the only thing you can do — so send an Idempotency-Key on writes and we make sure the work happens once.

curl -X POST https://app.360nook.com/api/v1/contacts \
  -H "Authorization: Bearer $KEY" \
  -H "Idempotency-Key: order-8f3a-2026-09-07" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","first_name":"Ana"}'

Retry it and you get the original response back, byte for byte, with Idempotent-Replay: true added. No second contact.

• Any unique string, up to 255 characters. Keys are remembered for 24 hours and scoped to your credential, so your order-42 can never collide with another app’s.
• Reuse a key with a different body and you get 422, not the old response — replaying there would mean your second, genuinely different write silently never happened.
• Two identical requests at once: one proceeds, the other gets 409. Retry in a moment without changing the body.
• If the request fails, the key is released. One bad attempt does not burn it.

Without an idempotency key, a retried webhook or a redelivered queue message creates the record twice. It is the most common cause of duplicate contacts in any integration, and it is why this header exists.