> ## 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.
# Overview
> Declarative rules that control where, how much, and how often a card can be used.
A **policy** is a rule Reap enforces when authorizing a card transaction. You decide what is allowed, attach the rule at the right level of your program, and Reap applies it on every transaction in real time. You do not run your own authorization service, and you do not need to react to each transaction as it happens.
Reap makes the authorization decision. Policies are how you tell Reap what that decision should be.
## What you can control
Policies fall into two families.
Block transactions by **merchant** (category, specific merchant, or country) or by **channel** (in-store, online, ATM, push-to-card). Evaluated against the single transaction in front of it.
Cap a **single transaction** amount, total **spend over a period**, or the **number of transactions** over a period. Periods are calendar windows from daily through yearly, plus lifetime.
See [Control types](/spend-policies/control-types) for the full list and the configuration each one takes.
## How policies work
Every policy has three parts:
* A **type**, which decides what it checks (a merchant restriction, a spend limit, and so on).
* A **scope**, which decides what it applies to: your whole program, one cardholder, or one card. See [Scopes](/spend-policies/scopes).
* A **configuration**, the values specific to the type (the merchants to block, the amount cap, the window).
When a card is used, Reap gathers every active policy that applies to that card, from the card itself up through the cardholder and the program, and checks the transaction against all of them. If any one of them would block the transaction, it is declined. The strictest applicable rule always wins, so a permissive rule at one level can never loosen a stricter rule at another.
```mermaid theme={null}
flowchart TD
P[Program] --> U[Cardholder]
U --> C[Card]
C --> T[Transaction checked against
every policy at, above, or on the card]
```
A new card has no policies and is unrestricted, beyond the platform-enforced limits that apply to every program (see [ATM withdrawal limits](/transactions/atm-limits) and [Restricted MCCs](/transactions/restricted-mccs)). You add policies as you need them.
## When a policy declines a transaction
A blocked transaction is recorded as `DECLINED` with a `declineReason` code that identifies which kind of rule stopped it, and a `policy` reference that names the exact policy responsible. The reference is captured on the transaction at decline time, so it stays accurate even if you later edit or remove that policy.
```json theme={null}
{
"status": "DECLINED",
"declineReason": {
"code": "SPEND_LIMIT_EXCEEDED",
"message": "This transaction would exceed the spending limit on this card. Try a smaller amount or try again later."
},
"policy": {
"id": "9b7d3c2a-1f4e-4a2b-8c6d-0e1f2a3b4c5d",
"type": "SPEND_LIMIT",
"scopeType": "CARD",
"name": "Daily card limit"
}
}
```
See [Decline reasons](/transactions/decline-reasons#spending-policy-controls) for every code a policy can produce.
## Managing policies
| Operation | Endpoint |
| ------------------------------------------------------ | ----------------------------- |
| Create a policy | `POST /policies` |
| List your policies | `GET /policies` |
| See what's in force for a card, cardholder, or program | `GET /policies/effective` |
| Get a policy | `GET /policies/{id}` |
| Rename a policy | `PATCH /policies/{id}` |
| Replace a policy's configuration | `PUT /policies/{id}/config` |
| Stop enforcing a policy | `POST /policies/{id}/disable` |
| Resume enforcing a policy | `POST /policies/{id}/enable` |
### Editing a policy
Most of a policy can be changed in place. A few properties are fixed at creation, because changing them would change what the policy fundamentally is.
* Name, with `PATCH /policies/{id}`
* Status, via enable / disable
* Amounts, counts, merchants, and channels, with `PUT /policies/{id}/config`
* Type
* Scope
* A limit's calendar window
To change a fixed property, create a new policy and disable the old one. Replacing a limit's amount preserves recorded usage: raising a daily spend limit from `$500` to `$1,000` mid-day does not reset what has already been spent, it just raises the ceiling.
### Turning a policy off
To stop enforcing a policy, disable it with `POST /policies/{id}/disable`. A disabled policy is skipped during authorization but keeps its recorded usage, so re-enabling it with `POST /policies/{id}/enable` resumes from where it left off. Enabling an already-enabled policy, or disabling an already-disabled one, returns it unchanged.
## Seeing what applies and what remains
`GET /policies` lists the policies you created. To see the full set actually **in force** for one card, cardholder, or your program - including the policies inherited from a higher scope - use [List effective policies](/api-reference/policies/list-effective-policies). This is also how you read how much of each limit is left.
Pass the scope as query parameters: `scopeType` (`CARD`, `USER`, or `PROJECT`) plus, for `CARD` and `USER`, the `scopeId`. The response lists every active policy that applies, most specific first. Each spend or transaction count limit carries a `usage` object with the headroom remaining in the window and a `resetsAt` timestamp for when it rolls over; restrictions and per-transaction caps report `usage: null`. This is the endpoint behind a "how much can I still spend today?" view, and only active policies are returned. See [List effective policies](/api-reference/policies/list-effective-policies) for the full request and response shape.
## Next
Every policy type and the configuration it takes.
Where policies attach and how the effective set is resolved.