Returns a paginated list of SII keys — the digital-certificate credentials
Cardda holds on behalf of a company to operate against Chile's Servicio de
Impuestos Internos (SII).
An SII key is what lets Cardda authenticate to the SII to sync the
company's issued/received electronic documents (DTEs), pull PDFs, and submit
acceptance/rejection events. A key becomes usable once its status is
approved; it can additionally issue documents once a certificate
password is present (can_issue?).
Response structure
Sensitive fields (password, certificate_password) are never exposed by
this endpoint — they are stripped from every serialization. Each item adds two
computed fields:
| Field | Description |
|---|---|
can_issue? | true when status is approved and a certificate password is stored. Serialized literally with the trailing ?. |
company_ids | UUIDs of the companies the key manages. |
Scoping
Results are scoped to the keys the caller can see: keys the caller owns
(user_id == caller) plus keys whose managed companies grant the caller the
sii_keys_view or sii_keys_manage permission.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Unauthorized — missing or invalid bearer token, or the caller failed the
list authorization gate. The gate passes for Cardda staff, for a caller who
belongs to the company-id header's company, or for a caller who passes
their own id as user_id. This gate is separate from result scoping:
holding sii_keys_view/sii_keys_manage determines which keys appear in the
response, but does not by itself authorize the call — a caller with those
permissions who sends neither the company-id header (for a company they
belong to) nor user_id=<own id> still receives 401. Pundit failures surface
as 401 (not 403) with an empty body.