Empieza aquí

Todo el camino es autoservicio. No hay un paso en el que tengas que esperar a que alguien te habilite algo.

1. Te registras y quedas como OWNER de tu organización.
2. Das de alta tu empresa en BETA.
3. Sacas tus llaves de API.
4. Pides un certificado de prueba —no lo fabricas— y desarrollas contra SUNAT beta.
5. Cuando estás listo, promueves esa misma empresa a producción.

El paso 5 es el que hace que los cuatro anteriores no se tiren a la basura: conservas tu companyId, tus credenciales, tus webhooks y tu organización.

1. Regístrate

curl -X POST "https://apifact.fac-360.com/console/v1/registrations" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "tu@empresa.pe",
    "password": "…",
    "organizationName": "Mi Empresa"
  }'

Responde 202 diga lo que diga: la misma respuesta y el mismo coste tanto si esa dirección ya tenía cuenta como si no. Es deliberado — ni el cuerpo ni el tiempo que tarda sirven para averiguar quién está registrado.

Quien se registra queda como OWNER de una organización nueva. Es la única forma de llegar a OWNER sin que otro OWNER te promueva. La organización nace sin empresas.

Después: verifica el correo con POST /console/v1/email-verifications, abre sesión con POST /console/v1/sessions, y activa el segundo factor con POST /console/v1/mfa/enrolment.

2. Da de alta tu empresa, en BETA

curl -X POST "https://apifact.fac-360.com/console/v1/organizations/{organizationId}/companies" \
  -H "Content-Type: application/json" \
  -d '{ "ruc": "20601030405", "legalName": "MI EMPRESA S.A.C.", "environment": "BETA" }'

Sí: en el edge de producción, con la empresa en BETA. Esa es la ruta recomendada. Emitirá contra SUNAT beta hasta que la promuevas, y el día que lo hagas no cambia nada más.

Dar de alta un RUC no demuestra que lo controles, y la plataforma no finge lo contrario: lo que garantiza es atribución, no prevención. El alta queda registrada con tu nombre en la auditoría de la organización. El control se demuestra más tarde, ante quien puede comprobarlo: SUNAT, aceptando un comprobante firmado con un certificado emitido a ese RUC.

3. Saca tus llaves

curl -X POST "https://apifact.fac-360.com/console/v1/companies/{companyId}/credentials" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "integracion ERP",
    "scopes": ["documents:validate", "documents:create", "documents:submit",
               "documents:read", "operations:read", "artifacts:read"],
    "expiresInDays": 90
  }'

El token se devuelve una sola vez. No hay columna que lo guarde ni ruta que lo relea: la base de datos no tiene de dónde sacarlo otra vez. Guárdalo al recibirlo.

Fíjate en documents:validate: no está implicado por documents:create, y es a propósito. Puedes darle a tu entorno de desarrollo una credencial que ensaya y no puede emitir.

4. Consigue un certificado de beta y desarrolla

No hace falta que lo fabriques con openssl. Pídelo:

curl -X POST "https://apifact.fac-360.com/console/v1/companies/{companyId}/certificates/sandbox" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "solUser": "MODDATOS", "solPassword": "moddatos" }'

Genera un autofirmado de 2048 bits con el RUC de tu empresa como sujeto, lo enrola por el mismo camino que una subida, y te devuelve el .pfx y su contraseña una sola vez. Guárdalos: es exactamente el archivo que habrías generado tú, y lo querrás para tus propias pruebas.

El certificado dice en su propio campo OU que no es válido fiscalmente. Dentro de un año, en tu carpeta de descargas, seguirá diciéndolo.

Las credenciales SOL sí las pones tú. MODDATOS / moddatos es el usuario de pruebas de SUNAT —una convención suya, no un valor que esta API pueda dar por supuesto en tu nombre.

Si prefieres subir el tuyo, la ruta de siempre sigue ahí:

curl -X POST "https://apifact.fac-360.com/console/v1/companies/{companyId}/certificates" \
  -H "Content-Type: application/json" \
  -d '{
    "environment": "BETA",
    "pfxBase64": "…",
    "pfxPassword": "…",
    "solUser": "MODDATOS",
    "solPassword": "…"
  }'

A partir de aquí sigue el Quickstart: ensaya con POST /api/v2/documents/validations, que no crea nada y no consume cuota, y cuando el mapeo esté limpio emite contra beta y recoge el CDR.

5. Prepara producción sin dejar beta

La misma ruta, con "environment": "PRODUCTION" y tu certificado digital real y las credenciales SOL del contribuyente.

Puedes hacerlo mientras sigues desarrollando: la empresa continúa en beta y emitiendo contra beta, y la configuración de producción queda esperando. Actívala con POST /console/v1/companies/{companyId}/certificates/{configurationId}/activation, que la deja armada.

Un certificado de producción no llega a ACTIVE hasta que la plataforma firma con él y SUNAT acepta. Eso ocurre en tu primer comprobante real, después del paso 6.

6. Promueve

curl -X POST "https://apifact.fac-360.com/console/v1/companies/{companyId}/promotion"

Sin cuerpo: no hay nada que decidir. Responde con la fecha y con cuántos ensayos se cerraron.

{
  "companyId": "…",
  "sunatEnvironment": "PRODUCTION",
  "cancelledDocuments": 3,
  "promotedAt": "2026-08-18T14:22:05.881Z"
}

Requiere rol OWNER y segundo factor. Se niega si te falta la configuración de producción armada o si queda algún envío de beta en vuelo.

Lo que ensayaste en beta se queda como está, con su CDR y su entorno. Lo que creaste y nunca enviaste queda CANCELLED. Y tu numeración de producción empieza limpia: los correlativos van por entorno.

Los detalles están en Entornos.

Si prefieres una plataforma que da de alta a sus clientes

Todo lo anterior tiene su gemelo en /api/v2/organizations/* con una credencial de organización (companies:manage), para que tu producto dé de alta empresas, les suba certificados, les acuñe credenciales y las promueva sin que nadie entre a una consola.

Esa credencial no puede emitir comprobantes, y no es una convención: ningún scope documents:* es admisible en ella y la base de datos lo rechaza.