Giftbit API Production Checklist
From Testbed to live
From Testbed to live
This checklist covers everything required to move a Giftbit API integration from the Testbed sandbox to production: hardening your error handling, requesting production access, and completing the go-live steps.
ERROR HANDLING & RELIABILITY
Wire up the /gifts endpoint. Full lifecycle per reward, including claimed/unclaimed. If your system needs to answer "did the recipient get their reward?", this is the endpoint.
/funds returns your real-time account balance. You can monitor your campaigns to make sure they don't drain your account mid-send.
Adaptive rate limiting allows burstiness, so valid usage rarely hits limits, but retry with backoff when you do. Test it without generating load: pass SIMULATE-RATELIMIT: true on any Testbed request.
Retry 5xx and timeouts safely: include a unique supplied ID on every send. If the original went through, the retry won't create a duplicate.
Invalid recipient details, and a reward option becoming unavailable between catalog fetch and send. Handle both and your fulfillment never silently stalls.
Request an unavailable brand. Trigger the simulated rate limit. If your error paths work in Testbed, production won't surprise you.
Once your integration handles the essentials above, the next step is getting your production credentials. Fill out the access request form and our team will assess and enable your account.
MOVING FROM SANDBOX TO GOING LIVE IN PRODUCTION
Register for a production account here. It's separate from your Testbed login.
Request production API access. Complete this form.
API permissions, like new accounts, go through a standard Know Your Business review. We recommend applying for access 2-3 days before target live date. You can expect a reply from the team on business days within 24 hours.
Once approved by the Giftbit team, you’ll have access to your production token. Getting your live token follows the same flow as Testbed: Username (bottom left) → API Keys → Generate New Key.
Change the web address your code sends its API requests to. That address has two parts: a base URL (the root — the same on every request) and a path (the specific endpoint, which changes per call).
https://api-testbed.giftbit.com /papi/v1/funds
└─── base URL ──┘ └── path ──┘
Testbed and production are isolated environments, so any reward templates you built while testing don't carry over. You'll recreate them in your live account. Your integration code is unaffected; this is account configuration, not code. This only applies if you will be using Giftbit to send the emails. Not necessary for Link-based sending or embedded rewards.
/brandsTestbed shows only a sample of the brand catalog while production has the full list. Call the /brands endpoint in production to get complete, current reward data like brands, denominations, and details. Fetch them dynamically so your catalog stays accurate as brands change.
Production rewards draw down from a real balance, so add funds before your first send. Bank transfer carries no fee; credit card carries a 2.9% fee. Rewards cost face value (no platform fees or minimums). If you are a high-volume sender you will be eligible for discounts, custom pricing and revenue sharing. Talk to the team for details.
If you are using Giftbit-sent rewards, we recommend you do one real send to an email address you control before going to full capacity. It's the only way to confirm the full production path end-to-end: live token, live funding, real delivery, real redemption.
/gifts endpoint to track the full lifecycle of any reward, including whether it's been delivered and whether the recipient has claimed it. Look up a reward by the ID returned when you created it, and the response shows its current status. The same endpoint lets you resend or cancel individual rewards. If your system needs to answer "did the recipient get their reward, and did they use it?", this is the endpoint to build against.
/funds endpoint to retrieve your real-time account balance. Production rewards draw down from your funded balance, so it's worth setting up an alert against a minimum threshold, that way a large campaign can't drain the account and start failing mid-send. Checking /funds is also the simplest read-only call to confirm your API authentication is working.
429 response — handle it by retrying with exponential backoff rather than immediately re-sending. You can test your retry logic in the sandbox without generating real traffic by adding the header SIMULATE-RATELIMIT: true to any Testbed request, which forces a simulated 429.
Include a unique supplied ID on every reward request, and retries become safe: if the original request already succeeded, retrying with the same ID won't create a duplicate reward. This matters most after a timeout or a 5xx server error, where your system can't tell whether the original send went through.
Without a supplied ID, a retry in that situation risks sending a reward twice. With one, you can retry confidently. Retry 5xx and timeout errors with backoff. If failures persist, contact support.
Treat any non-200 response as an error. Giftbit's API returns an HTTP 200 only when a request genuinely succeeds, so your integration should handle every other response as a failure. Log the full JSON error body, since the Giftbit support team needs it to help troubleshoot. The error response follows a consistent JSON format with a message explaining what went wrong.
From there, handle the standard retry cases: retry 429 (rate-limit) and 5xx (server) responses with backoff, and watch for the two failures that occur most often in real use: invalid recipient details, and a reward option becoming unavailable between the time you fetch the catalog and the time you send. As a general rule, validate recipient data before sending, and fetch brand availability fresh rather than relying on cached catalog data. Handle these and your fulfillment won't silently stall.
The Testbed sandbox lets you trigger error conditions deliberately, so you can confirm your error paths work before going live. Send a reward to an invalid recipient, request a brand that isn't available, and force a rate-limit response with the SIMULATE-RATELIMIT: true header.
Because Testbed runs on a virtual balance, all of this is free and carries no risk. If your integration handles these cleanly in the sandbox, production won't surprise you.
Yes. You can either fund your account in multiple currencies and send rewards to recipients across regions. Or, set a default currency for your account, and when you send to a region that uses a different currency, Giftbit automatically converts it for you for free. So, you can fund in one currency and power a global program.