Skip to main content
Cada pedido lleva una clave de la API en el header Authorization:
Sin clave, la respuesta es missing_api_key; con una clave mal copiada, invalid_api_key.

​
Quién crea las claves

La propietaria del estudio, desde Configuración → Integraciones → API, si su plan incluye la API. Al crear una clave elige el entorno, el tipo de acceso y el vencimiento, y la ve una sola vez: Craqui no la guarda en claro y no la puede volver a mostrar. Si se pierde, se crea otra.

​
El prefijo

El principio de una clave dice cómo es:
  • crq_live_ usa los datos reales del estudio.
  • crq_test_ usa su estudio de prueba, un estudio de ejemplo que no le escribe a nadie. Lee Entorno de prueba.
La URL es la misma para las dos: https://api.craqui.com/v1. El entorno lo decide la clave, y cada objeto lo repite en su campo livemode. Una clave que empieza con cra_ es de la API anterior de Craqui y no sirve en esta (legacy_api_key).

​
Permisos

Cada clave tiene una lista de permisos (scopes). Una clave completa tiene todos los que existen hoy; una restringida, solo los que eligió la propietaria. Si una ruta pide un permiso que la clave no tiene, la respuesta es scope_required, con el permiso que falta en required_scope. Los permisos de una clave no cambian: para tener otros, se crea otra clave. El permiso de cada ruta también figura en la Referencia.

​
El contacto va aparte

El email y el teléfono de un cliente son datos personales, así que tienen su propio permiso, clients.pii:read. Sin él, un cliente viene sin los campos email y phone (no vienen en null: no vienen), y filtrar por email o por teléfono responde scope_required. Pide este permiso solo si tu sistema necesita escribirle o reconocer a las personas.

​
Los objetos expandidos

Algunas rutas traen objetos relacionados completos con expand[] (por ejemplo, el cliente de una reserva). Cada objeto expandido pide el permiso de su recurso: expandir el cliente de una reserva pide también clients:read.

​
Qué puede usar cada negocio

Las rutas de esta API son para estudios de wellness. Con la clave de una academia, hoy solo responde GET /business; el resto responde wrong_vertical. Las claves de prueba también son, por ahora, solo para estudios.

​
Cuándo deja de funcionar una clave

En los dos últimos casos la clave no se borra: si la situación cambia, vuelve a funcionar sola.

​
Desde un servidor, nunca desde un navegador

Una clave da acceso a los datos del estudio. En código que corre en el navegador, cualquiera que abra la página la puede leer. Por eso la API rechaza todo pedido que viene de un navegador (con el header Origin) con browser_not_allowed, y no responde a CORS. Para cuidar una clave:
  • Guárdala en una variable de entorno o en el gestor de secretos de tu plataforma, nunca en el código ni en un repositorio.
  • Usa una clave restringida con los permisos justos para cada sistema.
  • Usa una clave distinta por sistema: si una se expone, revocas solo esa.
  • Si una clave se expuso, pide que la revoquen enseguida y que creen otra.