Skip to main content
Three actions cover the whole operational journey. You purchase stock into the pool, issue passes to individual cards and watch visits land as cardholders redeem at the lounge. Each action below opens with what it does, then walks the steps involved.

​
Purchase inventory

Passes are purchased before they are issued. You submit a purchase request for a plan and a quantity, your Reap team reviews it, and approval loads the passes straight into your inventory pool. Nothing reaches the pool from a request that is still pending or rejected.
1

Submit the request

The request captures what you want to buy and nothing moves until it is decided.
  • Your application submits the reward type, plan name and quantity with POST /cards/rewards/request-purchase
  • Reap records the request as pending review and routes it to your Reap team
  • No passes are added at this stage
2

Reap reviews the request

Your Reap team approves or rejects the request and every request is decided exactly once.
  • Approval records the invoice detail and loads the purchased passes into your pool
  • Rejection records a reason and loads nothing
3

Receive the decision

The outcome lands on your webhook endpoint either way.
  • Reap delivers the decision through the PURCHASE_REQUEST_APPROVED or PURCHASE_REQUEST_REJECTED webhook
  • On approval, refresh your inventory and begin issuing
  • On rejection, surface the reason and raise a corrected request if needed

​
Reading your inventory

GET /cards/rewards/inventory returns your stock scoped to your business, with filters for reward type and plan name. Each row shows the purchased, consumed and available totals for the plan, with audit detail alongside.
The Reap dashboard shows the same counters read only and flags low stock once available passes fall below your threshold, which defaults to ten. Raise the next purchase request before the pool runs dry so issuance never has to wait on a review.

​
Issue a pass

One call issues a pass to an existing card. The call returns immediately, creation runs in the background on the lounge network, and the pass becomes active shortly after. A webhook announces completion so you can present the pass without polling.
1

Issue the pass

One call starts the whole journey and returns straight away.
  • Your application calls POST /cards/:id/rewards with the reward type and plan name
  • Reap validates the feature, the card ownership and the available stock, then queues creation and acknowledges immediately
2

Creation completes in the background

Reap creates the pass on the lounge network, and the step typically completes in around ten seconds.
  • Reap records the pass against the card and draws the pool down by one
  • A failed creation leaves no pass record and no net change to your inventory, so issue again
3

Present the pass

A webhook announces the pass so you never have to poll.
  • The PASS_CREATION_COMPLETED webhook fires once the pass is active
  • Your application fetches it with GET /cards/:id/rewards
  • The pass carries a raw QR payload and a barcode string rather than a ready made image, so generate the QR code from the payload and render both to the cardholder
When a single pass remains in the pool and two issuances race, exactly one succeeds. Counters never fall below zero, so a burst of issuance activity can never spend more stock than you hold. Every pass returned on the card includes what your app needs to display the benefit:
  • The status, one of active, redeemed, disabled or expired
  • The visit allowance and the visits already recorded
  • The raw QR payload and the barcode string for lounge entry
  • The recorded cost, the currency and the expiry date

​
Track redemptions

Entry needs only the QR code and barcode rendered in your app. The cardholder carries no separate membership card and completes no enrolment with the lounge network. Reap retrieves the lounge network report once a day and updates pass usage and visit records from it, so your app can always show whether a pass has been used. The pass turns redeemed once its visit is recorded. No client action is required.

​
The machinery behind the flow

  • POST /cards/rewards/request-purchase submits a purchase request for a plan and a quantity
  • GET /cards/rewards/inventory returns the purchased, consumed and available totals for your business
  • POST /cards/:id/rewards issues a pass to a card and queues creation on the lounge network
  • GET /cards/:id/rewards lists the passes on a card with status, usage and the QR and barcode payloads
These guides stay at the level of names and purpose. Field level detail belongs to the API Reference.

​
Next steps

Lifecycle and events

The four pass statuses, the card operations that move them and the webhook events

Airport lounge access FAQ

Coverage, the plan, spending control and the questions prospects raise