How the activation probe went
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
uuiduuidResponse 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/certificates/497f6eca-6276-4993-bfeb-53cbbbba6f08/activation" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "schemaVersion": "console.1", "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6"}Enrol a new certificate version POST POST
ADMIN and above, which is the floor ADR 0016 point 7 sets for companies and the one 000060 already applies to minting a credential that carries certificates:manage. Takes the four secrets SUNAT needs: the PKCS#12, its password, and the SOL user and password that authenticate the submission. None of them touches a database connection — they cross the signing service binding and are sealed there. The result is a DRAFT that signs nothing; whatever certificate is signing today keeps signing until an activation probe is accepted by SUNAT.
Ask SUNAT to prove this version POST POST
Answers 202 and nothing is switched yet. A DRAFT reaches ACTIVE only after this platform has signed a factura on the reserved series F000 with that certificate and SUNAT beta has accepted it (000052) — proof of control checked by the party that can check it. PRODUCTION is refused, because a production certificate cannot be proved against beta and issuing a real comprobante to prove it is not the platform's call. This route takes no Idempotency-Key: the key is derived from the version, so a double-click replays instead of probing twice.