Yes, you can automate gift card rewards through an API. When your system confirms that a user completed an action, one authenticated request to Giftronaut’s API places the order, and Giftronaut delivers the reward by email, text or reward link. Before it goes live you need a funded balance and approval for production access.
At a previous job, I once walked an engineer through how our survey rewards worked. A response landed in a sheet, someone eyeballed it, someone else bought the card, and a third person sent it. He listened to the whole thing, then asked, “So a human is the webhook?” I wanted to argue. I couldn’t.
If a person still has to notice that something happened before your rewards go out, an API can take over that job. (A webhook, in case the word is new, is the message one system sends another when something happens.) It comes with a few jobs of its own, though, and they’re easier to plan for before you build than after the first duplicate reward.
Your server confirms the action, places a Giftronaut order for the reward, and listens for the result. Giftronaut’s Gift Card API page names the triggers it’s built for: demo signups, referrals, registrations and product trials; survey and user-testing participants the moment they respond (more in automating gift cards after survey completion); in-app rewards; and rewards sent from your CRM.
Here’s the loop in five steps:
Giftronaut owns delivery, and your code owns the decision to reward. The diagram shows where each side’s job starts and stops.
You need four things: credentials, a funded balance, a reward to send and approval for production. Credentials are free and instant. The balance and the production approval are where launch dates slip, so start them early.
| Need | What it involves | What it means for your trigger |
|---|---|---|
| Sandbox | Create a sandbox app (the quickstart walks through it) and copy its client ID and secret. It has a virtual $10,000 balance, delivers no real cards or emails, and allows 300 requests a minute. | Build and break the whole flow without spending anything. |
| Production access | Create a separate production app. Giftronaut reviews every production account, and server-to-server access needs an IP allowlist. The docs say it’s typically enabled within 1 business day after the review. | Ask before launch week, and list every server that will call the API. |
| A funded balance | Orders are prepaid, and Giftronaut doesn’t extend credit. ACH typically takes 2 to 3 business days and wire 1 business day, counted from the day your bank sends the payment. Credit card deposits carry a 3% processing fee. | Treat the balance like inventory: when it’s empty, every reward stops. |
| A reward product | A Choice Card (the recipient picks a local brand) or a Branded Card (you pick the brand), each with a product ID from the catalog endpoint. | Pick one per trigger and store its product ID. |
A new account’s first deposit is held while the business is verified, and most reviews finish within one business day. For global apps, one more check: Giftronaut blocks access from 12 countries covered by US sanctions, and the block applies to the API as well as to redemption, so decide what your trigger does when a user is in one of them.
Create a free account, generate a sandbox API key and place test orders against a virtual $10,000 balance.
Give every order an idempotency key built from the event that earned it. Giftronaut requires the key on every order, and a key that has been used before is rejected with a 409 DUPLICATE_IDEMPOTENCY_KEY error and creates no second order. A duplicate event can’t pay out twice.
Think of the order slip on a diner’s ticket rail. When a second slip with the same number turns up, the cook knows it’s the same order, not another burger.
Say your app rewards a user with $10 when they finish onboarding, and your event system retries a delivery that timed out, so “onboarding complete” arrives twice for the same user. With a key like onboarding-reward-48213, the reward name plus the user ID, the second call is rejected and nobody is paid twice. With a fresh random value each time, you’ve just paid for two.
Three habits keep this reliable. Generate the key before the first request, not inside a retry loop. Save it with your own record of the reward. And read a 409 as “an order with that key already exists,” not “the order failed”: if a timeout leaves you unsure, look the order up with GET /api/v1/orders?clientOrderId= and your key first.
Three limits show up first: the request rate, your balance and your token. Production allows 60 requests a minute per credential, counted in a fixed 60-second window with no daily cap, so a burst of events needs a queue between your app and the API.
Picture a launch email that pushes 300 users through onboarding in a few minutes. At 60 requests a minute, placing 300 single-recipient orders takes at least five minutes, and anything over the limit gets a 429 response. Its rate-limit headers include the time the window resets, so a worker can wait and retry instead of dropping the reward. If a reward doesn’t need to land within seconds, one order can also carry many recipients, each with their own amount, which cuts the number of calls.
The balance is the second limit. A prepaid order the balance can’t cover is rejected with a 402 INSUFFICIENT_BALANCE and is not queued, so a user can earn a reward that never goes out unless your code notices. Check the balance (GET /api/v1/balance) before a big push, and alert someone when it runs low. A balance.low_balance webhook is listed as coming soon, so for now that check is yours to build.
The token is the third. Production access tokens expire after one hour, and this flow has no refresh token, so request a new one when the old one expires and reuse it between orders.
Register a webhook endpoint and subscribe to the order events, so Giftronaut tells you what happened instead of your code polling for it. Giftronaut signs every webhook with HMAC-SHA256, makes up to five delivery attempts, and expects a 2xx reply within five seconds.
Verify the X-Giftronaut-Signature header before you trust a payload, answer fast, and do the real work on a queue. Giftronaut can send the same event more than once, for example when you resend an order, so dedupe on the eventId the way you dedupe your own triggers.
One gap: webhooks don’t yet tell you whether a recipient actually redeemed. A recipient.redeemed event is listed as coming soon. For orders with the Refund Option, the Help Center points to Order Management, under Order History, for per-recipient redemption status.
Set the Refund Option on the order when you place it. In the API that’s two fields: refundOption set to true and refundOptionDays set to 30, 60 or 90. When the window closes, Giftronaut credits 50%, 40% or 30% of the unredeemed value back to your balance, compared with the default 180-day window, which has no refund.
Two conditions matter for an automated flow. The Refund Option has to be set when the order is placed, so you can’t add it later, and only fully unredeemed rewards qualify: once someone redeems a reward even partly, it can’t be reclaimed. A shorter window also means less time for the recipient (the deadline shows in their reward email), and Giftronaut doesn’t send reminder emails, so any nudge is your workflow’s job.
Which window? Giftronaut data from September 2026 shows 95.6% of redeemed rewards were redeemed within 30 days (45,162 redeemed rewards). That says nothing about rewards that were never redeemed, but for a reward tied to something a user just did, such as finishing a survey, a 30-day window with the 50% refund rate is a sensible place to start.
It sends Choice Cards and Branded Cards, plus prepaid cards for markets where local brand options are limited, from a catalog of 4,300+ brands to recipients in 225 countries. You choose the reward type per order, and each order can arrive in a few ways:
The Gift Card API page and the API docs cover each of these in detail. Still comparing providers? Our gift card API provider checklist lists what to verify in writing before you choose.
The engineer’s question has stuck with me. These days, when a team tells me rewards go out “after someone checks,” I ask what tells that person to check, and what happens on the day they’re out.
So start small. Pick the one trigger that fires most often, such as survey completions or first referrals, and wire only that into the sandbox. Then break it on purpose: send the event twice, empty the balance and fire a burst, and see what your code does each time. When duplicates, a 402 and a 429 all end quietly, request production access.
Book a demo to walk through your event, your volume and your production access request.
Yes. The sandbox is free and self-serve, with a virtual balance of $10,000 that resets when an order costs more, and no real cards or emails are issued. Orders still complete as they do in production, so you can test duplicate events and error paths, and going live means creating a production app, because your credentials decide which environment you reach.
Yes, with reward links. An order placed with the reward-links endpoint has no recipient email: the link itself is the access credential, returned on the order once its status is COMPLETE, so your app can show it to the user. Email orders do need the recipient’s address, which the recipient confirms before the card is revealed.
Yes. Giftronaut’s Zapier integration sends email rewards from thousands of Zapier triggers, such as survey responses, form submissions and CRM events, and orders placed through Zapier require approval until you switch that off in Control Center. To work through an AI assistant instead, see our guide to the AI-powered gifting assistant and Giftronaut’s MCP connection.
Giftronaut’s docs say production server-to-server access is typically enabled within 1 business day, after a team review that is a standard Know Your Business check for every production account. You request it from your production app and supply an IP allowlist of every server that will call the API. Until it’s approved, a production credential can’t get a token for REST calls.
Giftronaut’s API has no usage fees, platform fees or subscriptions, and you pay for the rewards you send. Funding your balance by credit card carries a 3% processing fee, while ACH and wire deposits carry none. Standard gift cards and prepaid cards have no redemption fee unless the brand’s own terms say otherwise, and Payout Options are the one product type with a redemption fee.
Yes. A single order can carry a list of recipients, and each one can have a different amount, so the Gift Card API page describes sending to thousands of recipients with one call. That helps with the 60-requests-a-minute production limit, but it suits rewards that can go out together, such as a nightly batch of survey completions, better than a reward that should land seconds after a user acts.