The gift-card API for AI agents: cartapi vs Tremendous, Giftbit, Givex
Tremendous, Giftbit, and Givex are excellent gift-card APIs for HR reward platforms and marketing incentives — use cases where your service holds the payment credential and sends codes to end users. None fit AI-agent-triggered purchases, where the buyer is an LLM and the credential can't safely live server-side. cartapi is the MCP-native entrant: agent calls search_gift_cards and get_checkout_link, gets back a Stripe URL, the human clicks and pays. Consent-first, merchant-of-record, no card on file. Swap it in over an afternoon if the buyer is an agent; keep Giftbit if the buyer is your batch job.
If you googled "gift card api" this week, every top result was Tremendous, Giftbit, Givex, Neocurrency, or Shopify's own storefront-oriented endpoint. All excellent products. None built for the agent buyer.
Here's the honest comparison, from someone who ships one of them.
The four camps of gift-card API
| Camp | Examples | Buyer model |
|---|---|---|
| HR / rewards | Tremendous, Giftbit, Rybbon | Your service holds a funded balance; you send codes as user rewards. |
| Retail POS integration | Givex, Blackhawk, InComm | Physical + digital, redemption tracking, chain-wide. |
| Wholesale catalog | Reloadly Gift Cards, Bitrefill (crypto) | Raw card-code catalog; you build the buying UX. |
| Agent-native | cartapi | MCP tool surface; buyer is an LLM; consent-first Stripe checkout. |
Each camp is right for a different job. Confusion sets in when a team building an AI agent shops the HR-rewards camp because that's what Google surfaces first.
Feature-by-feature comparison
| Feature | cartapi | Tremendous | Giftbit | Givex |
|---|---|---|---|---|
| MCP-native tools | Yes (search_gift_cards, get_checkout_link) | No (REST only) | No (REST only) | No (SOAP/REST) |
| Consent-first checkout | Every purchase returns Stripe URL | Server-signed send | Server-signed send | Server-signed |
| Merchant of record | Yes — cartapi on statement | No — you are MoR | No — you are MoR | No — you are MoR |
| Card-on-file required | No | Prefunded balance | Prefunded balance | Merchant terms |
| Brand coverage | Reloadly catalog (hundreds) | 1,000+ across categories | ~600 | Chain-specific |
| Country coverage | Reloadly footprint (~150) | 200+ (via prepaid partners) | ~30 | Depends on merchant |
| Best for | AI agent triggering a purchase for a human | HR rewards, marketing incentives | Survey / research payouts | Enterprise POS integration |
Coverage numbers are approximate and shift monthly; check each vendor's live catalog before committing.
The consent-first difference, spelled out
A Giftbit or Tremendous integration typically holds a prefunded balance in your account. When your service wants to send a $50 Amazon card, you call POST /gifts with the SKU and recipient email. The balance debits, the card sends. No user interaction.
That model is elegant when the sender is your batch job. It's radioactive when the sender is an LLM agent whose context can be prompt-injected. One poisoned instruction inside a scraped web page becomes fifty $50 Amazon cards to an attacker inbox.
cartapi solves this by not holding a balance. The MCP tool returns a signed, single-use Stripe URL. The user opens their browser, sees the amount, sees the recipient, sees the cartapi statement descriptor, clicks pay. Every purchase requires human proof-of-life.
See Consent-first checkout: why your AI agent should never see the card for the threat-model derivation.
Integration effort, side by side
Giftbit (existing)
POST https://api.giftbit.com/papi/v1/gifts
{
"brand_code": "amazon_us",
"price_in_cents": 5000,
"contacts": [{ "firstname": "Anna", "email": "[email protected]" }]
}Prerequisites: Giftbit account, prefunded balance, API key. Your service is on the hook for tax, dispute defense, and the money sitting in the account.
cartapi via REST (agent-agnostic)
GET https://api.cartapi.io/v1/products/search?category=giftcard&country=US&brand=Amazon
POST https://api.cartapi.io/v1/checkout/session
{
"sku_id": "gc_amzn_us_50",
"buyer_email": "[email protected]"
}
-> { "checkout_url": "https://checkout.stripe.com/c/pay/cs_..." }Redirect the user to the URL. Stripe charges. Fulfillment webhook fires. Done. No balance, no tax filings, no chargeback defense.
cartapi via MCP (agent-native)
agent tool call:
search_gift_cards(country="US", brand="Amazon", min_amount_usd=45)
-> [{ id, brand, amount, currency, ... }]
get_checkout_link(sku_id=..., buyer_email="[email protected]")
-> { checkout_url: "https://checkout.stripe.com/c/pay/cs_..." }
get_order_status(order_id)
-> { status: "fulfilled", code: "..." }Zero glue code between agent and API. Add cartapi to Claude Desktop with one command and it works.
When to pick which
- Building a survey-payout platform — Giftbit or Tremendous. They handle batch, they handle balance, they've solved the problem for a decade.
- Sending $500/mo of employee gifts — Tremendous. Best UX for the sending admin.
- Enterprise loyalty program with in-store redemption — Givex.
- Building a chat agent that occasionally buys a gift — cartapi. The consent-first URL is the whole point.
- Building an MCP server of your own that needs gift cards as a subroutine — cartapi. MCP-to-MCP composition works out of the box.
- Crypto-first gift-card buyer — Bitrefill. cartapi is Stripe-only today.
- Deep Shopify-store integration — Shopify's native gift-card GraphQL API. cartapi doesn't touch storefront-issued cards.
What cartapi doesn't do (yet)
- No prefunded balance: every purchase is a fresh Stripe checkout. Great for consent; bad for high-frequency automated sends.
- No bulk send API: cartapi is one-code-per-purchase by design. If you want to send 500 codes in a batch, use Giftbit.
- No custom-brand gift cards: cartapi sells the Reloadly catalog. If you want to issue your own storefront card, you want Shopify or Blackhawk.
- No crypto payment: Stripe-only today. Crypto is on the roadmap via Stripe's Bitcoin support once it's more widely enabled.
These aren't limitations to hide — they're the corollary of the design choices. Consent-first + MoR + MCP-native lands you exactly here.
Try it in one command
claude mcp add --transport http cartapi https://mcp.cartapi.io/mcpThen in Claude Desktop:
using cartapi, list the gift card brands available in the US.
The agent calls list_gift_card_brands(country="US") and reads the catalog back. Follow up with:
get me a $50 Amazon US gift card, email it to [email protected].
You'll get a Stripe URL. That's the whole loop your users will experience.
Frequently asked questions
What is a gift-card API?
A programmatic interface for purchasing, delivering, and managing gift-card codes across many brands and countries. Big vendors: Tremendous, Giftbit, Givex, Reloadly. Platform-specific: Shopify, Google Play, Amazon Incentives. cartapi is the MCP-native entrant purpose-built for AI-agent-triggered purchases.
How is cartapi's gift-card API different from Tremendous or Giftbit?
Three differences: MCP-native so agents can call directly, consent-first checkout (every purchase returns a Stripe URL), and merchant-of-record for the whole transaction. Tremendous/Giftbit/Givex assume the calling service holds a payment credential — a bad fit when the caller is an agent.
Can I replace Giftbit with cartapi in an existing app?
For agent-triggered use cases, yes — swap the Giftbit send-gift call for cartapi's search_gift_cards + get_checkout_link, redirect the user to the Stripe URL. For batch HR-reward jobs with your own credential, keep Giftbit.
What brand catalog does cartapi cover?
Reloadly's catalog — Xbox Game Pass, PSN, Steam, Nintendo, Riot, Amazon, Uber, DoorDash, Apple, Google Play, and hundreds more. Coverage varies by country. list_gift_card_brands enumerates the live list.
Does cartapi support crypto payment?
Not yet — Stripe-only today. Crypto is on the roadmap once Stripe's Bitcoin flow reaches wider availability. For crypto-first buying today, Bitrefill is the incumbent.