---
title: "Issue Card"
method: POST
path: "/cards/{cardholderId}"
tags: ["Cards"]
---

# Issue Card

`POST /cards/{cardholderId}`

Issue a new credit card for a specific cardholder. A detailed explanation of different types and statuses can be found in our [guides](/docs/card-entity) section. Hint: you can also [replace](./replace-card) an existing card instead.
If the cardholder is in the invited state at the time of issuing the card, we will park the card issuing request and automatically issue the card once the cardholder is active.
Please be aware that card issuing is (as many other processes in Pliant's API) an [asynchronous process](/docs/core-concepts#mutating-data-happens-asynchronously). This means you need to rely on the callback for the card being active, before you can start using it.

**This endpoint has changed in comparison to the previous version of the API.** The following changes were made:
- added `cardControls` to request and response body
- deprecated `type` and replaced it with `cardConfig`

## Path parameters

- `cardholderId` string, uuid, required

## Request body

- object
  - `organizationId` string, uuid, required — The ID of the organization to issue the card for.
  - `cardAccountId` string, uuid — The ID of the [card account](/docs/card-account) to issue the card for. If not provided, the card will be issued for the default [card account](/docs/card-account) of the organization.
  - `type` 'VIRTUAL' | 'SINGLE_USE' | 'PHYSICAL' | 'BLACK' | 'TRAVEL', nullable — Deprecated, please use `cardConfig` instead. `VIRTUAL` - Virtual credit card `SINGLE_USE` - One-time virtual credit card (only one authorization allowed per card) `PHYSICAL` - Physical credit card `BLACK` - Physical black premium credit card `TRAVEL` - Virtual cards used specifically in travel industry related use cases Either `type` or `cardConfig` has to be provided. Please prefer `cardConfig`.
  - `cardConfig` string, required — The Pliant card configuration of this card. This describes all features of this card in one single configuration, e.g. the type of the card and also the design of the card etc. It replaces the deprecated card `type`. Please refer to the [guide section](/docs/card-entity) to learn more about possible values. Either `type` or `cardConfig` has to be provided. Please prefer `cardConfig`. **Required** for INSURANCE cards - the deprecated `type` field cannot be used.
  - `cardDesignId` string, uuid, nullable — The unique identifier of the card design used for this card. This field can only be set when creating virtual cards. Available designs for a card config can be retrieved via the [available cards endpoint](/reference/get-available-cards).
  - `label` string, nullable — Mandatory only for virtual cards with a `cardConfig` containing `VIRTUAL` or `TRAVEL`, the maximum length is 40 characters.
  - `purpose` string — Mandatory only for virtual cards with `cardConfig` ending with `SINGLE_USE`
  - `validityPeriod` 3 | 6 | 9 | 12 | 18 | 24 | 30 | 36 — Number of months when card expires. - Mandatory for `cardConfig` containing `VIRTUAL` and `TRAVEL` - For `cardConfig` ending with `PHYSICAL` or `BLACK`: set to 36 months automatically - For `cardConfig` ending with `SINGLE_USE`: set to 12 months automatically - For `cardConfig` containing `INSURANCE`: - Physical insurance: set to 24 months automatically - Virtual insurance (excluding single-use): validated from enum, defaults to 36 months - Single-use insurance: set to 12 months automatically For cards with fixed validity periods, user input is ignored.
  - `validFrom` string, date, nullable — Optional field to describe a fixed date range in which the card is usable for purchases, replaces the `validityPeriod` if used. Outside of this date range, the card cannot be used for any purchases, only for zero-amount card-checks, and is shown with `status` `PENDING`. If not provided, the card is active immediately. Date needs to be provided as `yyyy-mm-dd` and is treated inclusive, meaning the provided date is already a valid day to use the card. If used, the parallel usage of card controls regarding `dates` and/or `times` is not allowed and the `validityPeriod` will be set to 36 months automatically. The earliest possible date is the current date. The `validFrom` date needs to be before the `validTo` date. The fields `validFrom`, `validTo` and `validTimezone` need to be used together, if used at all. This field can be [updated later](/reference/update-card-validity-period). This field must be `null` when issuing benefit cards.
  - `validTo` string, date, nullable — Optional field to describe a fixed date range in which the card is usable for purchases, replaces the `validityPeriod` if used. After the specified date, the card is automatically terminated. If not provided, the card is active until the `validityPeriod` ends. Date needs to be provided as `yyyy-mm-dd` and is treated inclusive, meaning the card will be terminated one day after this date. If used, the parallel usage of card controls regarding `dates` and/or `times` is not allowed and the `validityPeriod` will be set to 36 months automatically. The earliest possible date is the current date. The latest possible date is the end date of the `validityPeriod`. The fields `validFrom`, `validTo` and `validTimezone` need to be used together, if used at all. This field can be [updated later](/reference/update-card-validity-period). This field must be `null` when issuing benefit cards.
  - `validTimezone` string — Optional field to describe the timezone for the `validFrom` and `validTo` fields. This field is mandatory if `validFrom` and `validTo` fields are used. A list of valid timezones can be found in our [guide section](/docs/card-controls-1). This field can be [updated later](/reference/update-card-validity-period). This field must be `null` when issuing benefit cards.
  - `maxTransactionCount` number — :exclamation: IMPORTANT: if the `cardConfig` is `TRAVEL` and this field is not set, the **default value will be `3`**. Optional field to describe the maximum number of transactions within the range of `1..999999999` that can be performed with this card. If not provided, the card can be used for an unlimited number of transactions until the card expires.
  - `monthlyLimit` object — Use `limit` instead.
    - `value` number — The value of the monetary amount, converted to minor units of the currency. For instance 1.00 EUR is 100 cents, thus the value here is `100`. See our [guides](/docs/monetary-values) for more details about how to handle monetary amounts.
    - `currency` string — The currency of the monetary amount in ISO 4217 format, for example `EUR` for Euro. This has to match the currency of the respective [card account](/docs/card-account)!
  - `limit` object, required — The limit of the card. The limit renews according to the `limitRenewFrequency` or never, if `limitRenewFrequency` is set to `TOTAL`. This limit can later be adjusted via the [update limit endpoint](/reference/update-card-limit). The limit can be up to the organization's overall limit. For instance an organization with a limit of 1,000,000 EUR can have a card with a limit up to 1,000,000 EUR. It is also possible to have more than one card with the maximum limit. For example you can have two cards each with a limit of 1,000,000 EUR. The card limits are not added up on creation, only the transactions happening on the card are added up and checked against the organization's overall limit. The limit must be `0` (of the card's currency) when issuing benefit cards.
    - `value` number — The value of the monetary amount, converted to minor units of the currency. For instance 1.00 EUR is 100 cents, thus the value here is `100`. See our [guides](/docs/monetary-values) for more details about how to handle monetary amounts.
    - `currency` string — The currency of the monetary amount in ISO 4217 format, for example `EUR` for Euro. This has to match the currency of the respective [card account](/docs/card-account)!
  - `limitRenewFrequency` 'DAILY' | 'WEEKLY' | 'MONTHLY' | 'QUARTERLY' | 'ANNUAL' | 'TOTAL' — The frequency of the card limit renewal. * `DAILY` - The card limit is renewed every day * `WEEKLY` - The card limit is renewed every week * `MONTHLY` - The card limit is renewed every calendar month, this is the default setting. * `QUARTERLY` - The card limit is renewed every calendar quarter. * `ANNUAL` - The card limit is renewed every year. * `TOTAL` - The card limit is never going to be renewed. After the limit is spent the card cannot be used anymore.
  - `transactionLimit` object, required — The transaction limit of the card. Meaning the maximum amount of a single transaction. This is always below or equal to the `limit` of the card. This limit can later be adjusted via the [update limit endpoint](/reference/update-card-limit). The transaction limit can be up to the card's limit. For instance a card with a limit of 1,000 EUR can have a transaction limit up to 1,000 EUR. The transaction limit must be `0` (of the card's currency) when issuing benefit cards.
    - `value` number — The value of the monetary amount, converted to minor units of the currency. For instance 1.00 EUR is 100 cents, thus the value here is `100`. See our [guides](/docs/monetary-values) for more details about how to handle monetary amounts.
    - `currency` string — The currency of the monetary amount in ISO 4217 format, for example `EUR` for Euro. This has to match the currency of the respective [card account](/docs/card-account)!
  - `customFirstName` string, nullable — Optional first name on `TRAVEL` cards which will be used on the card. When used, this replaces the [cardholder](/docs/cardholder-entity) first name, which normally is used on the card. The maximum length of `customFirstName` is 50 characters. If used, both fields (`customFirstName` and `customLastName`) have to be provided with at least one character each. It is important to note, that only the following characters are allowed for issuing cards: `A-Z`, `a-z`, `0-9`, `äöüÄÖÜ.-`
  - `customLastName` string, nullable — Optional last name on `TRAVEL` cards which will be used on the card. When used, this replaces the [cardholder](/docs/cardholder-entity) last name, which normally is used on the card. The maximum length of `customLastName` is 50 characters. If used, both fields (`customFirstName` and `customLastName`) have to be provided with at least one character each. It is important to note, that only the following characters are allowed for issuing cards: `A-Z`, `a-z`, `0-9`, `äöüÄÖÜ.-`
  - `cardControls` 0 — unresolved $ref
  - `customFields` CustomFields — unresolved $ref
  - `teamId` string, uuid, nullable — The ID of the team to issue the card for.
  - `projectId` string, uuid, nullable — The ID of the project to issue the card for.
  - `copilots` object, nullable — Optional feature for `TRAVEL` cards. This feature allows to assign cardholders or teams as copilots to the card. The copilot also has access to the card and its card details alongside with the cardholder of the card itself.
    - `cardholderIds` string[], nullable — The IDs of the cardholders to assign as copilot to the card.
    - `teamIds` string[], nullable — The IDs of the teams to assign as copilot to the card.
  - `deliverTo` 'ORGANIZATION' | 'CARDHOLDER', nullable — Optionally, specifies where the physical card should be delivered. * `ORGANIZATION` - Ship to organization address (default) * `CARDHOLDER` - Ship to cardholder's personal delivery address This field is only applicable for physical cards. If not provided, the card will be shipped to the organization address. The request will fail if the cardholder's personal delivery address is not set and `deliverTo` is set to `CARDHOLDER`.
  - `additionalLimits` Items[], nullable — Optional additional limits to set on the card at creation time. — unresolved $ref

## Response `200`

Ok. The card can be used after you received the callback for the card being active.

- Schema — unresolved $ref

## Other responses

- `400` — unresolved $ref
- `401` — unresolved $ref
- `403` — unresolved $ref
- `404` — unresolved $ref
- `500` — unresolved $ref

---

[API](https://skmtc.dev/getpliant/apis/pliant-customer-api.md) · [All operations](https://skmtc.dev/getpliant/apis/pliant-customer-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/getpliant/pliant-customer-api/revisions/f3f589cfa718/schema)