Fac-360The notification subscriptions this company has configured
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.
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.
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 GET "https://example.com/console/v1/companies/497f6eca-6276-4993-bfeb-53cbbbba6f08/webhooks/subscriptions" \ -H "Authorization: Bearer apf_v2_tu_credencial"{ "schemaVersion": "console.1", "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6", "subscriptions": [ { "subscriptionId": "d079718b-ff63-45dd-947b-4950c023750f", "url": "http://example.com", "events": [ "string" ], "status": "ACTIVE", "description": "string", "secretVersion": 0, "createdAt": "2019-08-24T14:15:22Z" } ]}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.
Create a subscription, and read its signing secret once POST POST
DEVELOPER and above. Returns the signing secret ONCE, in this response and nowhere else. Unlike the machine route this takes no Idempotency-Key: an integrator retries blindly and needs a repeated POST to return the first subscription rather than create a second, but a person pressing a button does not, and asking them for an idempotency key would be asking them to understand a problem they do not have. One is minted per request, so the repository serialisation is not weakened for this door. The destination goes through the same guard as the machine route, which is what stops a subscription pointing at an internal address and being used to probe the network from inside.