Fac-360
Organizations

Mint an API credential for a client company

Creates a COMPANY credential, which can issue comprobantes. ADR 0016 point 3 names this a privilege escalation and does not pretend otherwise: the mitigation is that it is recorded. The credential row and its ops.audit_events row are written in one transaction, and a DEFERRABLE constraint trigger on auth.api_credentials refuses at COMMIT to admit a credential for an organization-owned company without one -- so an unaudited mint is not a policy violation, it is a failed transaction. The token is returned exactly once.

POST
/api/v2/organizations/companies/{id}/credentials

Creates a COMPANY credential, which can issue comprobantes. ADR 0016 point 3 names this a privilege escalation and does not pretend otherwise: the mitigation is that it is recorded. The credential row and its ops.audit_events row are written in one transaction, and a DEFERRABLE constraint trigger on auth.api_credentials refuses at COMMIT to admit a credential for an organization-owned company without one -- so an unaudited mint is not a policy violation, it is a failed transaction. The token is returned exactly once.

Authorization

bearerAuth
AuthorizationBearer <token>

Tenant-bound, scoped and expiring Apifact credential. Migrated legacy credentials are accepted only on deprecated v1 writes and tenant-scoped v2 read, poll and download routes. Each operation names the single scope it requires in x-required-scope; the scope array of the security requirement itself is empty because OpenAPI 3.0 requires it to be for a non-oauth2 scheme.

In: header

Path Parameters

id*string
Formatuuid

Header Parameters

Idempotency-Key*string
Match^[!-~]+$
Length1 <= length <= 200

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X POST "https://example.com/api/v2/organizations/companies/497f6eca-6276-4993-bfeb-53cbbbba6f08/credentials" \  -H "Idempotency-Key: b6a2f0e4-1c3d-4a5b-8e7f-9d0c1b2a3e4f" \  -H "Authorization: Bearer apf_v2_tu_credencial" \  -H "Content-Type: application/json" \  -d '{    "name": "SaaS - facturacion 20698765432",    "scopes": [      "documents:create",      "documents:read",      "documents:submit",      "documents:pdf",      "operations:read",      "artifacts:read",      "webhooks:manage"    ],    "expiresInDays": 90  }'
{  "schemaVersion": "2.0",  "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6",  "resourceId": "026d60bb-63a8-407e-bf67-01dcfc6022e6",  "credentialId": "f568fec0-10b6-4b94-9daf-e62c50c9bf3e",  "token": "string",  "companyId": "8bb73d03-06b4-47c7-80c7-59301f770eda",  "companyRuc": "string",  "scopes": [    "string"  ],  "expiresAt": "2019-08-24T14:15:22Z",  "createdAt": "2019-08-24T14:15:22Z",  "auditEventId": "b284fbf1-1a7a-4799-bddc-ba227ef5747f"}

Upload a client company's signing certificate and SOL credentials POST POST

The same body, the same validation, the same sealing boundary and the same DRAFT outcome as POST /api/v2/certificates -- it is that path, reached with the tenant established by auth.bind_organization_company after verifying the company belongs to the caller's organization. The PKCS#12 and the three passwords cross the signing service binding and reach nothing durable in between. Activation is deliberately NOT available here: promoting the DRAFT sends a real signed factura to SUNAT under the client's RUC, and that is performed with the company credential this organization minted.

Move a client company from SUNAT beta to production POST POST

ONE-WAY. After it the next comprobante this company issues is a real fiscal fact in the taxpayer's sales ledger, and there is no route back. It refuses until the company already holds a production configuration that has been ARMED -- a real certificate whose subject RUC is this company's, and a SOL account validated against production -- so promotion is never the step that discovers the taxpayer has no usable certificate. It also refuses while any beta submission is still in flight. Everything rehearsed in beta keeps its state, its CDR and the environment it was stamped with; a beta document created and never sent is CANCELLED in the same transaction, because its only remaining move was a submission that would now be refused. Correlativos are held per environment, so production numbering does not continue a rehearsal. The act and its audit row are written together, exactly as the alta is. 404 answers both a company that does not exist and one outside this organization, indistinguishably.