The request and error log
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 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.
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
uuidQuery Parameters
uuiddate-time1 <= value <= 20050Response 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 GET "https://example.com/console/v1/companies/497f6eca-6276-4993-bfeb-53cbbbba6f08/activity" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "schemaVersion": "console.1", "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6", "companyId": "8bb73d03-06b4-47c7-80c7-59301f770eda", "entries": [ { "occurredAt": "2019-08-24T14:15:22Z", "operationId": "3051932a-fdd2-48fa-b330-7e7d41535969", "documentId": "4704590c-004e-410d-adf7-acb7ca0a7052", "documentType": "string", "series": "string", "number": "string", "operationType": "string", "operationStatus": "string", "startedAt": "2019-08-24T14:15:22Z", "finishedAt": "2019-08-24T14:15:22Z", "attemptNumber": 0, "endpoint": "string", "classification": "string", "responseCode": "string", "responseMessage": "string", "catalogVersion": "string", "credentialPrefix": "string" } ]}Plan consumption for this company GET GET
A read, and only a read. ADR 0016 point 6 keeps the quota holder on the company and usage.consume_quota is untouched. The period is this company's own plan period, not a window this route picked.
Generate a throwaway BETA certificate for this company and enrol it POST POST
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.