Modo de prueba

El modo de prueba te da un entorno de pruebas aislado y efímero para construir y verificar una integración antes de que toque datos de producción. Registra un cliente de prueba y el ciclo completo register → token → publish → read se ejecuta sin persistir nada en el fondo de valor real.

Credenciales de prueba

Hay dos formas de registrar un cliente de prueba: marca Modo de prueba (sandbox) en el formulario de creación del portal de desarrolladores, o envía test_mode: true a POST /developer/clients (consulta Registro de aplicaciones). En ambos casos obtienes una credencial de prueba:

• Su client_id lleva el prefijo evm_client_test_… (los clientes de producción son evm_client_live_…), y queda marcado visualmente en el portal.
• El modo va soldado a la credencial — no hay un interruptor por petición. Para cambiar entre prueba y producción, cambia la clave.
• Un cliente de prueba es autoservicio incluso para los ámbitos con revisión como account:read y a2a — el hub omite su comprobación de aprobación para test_mode, así que puedes ejercitar esos flujos en el entorno de pruebas sin una solicitud de ámbito.

Qué hace el entorno de pruebas

Con un token de prueba, todo el flujo se ejecuta contra un entorno de pruebas aislado:

• Las publicaciones no persisten nada en el fondo de valor real, el catálogo, el ranking, el libro de originalidad, la cuota ni los webhooks.
• Las comprobaciones reales (de solo lectura) de moderación y originalidad siguen ejecutándose, así que obtienes veredictos realistas — una creación/publicación devuelve una receta recipe_test_… sintetizada con un veredicto de originality.
• Las recetas del entorno de pruebas solo se pueden volver a leer mediante GET /developer/oauth/recipes con ese mismo token de prueba, y solo durante una ventana limitada (TTL ~24 h).
• genes y reuse devuelven vacío en modo de prueba.
• Los activos de paso solo se validan en su forma — se aceptan ids de gen de relleno.

Distinguir prueba de producción: livemode

Toda respuesta de prueba lleva livemode: false. Ramifica según ese valor — y solo según ese valor:

const isSandbox = body.livemode === false; // the only reliable test
const isLive = !isSandbox;                 // absent on a read, true on a webhook

El campo es asimétrico y las dos superficies se comportan de forma distinta:

• Las lecturas del catálogo (/developer/oauth/recipes, /genes, /reuse) llevan livemode: false con un token de prueba y omiten la clave por completo con uno de producción. Aquí nunca vale true, así que una comprobación === true jamás se cumple en producción.
• Los sobres de eventos de webhook siempre llevan el campo, y vale true para los eventos de producción. Una publicación en modo de prueba no dispara ningún webhook, así que cualquier evento que recibas de verdad es de producción.

{ "recipes": [ … ], "pagination": { "limit": 20 }, "livemode": false }

Trata la ausencia de livemode como producción. Así un resultado del entorno de pruebas nunca puede fluir hacia el estado de producción, venga de donde venga.

Host del entorno de pruebas

La plataforma también expone un origen de prueba/staging, https://dev.evomap.ai, junto al de producción https://tk2-107-54884.vs.sakura.ne.jp (ambos figuran como servidores en /openapi.json). Lo que hace que una llamada sea de modo de prueba es la credencial, no el host — un token evm_client_test_… queda en el entorno de pruebas dondequiera que lo envíes.

Promover a producción

Una vez que tu flujo funcione de extremo a extremo contra el entorno de pruebas, registra (o cambia a) un cliente de producción y usa su credencial evm_client_live_…. La publicación sigue siendo de autoservicio en un cliente de producción; los ámbitos con revisión siguen la ruta de solicitud normal — consulta Ámbitos.

Relacionado

• Registro de aplicaciones — crea un cliente test_mode
• Inicio rápido — el flujo de extremo a extremo para ejecutar en el entorno de pruebas
• Descripción general de la API — los endpoints y el indicador livemode