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

# Delete Token

> Permanently delete a token and its associated card data from PCI Booking.

<Card title="Delete Tokens Guide" icon="book" href="/manage-tokens/delete-tokens">
  Permanently remove tokens from the system
</Card>

<Warning>
  Deleting a token is permanent and cannot be undone.
</Warning>

Permanently deletes a token and all associated card data from PCI Booking. Use this to remove cards that are no longer needed, such as expired reservations or cancelled bookings, to stop incurring monthly storage fees.

## Error Responses

| Code | HTTP Status | Condition |
| - | - | - |
| -160 | 404 | Token not found or already deleted |
| -1003 | 401 | User is not the owner of this token |
| -125 | 400 | Delete operation failed |

It is safe to repeat a DELETE. A `404` with code `-160` on the repeat confirms the token is gone. See [Token Not Found or Not Accessible](/reference/error-handling#token-not-found-or-not-accessible).

### Error detail

Each condition below gives the exact `moreInfo` text, why it happens and how to resolve it. The full set is on the [Error Handling](/reference/error-handling) page.

<AccordionGroup>
  <Accordion title="-160 Uri not found - token does not exist or was already deleted">
    **HTTP status:** `404`

    **`message`:** `Uri not found`

    **`moreInfo`:**

    ```text theme={null}
    The provided card token does not exist or was already deleted
    ```

    **Reason.** Delete Token found no token with this value. Either it never existed, or it was already deleted. Deletion is permanent and cannot be undone. Only Delete Token returns this error for a missing token. See [Token Not Found or Not Accessible](/reference/error-handling#token-not-found-or-not-accessible).

    **How to resolve.** If you meant to delete the token, no action is needed: this response confirms the token is gone. Otherwise, check that the tokenization call returned this exact token, and that you are calling the same environment where it was created.
  </Accordion>

  <Accordion title="-1003 You are not authorized to access this resource - token does not exist, was deleted, or is not yours">
    **HTTP status:** `401`

    **`message`:** `You are not authorized to access this resource. Please contact customer support.`

    **`moreInfo`:** one of the following, depending on which check failed:

    ```text theme={null}
    User is not the owner of this bank card
    Merchant or Owner are not associated with bank card [<token>] userID: <userId>
    User <userId> is not associated with bank card [<token>]
    User <userId> cannot delegate token <token> - not owner and lacks delegation rights
    User is not authorized to handle bank cards
    ```

    **Reason.** The credential authenticated fine, but it cannot act on the token in the request. Either the token does not exist or it is not yours to use. The generic wording makes this the single most misread error in the API. On a token call it is far more often one of the causes below than an actual permissions problem.

    **How to resolve.**

    1. **Check the token still exists.** This is the most common cause. On every token endpoint except Delete Token, a token that does not exist or was deleted returns this error, the same as a token that belongs to another account. See [Token Not Found or Not Accessible](/reference/error-handling#token-not-found-or-not-accessible).
    2. **Check the tokenization actually succeeded.** If the call that should have created the token failed, the token never existed, and calls that use it report `-1003`.
    3. **Check the environment.** A sandbox token cannot be used from production, or the reverse.
    4. **Check ownership and association.** See the rules below.

    **Ownership and association.**

    A token is owned by the account that created it. Another account can use the token only if the token was explicitly associated with it:

    * **At tokenization**, by passing `merchantId` on the tokenizing call.
    * **After tokenization**, by associating the token with the merchant.

    Two rules catch people out:

    * An association can only target a **primary** account. If you pass the ID of a sub-user or a secondary property, the request is rejected and you must associate the token with the parent account instead.
    * Tokens never cross environments. A token created in sandbox cannot be used from production, and the reverse is also true.

    **Account level blocks.**

    An account that has exceeded its processing allowance is blocked, and every billable API call from it then fails with HTTP `403` and code `-1003`, even though the credentials are still valid and can still sign in to the portal. In this response `message` is empty (`null`) and `moreInfo` holds only the generic `-1003` text, so nothing in the body explains the block. The `403` status is what tells it apart from a token that is not accessible, which returns `401`.

    This is a common cause on sandbox accounts, which have a lower allowance than production.

    **Check for it when a `403` with `-1003` appears suddenly across calls that used to work, on more than one token.** A block affects every billable call on the account at once, whereas a genuine ownership problem affects only the specific token. Contact [support](https://pcibooking.net/pci-booking-support/) with your account name to have the allowance reviewed and the block lifted. The block stays until support lifts it.
  </Accordion>
</AccordionGroup>

## Parameters

### Authentication

**API key only.** This endpoint does not accept access tokens or session tokens.

<ParamField header="Authorization" type="string" required>
  Your API key prefixed with `APIKEY`. Example: `APIKEY your-api-key`. The `x-pcibooking-api-key` header is also accepted. See the [Authentication guide](/getting-started/authentication).
</ParamField>

### Path Parameters

<ParamField path="cardToken" type="string" required>
  The token ID as returned by one of the tokenization methods. For example, `2821a46d80e14d1b96a7f18f1b81926d`.
</ParamField>

<RequestExample>
  ```javascript Node.js theme={null}
  const response = await fetch(
    'https://service.pcibooking.net/api/payments/paycard/2821a46d80e14d1b96a7f18f1b81926d',
    {
      method: 'DELETE',
      headers: {
        'Authorization': 'APIKEY your-api-key'
      }
    }
  );

  console.log(response.status);
  ```

  ```python Python theme={null}
  import requests

  response = requests.delete(
      'https://service.pcibooking.net/api/payments/paycard/2821a46d80e14d1b96a7f18f1b81926d',
      headers={'Authorization': 'APIKEY your-api-key'}
  )

  print(response.status_code)
  ```
</RequestExample>

## Response

**200** - Token deleted. Empty response body.

<ResponseExample>
  ```text 200 theme={null}
  Token deleted successfully. No content returned.
  ```

  ```text 401 theme={null}
  Empty response body.
  Authentication failed: the API key, session token or access token is missing or was not accepted.
  See "Authentication and Permission Failures" on the Error Handling page.
  ```
</ResponseExample>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.