Credenciales del simulador

Para probar tu integración necesitas credenciales, y en el simulador de SPIDI te las das tú mismo: una llamada HTTP, sin hablar con nadie y sin esperar a nadie. Lo que obtienes es tu propio espacio aislado — todo lo que crees (acuerdos, sesiones, eventos) es tuyo y nadie más lo ve.

Esto es el simulador, no producción

El alta self-service (POST /console/register) y toda la superficie /console/** existen solo en el simulador. En producción las credenciales te las entrega SPIDI, y el token se obtiene con POST /api/spidipagos/login usando tus credenciales reales. Si tu código llama a /console/**, se rompe el día que salgas del sandbox.

Una llamada

curl -X POST https://sim-productos.abiertolab.com/console/register \
  -H "Content-Type: application/json" \
  -d '{"email":"tu@correo.com","password":"una-clave"}'

Respuesta 201:

{
  "developer_id": "dev_1f2e3d4c5b6a7890",
  "console_token": "ctok_0a1b2c3d4e5f6071",
  "key": {
    "account_id": "acc_9f8e7d6c5b4a3021",
    "token": "3f6b1c2e-84a1-4e0d-9c77-1d2a5b8e4f30",
    "webhook_secret": "whsec_5e4d3c2b1a098765",
    "short_name": "acc9f8e7d6c",
    "password": "apw_2b7c4d1e8f350a69"
  }
}

Guárdalo entero. Los errores posibles son dos: 400 si falta email o password, y 409 si ese email ya está registrado.

Tres piezas, tres usos

Pieza	Cómo se usa	Para qué
key.token — token de API	Authorization: Bearer contra /api/v1/ext/** y contra /control/**	Integrar: crear acuerdos y sesiones, consultar el estado, forzar desenlaces
console_token — token de consola	Authorization: Bearer contra /console/**	Observar: la traza de eventos, las sesiones y los acuerdos de tu key
key.webhook_secret	No viaja en ninguna petición	Verificar la firma spidi-signature de los webhooks que recibes
key.short_name + key.password	POST /api/spidipagos/login	Ejercitar el login y el refresco de token, que es como te autenticas fuera del simulador

Tienes el token en la mano, pero prueba el login igualmente

El alta te entrega el token de API directamente, así que puedes integrar sin hacer login ni una vez. En producción no es así: allí te autenticas, el token dura poco y lo refrescas.

Por eso el alta te da también short_name y password: para que ese camino —el que de verdad vas a usar— no sea la primera vez que lo ejecutas el día del estreno. → Autenticación

Los dos tokens son espacios separados a propósito: el token de API no abre /console/** y el token de consola no abre la API. Si los cruzas recibes un 401, y ese 401 es la pista de que te equivocaste de token, no de que el token esté mal.

El account_id (acc_…) identifica tu key. Lo vas a necesitar para leer la traza y para listar tus sesiones.

El token de API, en una petición real

curl https://sim-productos.abiertolab.com/api/v1/ext/payment-sessions/status/<session_id> \
  -H "Authorization: Bearer <tu-token-de-api>"

Recuperar el token de consola

Si lo pierdes, POST /console/login con el mismo email y contraseña te da uno nuevo:

curl -X POST https://sim-productos.abiertolab.com/console/login \
  -H "Content-Type: application/json" \
  -d '{"email":"tu@correo.com","password":"una-clave"}'

Respuesta 200: { "developer_id": "dev_…", "console_token": "ctok_…" }.

Ojo: el login rota el token de consola. El anterior deja de valer en ese mismo instante. El token de API no rota: sigue siendo el mismo.

Ver tus keys y sus receptores por defecto

curl "https://sim-productos.abiertolab.com/console/keys" \
  -H "Authorization: Bearer <tu-token-de-consola>"

Devuelve, por cada key, su account_id, su token, su webhook_secret, la fecha de creación y un objeto default_webhooks con cuatro URLs (paid, accredited, fail, captura).

Esas URLs son receptores del propio simulador (/console/hooks/<account_id>/…). Sirven para ver la mecánica de entrega funcionando sin montar nada, pero no prueban tu código: responden siempre, así que si las usas como webhook_url te estás contestando a ti mismo. Cómo recibir el aviso de verdad está en Conducir el ciclo.

Lo que sí hacen los cuatro es dejar en tu traza lo que les llegó —cuerpo crudo, cabeceras y firma— como eventos webhook.received. El cuarto, captura, acepta cualquier cosa y responde 200: es un mirador, no un desenlace.

El webhook_secret

Con ese secreto el simulador firma cada webhook que te envía: calcula un HMAC-SHA256 sobre spidi-timestamp + "." + el cuerpo crudo, en hexadecimal, y lo pone en la cabecera spidi-signature. Tu receptor repite el cálculo con el mismo secreto y compara. El cómo se implementa está en la guía Manejar notificaciones; qué hacer cuando la comparación falla, en Observar y depurar.

Nota sobre el alta antigua

El simulador conserva un alta más vieja, POST /register con { "short_name": "…", "password": "…" }, que devuelve account_id, token y webhook_secret pero no crea token de consola. La verás en el tutorial Recibe tu primer pago. Funciona para integrar, pero sin token de consola no puedes leer la traza. Para probar en serio, usa POST /console/register.

Qué es contrato y qué es andamiaje

• Contrato (existe en producción): /api/spidipagos/login y /api/v1/ext/**.
• Solo del simulador: /console/** (incluido el registro), /control/** y la página de pago con sus claves de prueba.

→ Conducir el ciclo · Entornos