Skip to main content
The Auto-claim as Fallback pattern handles the case where a recipient receives a gift but doesn’t claim it — perhaps they missed the notification, the email went to spam, or the deadline passed. Instead of letting the gift expire, you claim it on their behalf and fulfill it directly.

Prerequisites

  • API key with gifts:create (to create the gift) and orders:create (to claim it) scopes
  • A plan for what product to order on the recipient’s behalf (store this at gift creation time)
  • A mechanism to watch for gift-status-changed webhooks

The flow

  1. Create the gift with POST /v2/gifts and store your fallback plan (product/variant + recipient address) in your own database, keyed by giftId.
  2. Watch gift-status-changed webhooks. If the recipient claims the gift themselves, cancel your fallback plan — the gift is handled.
  3. Trigger auto-claim after your deadline (e.g., N days after creation) if the gift is still unclaimed.

Store the fallback plan at creation time

When you create the gift, immediately record what you’ll order if the recipient doesn’t claim it:
JavaScript

Cancel the plan if the recipient claims

Subscribe to gift-status-changed webhooks. When a gift’s status changes to claimed (or any terminal state that means the recipient acted), mark your fallback plan as cancelled:
JavaScript

Trigger auto-claim

After your deadline, if the fallback plan is still pending, claim the gift:
JavaScript
Python

409 handling

The claim endpoint returns 409 Conflict in two distinct situations:
JavaScript
Both 409 cases are terminal — retrying will not succeed. Handle them gracefully without alerting as errors.
Last modified on July 27, 2026