Stores a new set of bank credentials for the company. Cardda encrypts the
secrets at rest; this is the only entry point that accepts plain-text
credentials. Upon creation Cardda runs an asynchronous validation against
the bank — the key starts as pending; poll the resource until status
flips to approved (or declined).
A credential can be shared across several companies. If you re-enter a
credential you already own (same user_id + type, plus rut for CL/MX or
email for US) and associate it to another company, Cardda attaches that
company to the existing key instead of creating a duplicate — the response is
200 carrying the existing key (vs 201 for a brand-new key).
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Unauthorized — missing or invalid bearer token, or company-id header not set.
Unprocessable entity — invalid credentials shape, or the credential is
already enrolled by a different user (user_id + rut/email +
type uniqueness). Re-entering a credential you already own (with its
identifier present) no longer 422s; it returns 200 with the existing
key (see above). Edge case: a blank-identifier reconnect (missing
rut for CL/MX or email for US) deliberately skips the association
path — as do virtual keys, which always skip it — so it can still 422
on the model's presence/uniqueness validations.