Move this company from SUNAT beta to production
OWNER only, and only with a second factor enrolled -- the alta of a company is ADMIN and above, and this is deliberately stricter. It is 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. Everything the company rehearsed in beta keeps its state, its CDR and the environment it was stamped with; a beta document that was created and never sent is CANCELLED here, because its only remaining move was a submission that would now be refused. It refuses while any beta submission is still in flight, and it refuses until the company already holds a production configuration that has been armed -- which means a real certificate whose subject RUC is this company's and a SOL account validated against production. Numbering does not carry over: correlativos are held per environment, so the first production F001 starts where a production F001 should. 404 answers both a company that does not exist and one this session may not act on, indistinguishably.
OWNER only, and only with a second factor enrolled -- the alta of a company is ADMIN and above, and this is deliberately stricter. It is 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. Everything the company rehearsed in beta keeps its state, its CDR and the environment it was stamped with; a beta document that was created and never sent is CANCELLED here, because its only remaining move was a submission that would now be refused. It refuses while any beta submission is still in flight, and it refuses until the company already holds a production configuration that has been armed -- which means a real certificate whose subject RUC is this company's and a SOL account validated against production. Numbering does not carry over: correlativos are held per environment, so the first production F001 starts where a production F001 should. 404 answers both a company that does not exist and one this session may not act on, indistinguishably.
Authorization
consoleSession Set by POST /console/v1/sessions. HttpOnly, Secure, SameSite=Strict, Path=/, __Host- prefixed. It is never readable by JavaScript and there is no header alternative: accepting both carriers would let an attacker choose the weaker one.
In: cookie
Path Parameters
uuidResponse Body
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/console/v1/companies/497f6eca-6276-4993-bfeb-53cbbbba6f08/promotion" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "companyId": "6f1a2b3c-4d5e-4f60-8a91-2b3c4d5e6f70", "sunatEnvironment": "PRODUCTION", "cancelledDocuments": 3, "promotedAt": "2026-08-18T14:22:05.881Z"}Stream one artifact GET GET
The bytes come from apps/artifact-worker, which re-verifies the SHA-256 and the byte size of what it reads before any of it reaches the caller. The object key never leaves the server. Use versions/{representationId} as the kind to fetch a specific PDF render.
The API credentials of this company GET GET
Any member may read it, VIEWER included. It carries no secret -- there is no column holding one -- and the public prefix it does carry is already reported for every operation by GET /console/v1/companies/{companyId}/activity, so hiding this list would be a rule with no content. Revoked and expired credentials stay in it.