Llamando a la API
Todo lo que hace la aplicación, lo hace a través de la misma API HTTP que puedes llamar tú mismo. Cada endpoint está listado en la referencia de la API REST; esta página cubre las tres cosas que necesitas antes de que cualquiera de ellos funcione.
Autenticación
Section titled “Autenticación”Envía un token de identidad como una credencial bearer:
curl -H "Authorization: Bearer <your-token>" \ https://app.example.com/api/workflowsLos tokens provienen de iniciar sesión. No hay una clave API separada para crear: tu identidad API es tu identidad de usuario, por lo que cualquier cosa que puedas alcanzar en la aplicación la puedes alcanzar con curl, y nada más.
Cada endpoint requiere esto. No hay lectura anónima: una solicitud sin credencial es rechazada antes de llegar al endpoint, sea cual sea el endpoint. El puñado de rutas realmente públicas — la lista de precios, esta documentación — son públicas por decisión explícita, no porque la autenticación sea opcional.
Indica qué workspace te refieres
Section titled “Indica qué workspace te refieres”Si perteneces a más de un workspace, indícanos en cuál actúa una solicitud:
curl -H "Authorization: Bearer <your-token>" \ -H "X-Account-Id: <workspace-id>" \ https://app.example.com/api/workflowsOmitirlo devolverá tu primer workspace. Si envías uno del que no eres miembro, recibirás tu primer workspace en su lugar: el encabezado selecciona entre los workspaces a los que ya perteneces, no otorga acceso a uno al que no perteneces.
El encabezado se llama X-Account-Id por razones históricas; el valor es un id de workspace. En todos los demás lugares, la palabra se refiere a tu propio inicio de sesión.
Solo verás los datos de tus propios workspaces. Un endpoint de colección devuelve tus filas y nada más; solicitar algo en un workspace del que no eres miembro es rechazado en lugar de devolverse vacío.
Qué host llamas importa
Section titled “Qué host llamas importa”Si tu organización tiene más de un producto de marca, el nombre del host que llamas selecciona cuál. La misma credencial en dos hosts diferentes ve dos conjuntos diferentes de workspaces: los que tienes en cada uno. Esto es deliberado: un workspace pertenece a una marca, y una solicitud debe indicar para qué marca es.
Lectura de los errores
Section titled “Lectura de los errores”| Estado | Significado | Qué hacer |
|---|---|---|
401 |
Sin credencial, o no es válida | Inicia sesión nuevamente y vuelve a intentarlo con un token nuevo |
402 |
El workspace no tiene una suscripción activa | Las lecturas aún funcionan; las escrituras necesitan un plan. Consulta Uso y facturación |
403 |
Autenticado, pero no es tuyo para tocar | No eres miembro de ese workspace, o la acción necesita al propietario |
404 |
No encontrado — o no es tuyo | Para recursos dirigidos por nombre, respondemos 404 en lugar de 403 para que la respuesta no confirme que algo existe |
429 |
Limitado por tasa, o crédito prepagado agotado | Disminuye la velocidad; si dice crédito, recarga |
Un 402 merece ser entendido: un workspace no pagado se vuelve de solo lectura en lugar de apagarse. Mantienes acceso a todo lo que ya está ahí y aún puedes exportarlo — simplemente no puedes crear nuevo trabajo hasta que haya un plan nuevamente. Los endpoints de facturación y membresía continúan funcionando, ya que son la forma en que lo solucionas.
Webhooks y embebidos se autentican de forma diferente
Section titled “Webhooks y embebidos se autentican de forma diferente”Dos familias de endpoints no son llamados por una persona autenticada, así que no utilizan tu token:
- Disparadores de Webhook llevan su propio token en la URL, por lo que un sistema externo puede iniciar un flujo de trabajo sin una cuenta de usuario.
- Endpoints de embed están autorizados por el token de embed y la lista de sitios permitidos para usarlo — consulta Incorporar un widget.
Ambos rechazan de inmediato cuando el workspace propietario no tiene una suscripción activa, en lugar de degradar a solo lectura. Un extraño en el sitio web de otra persona no debería ver un problema de facturación.