Probar solicitudes de API de forma segura

La Referencia de la API pública es de solo lectura. Test Request permanece oculto y la protección del navegador rechaza las solicitudes interactivas antes de enviarlas.

Este reemplazo solo de texto conserva el flujo útil de autenticación y Postman de la guía archivada sin restaurar ninguna de sus siete capturas rechazadas.

Comprende la excepción de localhost

Cuando los mantenedores ejecutan la documentación en 127.0.0.1 o localhost, el modo local de lectura (live-read) solo puede enviar estas operaciones permitidas:

• GET /configs
• GET /countries
• GET /ai/agents/{agent_id}/templates

Esas solicitudes se dirigen a https://api.ordering.co y pueden devolver datos de producción. No actives Test Request, no envíes una solicitud real ni ingreses credenciales, a menos que el proyecto, la operación y la actividad de prueba exactos estén autorizados. Los demás métodos y rutas permanecen bloqueados.

Actualmente no hay un sandbox remoto no productivo aprobado. CORS no es una frontera de seguridad ni prueba que una solicitud no se haya recibido.

Flujo con token de acceso

Usa un token de acceso Bearer cuando una aplicación actúe en nombre de un usuario autenticado. En un entorno autorizado:

1. Prepara una solicitud POST a la operación de autenticación del proyecto previsto.
2. Envía JSON con el correo electrónico o celular del usuario y los campos de credenciales obligatorios.
3. Lee session.access_token de una respuesta correcta.
4. Envía ese token mediante el encabezado Authorization en solicitudes posteriores.

Forma de solicitud sanitizada:

POST https://api.ordering.co/v400/en/YOUR_PROJECT/auth
Content-Type: application/json

{
  "email": "you@example.com",
  "password": "[REDACTED]"
}

Fragmento de respuesta sanitizada:

{
  "error": false,
  "result": {
    "session": {
      "access_token": "[REDACTED]",
      "token_type": "bearer"
    }
  }
}

Encabezado de autorización:

Authorization: Bearer YOUR_ACCESS_TOKEN

Los tokens de acceso Bearer y las claves de API son credenciales distintas. Sus permisos dependen del usuario, la clave, la operación y el middleware; ninguno otorga acceso universal.

Prepara el mismo flujo en Postman

Puedes configurar el flujo archivado en Postman sin capturas:

1. Crea una solicitud con el método POST y la URL de autenticación autorizada.
2. En Body, selecciona raw, elige JSON e ingresa únicamente credenciales sintéticas o autorizadas.
3. Cuando una solicitud autorizada termine correctamente, lee result.session.access_token en la respuesta.
4. Para una solicitud posterior, abre Authorization, selecciona Bearer Token e ingresa YOUR_ACCESS_TOKEN.

No uses una cuenta de administrador solo por conveniencia. Elige un usuario con los privilegios mínimos necesarios para realizar la operación que estás probando.

Flujo de clave de API

Usa una clave de API de usuario solo para una integración autorizada de servidor a servidor. Consérvala en un gestor de secretos del lado del servidor y envíala mediante:

X-Api-Key: YOUR_API_KEY

No pegues una clave en endpoints arbitrarios. La clave es revocable, hereda los permisos asociados al usuario y debe limitarse a la integración que la necesita. Esta guía no afirma que exista una pantalla actual del dashboard ni que las claves tengan una política de vencimiento permanente.

En Postman, agrega X-Api-Key como encabezado de solicitud solo para una prueba autorizada y usa YOUR_API_KEY en ejemplos guardados. Nunca guardes una clave real en un espacio de trabajo compartido, una exportación de colección, una captura o un repositorio.

Borrar credenciales

Scalar no persiste la autenticación. Recargar, salir de la página o seleccionar Clear credentials elimina la sesión de Scalar que está en memoria. Esto no revoca un token ni una clave de API del servidor; usa el flujo de revocación autorizado de la credencial cuando sea necesario.

No se envió ninguna solicitud al preparar esta guía ni se activó ningún control Test Request.