A POST request sent to create a card. Prior to create a card, the user must have completed KyC and verified his wallet. Cards can have different designs setup during onboarding. If no designId is specified in the request, and a default designId has been specified during setup of the card program, the default will be used. If there is no designId neither in the request nor a default specified, an error response will be returned.
For physical cards, ensure the shipping address is up to date before creating the card. Any
shippingKYC associated with the user must be in statuscompleted; otherwise the card may be shipped to an outdated address.
If reissuing a card (e.g. replacing a lost or stolen card), use the reissue endpoint (POST /cards/{id}/reissue) instead of this one.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.
The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401 Unauthorized, the client's identity is known to the server.
The user has sent too many requests in a given amount of time ("rate limiting").
The server has encountered a situation it does not know how to handle.
This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.
The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded.
This error response is given when the server is acting as a gateway and cannot get a response in time.