Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.chipipay.com/llms.txt

Use this file to discover all available pages before exploring further.

Gift Cards are live. You pre-fund Chipi credits in USDC, mint a redeemable code, share it however you want, and the recipient claims into a Starknet or Solana wallet. Cross-chain delivery uses Circle’s CCTP bridge under the hood.

​
At a glance

Funded from credits

USDC held on Chipi’s Starknet treasury; created code is a claim on that hold

Two destination chains

Recipient picks Starknet or Solana at redeem time

Per-code limits

maxRedeems (total) + maxRedeemsPerUser

5 gift types

PROMOTIONAL, GIFT_CARD, REFERRAL, LOYALTY, COMPENSATION

​
How it works

  1. You create a gift code via POST /v1/gifts with an amount, expiry, and per-user/total redeem caps. Chipi holds the total potential payout (amount × maxRedeems) from your credits balance on creation, so no over-spend.
  2. You share the code any way you like — email, link in your app, QR. The code is the redeem key.
  3. A recipient redeems via POST /v1/gifts/claim/:code/redeem with their wallet address and target chain. Starknet recipients receive instantly; Solana recipients go through CCTP burn → Circle attestation → mint on Solana (status transitions visible via the redeem polling endpoint).
The redeem endpoint is public (no API key required) so the code itself is the access token — share carefully.

​
Endpoints

All under /v1/gifts/* on https://api.chipipay.com. Org-facing endpoints (create, list, stats) use ApiKeyGuard (sk_ in Authorization OR pk_ in x-api-key); claim/status endpoints are public.
Method + pathAuthPurpose
POST /v1/giftsApiKeyGuardCreate a gift code
POST /v1/gifts/bulkApiKeyGuardCreate N codes in one call
GET /v1/giftsApiKeyGuardList your org’s codes
GET /v1/gifts/:idApiKeyGuardSingle code detail
GET /v1/gifts/usageApiKeyGuardAggregate redeem stats for your org
GET /v1/gifts/history/redeemsApiKeyGuardList redeems against your codes
GET /v1/gifts/history/redeems/:idApiKeyGuardSingle redeem detail
GET /v1/gifts/claim/:codePublicRecipient previews the code (amount, expiry, etc.)
POST /v1/gifts/claim/:code/redeemPublicRecipient claims into their wallet
GET /v1/gifts/claim/:code/status/:redeemIdPublicRecipient polls redeem status
GET /v1/gifts/redeems/:id/statusApiKeyGuardOrg-side polling on a specific redeem

​
Cross-chain delivery

Recipient picksPathTypical latency
chain: "starknet"Direct transfer from Chipi’s Starknet treasurySeconds (one Starknet tx)
chain: "solana"CCTP burn on Starknet → Circle attestation → mint on Solana60–120 seconds (Circle attestation gates it)
The Solana path tracks state through GiftRedeemStatus: PENDING → BRIDGING (CCTP burn submitted) → ATTESTED (attestation received from Circle) → SUCCESS (USDC minted on Solana). Recipients poll the public status endpoint. If anything fails between BRIDGING and SUCCESS, the redeem moves to FAILED and the hold against your credits is released. You’re not charged for failed redeems.

​
Gift types

The type field on every gift is one of:
  • PROMOTIONAL — marketing campaigns, sign-up bonuses
  • GIFT_CARD — explicit gift product (e.g. a $25 USDC card)
  • REFERRAL — referral rewards
  • LOYALTY — repeat-customer rewards
  • COMPENSATION — refunds or make-goods
Chipi treats them identically functionally; the field exists for your own analytics + compliance reporting.

​
Where to go next

  • Quickstart — first POST /v1/gifts call to create a code, then claim it.
  • Endpoints — full request/response shapes per route.
  • Cross-chain — CCTP wire details, Solana recipient flow.
  • Dashboard — org-side admin: bulk create, view stats, retire codes.