> ## 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.
# Changelog
> New endpoints, webhook events, and behavior changes in the Reap API.
Every change here is backwards compatible unless an entry says otherwise. Breaking changes
ship under a new `Reap-Version`, described in [Versioning & Compatibility](/api-reference/versioning).
### Cards can be blocked and unblocked directly
[Block a card](/api-reference/cards/block-card) puts a hard stop on it, declining every attempt
online, in-store, and at the ATM, separate from freezing it. [Unblock a card](/api-reference/cards/unblock-card)
lifts a block you or Reap placed, when it can be lifted. The card resource now includes
`blockLiftable`, which tells you whether unblock will work before you call it, and `frozen`, which
reports a freeze that a block is currently hiding from `status`. `blockReason.type` on a blocked
card can now be `CLIENT_REQUESTED`.
See [Card statuses](/cards/overview#card-statuses) and [Managing cards](/cards/managing-cards#block-and-unblock).
### Card management stays available when an account is restricted
Deleting, freezing, unfreezing, updating the PIN on, or revealing the details of a card no longer
fails with `ACCOUNT_NOT_ACTIVE` when the linked account is restricted, and a restricted account no
longer blocks its cards. `blockReason.type` on a card can no longer be `ACCOUNT_RESTRICTED`;
restriction now only affects transaction authorization, tracked separately on the account.
See [Account status](/accounts/overview#account-status).
### File a dispute on a cleared card transaction
You can dispute a cleared card transaction and have Reap take the case to the card network. Send
the transaction ID and a reason; Reap derives the card, the cardholder, and the currency from the
transaction itself.
* [File dispute](/api-reference/disputes/file-dispute)
* [List disputes](/api-reference/disputes/list-disputes)
* [Get dispute](/api-reference/disputes/get-dispute)
Some reasons need a signed statement from the cardholder before the case can move forward.
[Mint signature link](/api-reference/disputes/mint-signature-link) returns a link you can hand to
the cardholder to sign. Subscribe to
[`CARD_DISPUTE_STATUS_UPDATED`](/api-reference/card-dispute-status-updated) for the outcome.
See [Disputes](/cards/disputes/overview) and [Dispute reasons](/cards/disputes/reasons).
### Fiat deposits are now available over the API
[Get fiat deposit](/api-reference/fiat-deposits/get-fiat-deposit) returns a fiat deposit credited
to an account, including the amount as received by the bank and the amount actually credited when
the transfer was converted on the way in. Subscribe to
[`FIAT_DEPOSIT_CREATED`](/api-reference/fiat-deposit-created) for new deposits. In Program-Funded
programs, [Simulate a fiat deposit](/api-reference/simulation/simulate-a-fiat-deposit) credits a
project's master collateral account in sandbox for testing. Fiat deposits also appear in
[List activities](/api-reference/activities/list-activities) as `FIAT_DEPOSIT`.
### The activity feed can return more than one activity type at once
`type` on [List activities](/api-reference/activities/list-activities) now accepts a
comma-separated list, so `type=CRYPTO_DEPOSIT,CARD_TRANSACTION` returns deposits and card
transactions together in one ordered, paginated feed. Every other filter narrows within its own
activity type instead of restricting the feed to it, so `cardId=` alone still returns the
account's other activity alongside that card's transactions - combine it with
`type=CARD_TRANSACTION` to see the card's transactions by themselves.
See [Reading transactions](/transactions/overview).
### Master deposits can be charged a deposit fee
Deposits into a master account can carry a fee, set per project and agreed with Reap. The fee
comes out of the deposit, so the balance goes up by the amount minus the fee. Each deposit
reports what it was charged in `feeAmount`, in the same token as `amount`. A project with no fee
reports `0`. Deposits into user accounts are never charged and report `null`.
See [Deposit fee](/accounts/deposits#deposit-fee).
### Simulate an authorization with a 3DS challenge
You can run the whole challenge flow in sandbox for cards using `3dsChallengeMethod: WEBHOOK`
with [Simulate 3DS authorization](/api-reference/simulation/simulate-3ds-authorization). It
sends `CARD_3DS_CHALLENGE_CREATED` without creating a transaction, so you can test how your
integration responds to a challenge. Approving one creates the transaction, rejecting it does
not.
See [Testing in Sandbox](/transactions/testing-in-sandbox).
### Responding to a closed 3DS challenge returns a specific error
[Respond to 3DS challenge](/api-reference/cards/respond-to-3ds-challenge) returns
`400 3DS_CHALLENGE_INVALID_STATE` if the challenge has already been answered or has expired.
### Fraud alerts can be handled through the API
Reap raises an alert on a transaction it suspects is fraudulent. You can also report a past
transaction as fraud yourself. Either way, you can list alerts, fetch one, and respond to
confirm or decline the suspected fraud:
* [Report fraud](/api-reference/fraud-alerts/report-fraud)
* [Respond to alert](/api-reference/fraud-alerts/respond-to-alert)
Confirming an alert, or reporting a transaction as fraud, blocks the card and sends
[`CARD_STATUS_UPDATED`](/api-reference/card-status-updated) with
`blockReason.type: FRAUD_ALERT_CONFIRMED`. Two webhook events track the alerts themselves:
[`CARD_FRAUD_ALERT_CREATED`](/api-reference/card-fraud-alert-created) and
[`CARD_FRAUD_ALERT_STATUS_UPDATED`](/api-reference/card-fraud-alert-status-updated). An alert
that nobody answers in time expires on its own.
See [Fraud Alerts](/cards/fraud-alerts).