Generate a throwaway BETA certificate for this company and enrol it
The step where onboarding stalls: before issuing anything an integrator needs a certificate, and in beta that certificate is a self-signed file produced with openssl. This generates it. The subject is THIS COMPANY'S RUC -- the enrolment guard compares the two and refuses a mismatch, so it cannot be minted for anybody else -- the key is 2048 bits, it lasts two years, and the certificate says on its own OU that it is not fiscally valid. It is then enrolled through exactly the same path an upload takes: same guards, same sealing, same DRAFT version, same Idempotency-Key semantics. You still supply the SOL credentials, because SUNAT's test user is SUNAT's convention and not something this API may assume for you. The PFX and its generated password come back in this response and nowhere else. BETA ONLY: a company that already issues against production is refused, because a certificate this platform signed for itself proves nothing about who controls the RUC -- and that is the entire job of a production certificate.
The step where onboarding stalls: before issuing anything an integrator needs a certificate, and in beta that certificate is a self-signed file produced with openssl. This generates it. The subject is THIS COMPANY'S RUC -- the enrolment guard compares the two and refuses a mismatch, so it cannot be minted for anybody else -- the key is 2048 bits, it lasts two years, and the certificate says on its own OU that it is not fiscally valid. It is then enrolled through exactly the same path an upload takes: same guards, same sealing, same DRAFT version, same Idempotency-Key semantics. You still supply the SOL credentials, because SUNAT's test user is SUNAT's convention and not something this API may assume for you. The PFX and its generated password come back in this response and nowhere else. BETA ONLY: a company that already issues against production is refused, because a certificate this platform signed for itself proves nothing about who controls the RUC -- and that is the entire job of a production certificate.
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/certificates/sandbox" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "schemaVersion": "2.0", "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6", "sandboxCertificate": { "pfxBase64": "string", "pfxPassword": "string", "certificateSerialNumber": "string", "subjectRuc": "string", "notAfter": "2019-08-24T14:15:22Z" }}The request and error log GET GET
The read that exists so a rejected comprobante does not become an email to support. One entry per SUNAT attempt -- retries are never collapsed -- plus operations that never reached SUNAT at all, each with the verbatim response code and description, the transport classification, and the PUBLIC prefix of the credential that started it. The free-form operations.result jsonb is deliberately NOT published: nothing bounds what a future workflow writes into it.
The complaints filed against this company, and the book's own identifier GET GET
ADMIN and above, and the floor is higher than it looks for a read: this returns the personal data of THIRD PARTIES — consumers who are not this platform's users and never chose to be in it. It is the same floor the machine surface's complaints:read scope carries, so a person's role and a credential's scope cannot disagree about who may see a consumer's address. It runs on DB_RUNTIME and not on the console connection. apifact_console holds SELECT on exactly two tables and no DML anywhere, so it cannot read complaints.* and must not learn to; what it can do is prove which company this session is entitled to, which is exactly what auth.bind_console_company is for. The book's own identifier comes back with the list, because the person reading this screen is usually the person who has to put it on the company's website. requiresTurnstile says whether that form is expected to send a humanity token. A refusal is 403 CONSOLE_ROLE_INSUFFICIENT and never 401: the session is alive and only the role is short, and a 401 would send somebody to a login screen that cannot fix it.