---
agentTools:
  projectIndex: https://customer-api.getpliant.com/llms.txt
---

# Various new endpoints & improvements

We are introducing a way to retrieve the **statement CSV** (helpful for reconciliation). In addition to that, we added a new request property for **deactivating cardholders** and a new callback that is fired once a card is shipped by one of our card manufacturers.

## Statement CSV

Until know we only exposed the monthly statement PDF including all the account movements (we call them "account entries") like credit card transactions, bill payments, direct debit reversal fees and so forth. We are now adding an endpoint that allows fetching the so called statement CSV. Usually this file is attached to the monthly billing email (next to the statement PDF) but can also be downloaded for each month using Pliant UI.

To access the file:

1. Call [POST /statements/csv](https://customer-api.getpliant.com/reference/get-statement-csv) to trigger the file creation job for the specified organization, card account and date period.
2. You will receive a callback of type `STATEMENT_CSV_DOWNLOAD_READY` once the exported CSV file is ready. Do not forget to subscribe to the callback upfront! Otherwise this endpoint returns an error.
3. Fetch the actual file via the URL that is provided in `statementFileUrl`. This URL is valid for at least 1 week. After that, the file might not be available anymore. The pattern of this URL may change at any time, so do not rely on the structure of the URL. Every time you receive the callback, just use the provided URL in the callback to download the file.

Remarks to the business logic: You can specify start and end dates. In the Pliant application, for all completed months, these dates default to the first and last day of the month. For the ongoing month, the start date defaults to the first day of the month, and the end date is set to the current day.

## Deactivate cardholder

It was possible for a long time already to deactivate cardholders by calling [DELETE /cardholders/\{cardholderId}](https://customer-api.getpliant.com/reference/deactivate-cardholder).

Sometimes there is the business need to deactivate a cardholder and re-invite the cardholder with the same username (email address). This is why we are adding an optional `suffix` parameter when calling the above mentioned endpoint that allows API consumers to alter the username by adding a suffix like `+deactivated` to the email address that is stored on the platform.

Business logic:

* If no suffix is applied the cardholder will be deactivated without any change of the username
* If the endpoint is called for already deactivated cardholders the suffix will be applied as well.

## Minor improvements

* We're introducing a new event: `CARD_SHIPPED`. This event will be triggered when we receive confirmation from our card manufacturers that a physical card has been successfully shipped. Please note that this event is applicable only for cards designated as `PHYSICAL` and will not be triggered for any other card types. The payload is re-using the `cardUpdate` object described in our [API reference](https://customer-api.getpliant.com/reference/createcardsubscription) for card entity.
* We added the `cardId` to the payload of `CARD_REQUEST_UPDATED` callback that is triggered by the following events: `CARD_REQUEST_CREATED`, `CARD_REQUEST_APPROVED` & `CARD_REQUEST_REJECTED`.