Fac-360Generate 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 notification subscriptions this company has configured GET GET
DEVELOPER and above, which is the tier webhooks:manage occupies among the scopes: a notification is integration configuration, not third-party data nor a tax act. It is deliberately LOWER than the complaint book, where a consumer address is read, and than SIRE, where a tax period is closed. The signing secret is never returned here. It is not stored readable anywhere, so the only moments it can be read are creation and rotation.