This guide takes you from zero to your first reward in about 15 minutes. Generate your token, confirm it works, send a test reward, and check its status. Everything runs in the Testbed sandbox, so there's no cost and nothing to break.
Note: make sure to review permitted use cases to ensure your program will qualify before you build.
Sign up for Testbed and log in.
Click your username (bottom left) → API Keys → Generate New Key
💡 Copy it somewhere safe. This token authenticates every request.
How will you deliver the rewards? The next steps depend on how you want the rewards to reach your recipients. There are two paths:
Email deliveryGiftbit sends the reward email for you. You'll create a template, then send to a recipient's email address. The least-code option, and the fastest first send. |
Link deliveryThe API returns a claimable reward link, and you deliver it however you like (your own email, SMS, in-app, Slack). No template required, more control over the experience. |
Not sure which fits your integration? The delivery methods guide compares all your options in detail. 💡If you just want to see a reward land, email is the quickest way to start.
Toggle between Email delivery flow and Link delivery flow for the next steps ↓
Include your token as a Bearer token in the Authorization header. Start with a read-only call to confirm auth works:
curl --include \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
'https://api-testbed.giftbit.com/papi/v1/ping'
You should get back a small JSON response confirming your token is accepted. Something like:
{
"username": "YOUR_USERNAME",
"displayname": "YOUR_DISPLAY_NAME",
"info": {
"code": "INFO_CREDENTIALS",
"name": "Credentials are valid",
"message": "The credentials used are valid and login attempt was successful."
}
}
If you get a 401 instead, it's almost always one of two things: a typo in the pasted token, or a missing Bearer prefix (with the space) before it in the header.
You are now authenticated!
If your integration will use Giftbit to deliver rewards to recipient contacts by email, you will need to create a template in your Testbed dashboard before you use the template in test orders. Log in and go to the Templates section. Create an API format template. You can control the look and feel of the email body by editing the template. You can override or omit details such as the brand(s) and face value in the template and declare them in your API request instead. Once the required sections of the template are complete, the dashboard will provide you with the ID for the template.
Note: Direct Links and Embedded Rewards requests do not require a template.
⚠️ Templates don't carry over to production, so you'll need to re-create these when you go live.
Now you're ready to send a reward against it via the API. Here's the minimal request:
curl --include \
--request POST \
--header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
--data-binary "{
\"gift_template\": \"WIHOWIPXXXX\",
\"contacts\": [
{
\"firstname\":\"Perry\",
\"lastname\":\"Johnson\",
\"email\":\"pjohnson@giftbit.com\"
}
],
\"price_in_cents\":2500,
\"brand_codes\": [
\"amazonus\"
],
\"id\":\"testorder1-email\"
}" \
'https://api-testbed.giftbit.com/papi/v1/campaign'
You should get back a response confirming the reward was created, including its ID:
{
"info": {
"code": "INFO_CAMPAIGN_CREATED",
"name": "Campaign Created",
"message": "Campaign creation has begun."
},
"status": 200,
"campaign": {
"company_name": "YOUR_COMPANY_NAME",
"message": "<p>Hi there, here is a complimentary signup incentive for a digital gift card of your choice.</p>\n<p><span>Click the Claim button on the brand of your preference shown below.</span></p>",
"subject": "Your incentive is here",
"contacts": [
{
"email": "pjohnson@giftbit.com",
"firstname": "Perry",
"lastname": "Johnson",
"message": "Contact ready"
}
],
"status": "API_CREATING",
"uuid": "ced5dbe0166f4bd58b9300f8284XXXXX",
"suppress_default_greeting": false,
"delivery_type": "GIFTBIT_EMAIL",
"price_in_cents": 2500,
"brand_codes": [
"amazonus"
],
"contacts_success_count": 1,
"contacts_failure_count": 0,
"fees": {
"cost_entries": [
{
"percentage": 0,
"fee_type": "PREFUND_GIFT_COST",
"amount_in_cents": 2500,
"currency": "USD",
"tax_type": "NOTAX",
"tax_in_cents": 0,
"number_of_gifts": 1,
"fee_per_gift_in_cents": 2500
},
{
"percentage": 50.000,
"fee_type": "BREAKAGE_PERCENTAGE",
"amount_in_cents": 0,
"currency": "USD",
"tax_type": "NOTAX",
"tax_in_cents": 0,
"number_of_gifts": 1,
"fee_per_gift_in_cents": 0
}
],
"subtotal_in_cents": 2500,
"tax_in_cents": 0,
"tax_type": "NOTAX",
"total_in_cents": 2500
},
"id": "testorder1-email",
"gift_template": "WIHOWIPXXXX"
}
}
Copy that ID. You'll use it in the next step, and in production. It's how your system tracks every reward it sends.
Where did the reward go? Testbed delivers all reward emails to your account email (the one you registered with) regardless of the recipient you specify. Check your inbox and you’ll see what your recipients will experience in production.
Look up the reward you just sent, using the ID from step 3:
curl --include \
--header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
'https://api-testbed.giftbit.com/papi/v1/campaign/{id}'
The response from /campaign shows the order’s status. Whether it's been delivered, claimed, or hit a snag. For example, a reward can come back as TEMPORARILY_UNDELIVERABLE, which is exactly the kind of state your system should watch for and act on (a resend clears it).
In production, this is how your system answers "did they get it? did they claim it?" The same endpoint lets you resend a reward (useful for an undeliverable one, or if a recipient deletes the email) or cancel it to reclaim the funds, as long as it hasn't been redeemed yet.
You can also access delivery status and claim status from /gifts using a similar request.
Here are examples of reward statuses:
DELIVERED the email-based reward was transmitted successfully
TEMPORARILY_UNDELIVERABLE the email-based reward cannot be delivered due to a soft bounce
UNDELIVERABLE the email-based reward cannot be delivered due to a permanent bounce
LINKCREATED the link-based reward was created
SENT_AND_REDEEMABLE the reward is waiting to be claimed
REDEEMED the reward was claimed
EXPIRED the promotional claim period has ended, the reward has not been claimed
GIVER_CANCELED the reward was canceled by the sender
And that's the full loop! You've authenticated, sent a reward, and tracked its status. Everything from here builds on what you've already done.
A couple of things worth knowing as you keep going:
Include your token as a Bearer token in the Authorization header. Start with a read-only call to confirm auth works:
curl --include \
--header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
'https://api-testbed.giftbit.com/papi/v1/brands'
You should get back a JSON response with brand codes you can use in later steps to create a test order. Something like:
{
"brands": [
{
"brand_code": "amazonus",
"name": "Amazon.com",
"image_url": "https://uploadedimagestestbed.giftbit.com/amazonus/amazonus5bcfc29b01ad4ecb961f857dcccbff8f-de5d493a-4f98-425a-bc2d-e55f32e543dd.png",
"disclaimer": "<p><strong>For testing purposes only.</strong> Reward availability, denominations, branding, and redemption flows may differ from Production. Certain rewards may not support full end-to-end testing or final user experience validation.</p><br><p>Restrictions apply, see <a href=\"https://www.amazon.com/gc-legal\">amazon.com/gc-legal</a>.</p>"
},
{
"brand_code": "walmart",
"name": "Walmart",
"image_url": "https://uploadedimagestestbed.giftbit.com/walmart/walmart-f9dc09fe-b60a-4384-87d1-7c047a844539.png",
"disclaimer": "<p><strong>For testing purposes only.</strong> Reward availability, denominations, branding, and redemption flows may differ from Production. Certain rewards may not support full end-to-end testing or final user experience validation.</p>"
},
{
"brand_code": "marqetavisavirtual",
"name": "Visa Incentive Virtual Card",
"image_url": "https://uploadedimagestestbed.giftbit.com/marqetavisavirtual/VisaLogoUSBluee8fbe7aa7aa34f42b58ac4318817b55f-fbb66aa8-7073-44ce-a8b3-0caa570b2eab.png",
"disclaimer": "<p><strong>For testing purposes only.</strong> This test reward simulates USD Prepaid Visa. The Prepaid Visa Incentive card is issued by Sutton Bank, Member FDIC, pursuant to a license from Visa U.S.A. Inc. Click <a href=\"https://giftbit.com/visa-terms/accountholder-agreement\">here</a> to view the Prepaid Visa Incentive Cardholder Agreement.</p>",
"expiry_period": "12 months"
}
]
}
If you get a 401 instead, it's almost always one of two things: a typo in the pasted token, or a missing Bearer prefix (with the space) before it in the header.
You are now authenticated.
Ordering Direct Links is relatively simple: declare a face value and a single brand, or a face value and a region (to offer all the compatible brand options for that region). You can set the claim period by declaring an expiration date, or omit the parameter to create a non-expiring link. Each Direct Link request creates one claimable link.
Note: If you want to request a single brand or a customized list of brands, you can use the brand codes from your test of the /brands endpoint in the previous step.
curl --include \
--request POST \
--header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
--data-binary "{
\"id\":\"testorder2-directlink\",
\"price_in_cents\": 2500,
\"region\": \"USA\",
\"link_count\": 1
}" \
'https://api-testbed.giftbit.com/papi/v1/direct_links'
You should get back a response confirming the reward was created, including its ID:
{
"info": {
"code": "INFO_CAMPAIGN_CREATED",
"name": "Campaign Created",
"message": "Campaign creation has begun."
},
"status": 200,
"direct_links": [
"https://testbedreward.giftbit.com/getReward/dl-58f3979b4d5e4496b3fb168e4f7eXXXXX"
],
"campaign": {
"company_name": "Giftbit",
"message": "Direct link to your reward.",
"subject": null,
"contacts": null,
"status": "API_CREATING",
"uuid": "cfd860a8e44e41a293b017f54c9XXXXX",
"suppress_default_greeting": false,
"delivery_type": "DIRECT_LINK",
"region": "USA",
"fees": {
"cost_entries": [
{
"percentage": 0,
"fee_type": "PREFUND_GIFT_COST",
"amount_in_cents": 2500,
"currency": "USD",
"tax_type": "NOTAX",
"tax_in_cents": 0,
"number_of_gifts": 1,
"fee_per_gift_in_cents": 2500
},
{
"percentage": 100.000,
"fee_type": "BREAKAGE_PERCENTAGE",
"amount_in_cents": 0,
"currency": "USD",
"tax_type": "NOTAX",
"tax_in_cents": 0,
"number_of_gifts": 1,
"fee_per_gift_in_cents": 0
}
],
"subtotal_in_cents": 2500,
"tax_in_cents": 0,
"tax_type": "NOTAX",
"total_in_cents": 2500
},
"id": "testorder2-directlink"
}
}
Copy that ID. You'll use it in the next step, and in production it's how your system tracks every reward it sends.
How to view the reward: The response from /direct_links includes a URL that will take you to the claim steps for the reward. Testbed simulates the claim experience and code reveal step in case you want to try claiming a test order. In Production you’ll send the link to your recipient contact using your choice of delivery method (email, SMS) or reveal the link in your app.
Look up the reward you just created, using the ID from step 3:
curl --include \
--header "Content-Type: application/json" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept-Encoding: identity" \
'https://api-testbed.giftbit.com/papi/v1/gifts?campaign_uuid={id}'
The response shows the reward's lifecycle state. In production, this is how your system answers "did they claim it?"
LINKCREATED the link-based reward was created
SENT_AND_REDEEMABLE the reward is waiting to be claimed
REDEEMED the reward was claimed
EXPIRED the promotional claim period ended, the reward was not claimed
GIVER_CANCELED the reward was canceled by the sender
Before you build out your integration, choose whether rewards reach recipients by link, by Giftbit-sent email, or embedded in your app.
Fake balance, real API. Test as much as you want; rewards aren't redeemable.
Sample brand catalog. Production has the full list (giftbit.com/rewards).Before launch, review the API Production Checklist: Go Live Guide
You'll need to sign up for a production account.
Note: reward templates do not carry over to the live environment so you will need to recreate them in your new live account.
Developers can start using the Giftbit gift card API by reading the API documentation, and then setting up their free Sandbox account. There are no API usage fees - just a fast and flexible start with gift card API software.
If you are a program manager or other stakeholder, simply direct your developer to this Giftbit API page.
Everyone is also free to book time with Matt Brossard, our integration specialist. Our team has dedicated technical and business resources to help you determine the best path to get started.
You can attach any custom information you want to associate with a reward, such as time stamps, transaction numbers, campaign IDs, or user identifiers by embedding those details in the user supplied ID. The ID parameter is a custom identifier used in your API requests that accepts a long string.
Each request ID is idempotent, meaning every value needs to be unique from request to request. Keep this in mind when designing the ID you will include in your API requests.
Yes, you can pull order history and status from the API.
Specifically, you can access order processing status and delivery information using the /campaign endpoint
You can pull campaign records using either your request ID, or the system generated UUID provided by Giftbit when you create a reward.
Similarly, you can pull individual reward records using either your request ID, or the UUID provided by Giftbit.
And you can access redemption status from the /gifts endpoint.
Refer to the API documentation for more instructions on how to utilize appropriate record identifiers in GET requests, or email testbed@giftbit.com.
Yes, everyone who uses Giftbit can choose to give their recipients a customized selection of brands, or a single brand per reward. You also have the option to give your recipients access to the full global catalog.
To send a single brand, your API request will contain only one brand code.
To send a customized choice of brands, your API request will contain a list of brand codes.
To send a reward with the full catalog, your API request will contain a region and a price, but you will omit the brand code(s).
Refer to the API documentation for more detail about constructing working requests.
GET /brands returns a list of reward brands available from Giftbit, including detailed information like the brand_code and an allowed price to include in your API calls. Some brands only allow certain fixed values, while others have an allowed range.
You can restrict the results list with any combination of price, currency, region, or search terms.
By default, all rewards delivered using the API are non-expiring. You’ll also have the option to provide an expiration date in your API call, to limit the period in which your recipients can choose a reward or reveal a card.
Learn more about how delivery methods affect catalog features.
The Giftbit gift card and prepaid card API allow for link-based reward delivery. There are two types of links you can use here: direct_link or shortlink
Direct links go straight to the reward itself, so you don’t need to add extra messaging or branding. They’re best for tasks like merging into emails delivered by a system other than Giftbit, where you don’t need to provide your recipients much added context.
Use the /direct_links endpoint to request direct link rewards.
Alternatively, shortlinks will first direct your recipients to a landing page which includes your company logo, as well as your custom message. These are often used for delivering shorter messages via SMS or social channels, or any time you need to provide your recipients more context.
Use the /campaign endpoint along with the delivery_type: SHORTLINK property to request shortlink rewards.
To trigger an email delivery reattempt, make a PUT request to the /gifts endpoint to manage the reward lifecycle and fulfilment functions.
Many developers use the Giftbit API specifically because they need white label options. To create a white label experience, we recommend using direct links, which are fully embeddable, have neutral looking presentation, and contain minimal instances of references to Giftbit.
Reach out if you have any more questions.
We work hard to keep Giftbit up and running, aiming for at least 99.95% uptime every month. In practice, we've done even better, averaging around 99.99% over the past two years.
Giftbit conducts a standard Know Your Business (KYB) review and use-case assessment for all new accounts.
KYB is the mandatory due diligence process financial institutions use to verify the legal identity, ownership structure, and beneficial owners of a business entity.
Broadly, the criteria for Giftbit is:
If you have concerns about the eligibility of your program, please reach out to sales@giftbit.com for review.