Fac-360
Certificates

Generate a throwaway BETA certificate for this company and enrol it

The first thing an integration needs is a certificate, and in beta that certificate is a self-signed file the integrator produces with openssl -- a step that teaches nothing and where onboarding stalls. This generates one for you: a 2048-bit key whose subject is THIS COMPANY'S RUC, valid for two years, marked on the certificate itself as not fiscally valid, and enrolled through exactly the same path as an upload, with the same guards, the same sealing and the same DRAFT version. You still supply the SOL credentials, because SUNAT's test user is SUNAT's convention and not something this API is entitled to assume on your behalf. The PFX and its generated password are returned in this response and nowhere else -- keep them, they are the file you would have made yourself. BETA ONLY: it is refused with 409 for a company that issues against production, where a certificate this platform minted for itself proves nothing about who controls the RUC. Idempotency-Key behaves as it does on the upload route: a replay returns the first certificate rather than minting a second.

POST
/api/v2/certificates/sandbox

The first thing an integration needs is a certificate, and in beta that certificate is a self-signed file the integrator produces with openssl -- a step that teaches nothing and where onboarding stalls. This generates one for you: a 2048-bit key whose subject is THIS COMPANY'S RUC, valid for two years, marked on the certificate itself as not fiscally valid, and enrolled through exactly the same path as an upload, with the same guards, the same sealing and the same DRAFT version. You still supply the SOL credentials, because SUNAT's test user is SUNAT's convention and not something this API is entitled to assume on your behalf. The PFX and its generated password are returned in this response and nowhere else -- keep them, they are the file you would have made yourself. BETA ONLY: it is refused with 409 for a company that issues against production, where a certificate this platform minted for itself proves nothing about who controls the RUC. Idempotency-Key behaves as it does on the upload route: a replay returns the first certificate rather than minting a second.

Authorization

bearerAuth
AuthorizationBearer <token>

Tenant-bound, scoped and expiring Apifact credential. Migrated legacy credentials are accepted only on deprecated v1 writes and tenant-scoped v2 read, poll and download routes. Each operation names the single scope it requires in x-required-scope; the scope array of the security requirement itself is empty because OpenAPI 3.0 requires it to be for a non-oauth2 scheme.

In: header

Header Parameters

Idempotency-Key*string
Match^[!-~]+$
Length1 <= length <= 200

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

No environment: a sandbox certificate is BETA by definition, and a field that can hold only one value is a field somebody eventually sends the other value in.

Response Body

application/json

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/api/v2/certificates/sandbox" \  -H "Idempotency-Key: b6a2f0e4-1c3d-4a5b-8e7f-9d0c1b2a3e4f" \  -H "Authorization: Bearer apf_v2_tu_credencial" \  -H "Content-Type: application/json" \  -d '{    "solUser": "MODDATOS",    "solPassword": "moddatos"  }'
{  "schemaVersion": "2.0",  "requestId": "d385ab22-0f51-4b97-9ecd-b8ff3fd4fcb6",  "sandboxCertificate": {    "pfxBase64": "string",    "pfxPassword": "string",    "certificateSerialNumber": "string",    "subjectRuc": "string",    "notAfter": "2019-08-24T14:15:22Z"  }}