> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reap.global/llms.txt
> Use this file to discover all available pages before exploring further.

# Working with Passes

> Purchase inventory, issue passes to cards and track lounge visits

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.

<Steps>
  <Step title="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
  </Step>

  <Step title="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
  </Step>

  <Step title="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
  </Step>
</Steps>

### 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.

<Tip>
  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.
</Tip>

## 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.

<Steps>
  <Step title="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
  </Step>

  <Step title="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
  </Step>

  <Step title="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
  </Step>
</Steps>

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

<AccordionGroup>
  <Accordion title="The endpoints">
    * `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
  </Accordion>
</AccordionGroup>

<Note>
  These guides stay at the level of names and purpose. Field level detail belongs to the API Reference.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Lifecycle and events" href="/airport-lounge-access/lifecycle-and-events">
    The four pass statuses, the card operations that move them and the webhook events
  </Card>

  <Card title="Airport lounge access FAQ" href="/airport-lounge-access/faq">
    Coverage, the plan, spending control and the questions prospects raise
  </Card>
</CardGroup>