Conntodo Developers

API REST de la plataforma Conntodo: procesos de evaluación y confiabilidad, clientes, agenda, formularios y pagos — multitenant por workspace, con un contrato único de respuestas.

Primeros pasos

1

Obtén tus credenciales. El equipo Conntodo te entrega la X-App-Key de tu aplicación (identidad pública, no es un secreto de autenticación), un usuario de la plataforma y un workspace sandbox con datos sintéticos para integrar sin tocar producción.

2

Headers obligatorios. Todas las llamadas llevan:

HeaderValorCuándo
X-App-Keyclave pública de tu aplicaciónsiempre (incluye validate/login)
Acceptapplication/jsonsiempre
AuthorizationBearer {token}tras el login
X-Workspace-IDid del workspace activoen todos los recursos de negocio
3

Autentícate en dos pasos — valida el email (devuelve los workspaces de tu app) y luego haz login sobre uno:

curl -X POST https://api.conntodo.com/api/v1/validate \
  -H "Content-Type: application/json" -H "X-App-Key: $APP_KEY" \
  -d '{"email":"integrador@tuempresa.com"}'

curl -X POST https://api.conntodo.com/api/v1/login \
  -H "Content-Type: application/json" -H "X-App-Key: $APP_KEY" \
  -H "X-Workspace-ID: 42" \
  -d '{"email":"integrador@tuempresa.com","password":"…"}'
# → data.token (Bearer, 15 días; renovable)
4

Entiende el contrato de respuesta. Un único envelope en éxito y error; el error_code es estable — discrimina causas por él, nunca parseando message:

// Éxito                                   // Error
{                                          {
  "status": "success",                       "status": "error",
  "code": 200,                               "code": 403,
  "data": { … },                             "error_code": "MODULE_NOT_IN_PLAN",
  "message": "…"                             "message": "…"
}                                          }
5

Importa la colección Postman (con el environment sandbox): 178 requests con los headers ya inyectados. Variables a fijar: baseUrl, app_key, bearerToken, workspace_id.

Versionado: integra siempre contra /api/v1. Las rutas legacy /api/* responden con headers Deprecation: true y Sunset: 2027-07-31. Política: los cambios breaking solo llegan con versión mayor y un mínimo de 6 meses de deprecación anunciada en el changelog.

Listas y paginación

Toda lista sigue el mismo contrato: los elementos van en data (array) y la paginación en meta. Controla el tamaño con ?per_page (default 20, máximo 100) y la página con ?page.

{
  "status": "success",
  "code": 200,
  "data": [ { … }, { … } ],
  "meta": {
    "current_page": 1, "last_page": 5, "per_page": 20,
    "total": 92, "has_more": true, "from": 1, "to": 20
  }
}

Conceptos de la plataforma

Workspace

La unidad de aislamiento multitenant: cada empresa opera en su workspace con sus usuarios, roles, datos y configuración. Todo recurso de negocio exige X-Workspace-ID y la membresía se valida en el servidor.

Application

El producto/front desde el que se consume (Confiable, Summit, …). Se identifica con X-App-Key: filtra los workspaces visibles en el login y define branding y correo de los envíos.

Módulos, planes y add-ons

Las capacidades (procesos, clientes, agenda, calidad, formularios…) son módulos con alcance system (siempre), business (según plan/modo) o addon (comprables). Si un módulo no está en el plan del workspace la API responde 403 MODULE_NOT_IN_PLAN.

Work modes

Plantillas de operación por workspace (multipruebas, calendario, ips, iptc…): definen vistas, secciones visibles y tema. Solo afectan presentación/configuración — los datos viven en las mismas tablas.

Industria y field mappings

Los catálogos y etiquetas de campos se adaptan por industria del workspace (p. ej. «prueba» vs «proceso», «poligrafista» vs «evaluador»). Los keys de la API no cambian; solo los labels.

Orígenes de datos (data sources)

Catálogos configurables por workspace (servicios, estados, sedes, checklist de calidad…). Los endpoints devuelven los valores adoptados por el workspace, no listas globales.

Integración server-to-server

Para sistemas que consumen la API sin un usuario interactivo (ERP, middleware), Conntodo emite client credentials (OAuth2). Cada credencial queda atada a un workspace: sus tokens solo operan ese workspace, con los scopes que se le autoricen — el integrador nunca declara el workspace en los headers, lo resuelve el servidor desde la credencial.

1

Solicita tu credencial al equipo Conntodo indicando el workspace y los scopes necesarios. Recibirás un client_id y un client_secret (este último se muestra una sola vez).

2

Obtén un token con el grant client_credentials:

curl -X POST https://api.conntodo.com/oauth/token \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "TU_CLIENT_ID",
    "client_secret": "TU_CLIENT_SECRET",
    "scope": "processes.read"
  }'
# → { "access_token": "…", "token_type": "Bearer", "expires_in": … }
3

Consume la superficie /api/v1/m2m con el Bearer. Sin headers de workspace — el binding de la credencial manda:

curl https://api.conntodo.com/api/v1/m2m/processes \
  -H "Authorization: Bearer {access_token}"

Scopes disponibles

ScopePermite
processes.readLeer procesos del workspace
processes.writeCrear y actualizar procesos
clients.readLeer clientes/empresas del workspace
forms.readLeer formularios y sus envíos
webhooks.manageGestionar webhooks salientes

Un token puede pedir menos scopes de los autorizados, nunca más. Pedir un scope fuera de lo permitido devuelve 403 PERMISSION_DENIED.

Webhooks salientes

Conntodo puede notificar a tu sistema cuando ocurren eventos en un workspace. Registra un endpoint (HTTPS) desde Ajustes → API/Webhooks o pídelo al equipo; recibirás un secreto de firma (se muestra una sola vez).

Eventos

EventoSe emite cuando…
process.createdse crea un grupo de procesos
process.status_changedun proceso cambia de estado
form.submission.createdse inicia un envío de formulario
payment.confirmedse aprueba un pago

Formato de entrega

Cada evento llega como POST con este cuerpo y headers:

POST https://tu-endpoint/hook
X-Conntodo-Event: process.status_changed
X-Conntodo-Signature: <hex sha256>

{
  "event": "process.status_changed",
  "created_at": "2026-07-07T00:00:00+00:00",
  "data": { "process_id": 123, "from": "activo", "to": "finalizado", ... }
}

Verificar la firma

Calcula un HMAC-SHA256 del cuerpo crudo con tu secreto y compáralo (tiempo constante) contra X-Conntodo-Signature. Rechaza si no coincide.

// Node.js
const expected = crypto.createHmac('sha256', SECRET)
  .update(rawBody).digest('hex');
if (!crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature))) {
  return res.status(400).end();
}
Responde 2xx en menos de 10 segundos. Cualquier otra respuesta se reintenta hasta 3 veces con espera creciente (30s, 5min). Diseña tu handler idempotente: un mismo evento puede llegar más de una vez.

Catálogo de códigos de error

Strings estables: agregar códigos es seguro; renombrar o eliminar uno es breaking change.

error_codeHTTPSignificado
UNAUTHENTICATED401Token ausente, inválido o vencido.
FORBIDDEN403Autenticado pero sin acceso al recurso.
PERMISSION_DENIED403Falta el permiso granular requerido en el workspace.
ACCOUNT_LOCKED403Cuenta bloqueada por seguridad.
WORKSPACE_HEADER_REQUIRED400Falta X-Workspace-ID.
WORKSPACE_ID_INVALID400X-Workspace-ID no es un id válido.
WORKSPACE_ACCESS_DENIED403El usuario no es miembro de ese workspace.
WORKSPACE_CONTEXT_REQUIRED400El endpoint exige contexto de workspace.
MODULE_NOT_IN_PLAN403Módulo no incluido en el plan del workspace.
SUBSCRIPTION_EXPIRED403Suscripción vencida — renovar para continuar.
NOT_FOUND404Ruta o recurso inexistente (o de otro workspace).
VALIDATION_FAILED422Datos inválidos; detalle por campo en errors.
CONFLICT409Estado en conflicto (p. ej. duplicado).
RATE_LIMITED429Límite de tasa excedido — respeta Retry-After.
BAD_REQUEST400Request malformada.
SERVER_ERROR500Error interno — reintenta con backoff.

Changelog de la API

  • Integración server-to-server: client credentials (OAuth2) atados a workspace, con scopes por módulo, y superficie /api/v1/m2m. Ver la guía.
  • Webhooks salientes firmados (HMAC-SHA256): process.created, process.status_changed, form.submission.created, payment.confirmed. Ver la guía.
  • Rate limiting por plan del workspace (429 RATE_LIMITED con Retry-After).
  • Contrato de listas unificado: elementos en data, paginación en meta (antes algunas listas anidaban en data.data).
  • Nuevo header X-App-Key (identidad pública por aplicación): filtra los workspaces de /validate y rechaza logins cruzados entre aplicaciones (403 workspace_not_in_app). Sin la clave el comportamiento anterior se mantiene.
  • Nuevos módulos agenda (sedes, disponibilidad, citas, bloqueos) y calidad (revisión QA de procesos) — ver referencia.
  • Pagos: POST /payments/checkout, GET /payments/intents/{uuid} y GET /billing/summary; pasarelas Wompi, ePayco, Mercado Pago y Stripe.
  • Envelope único en TODAS las respuestas (incluidas excepciones no manejadas) y catálogo error_code estable.
  • /api/v1 como superficie oficial; rutas legacy /api/* con headers Deprecation + Sunset: 2027-07-31.
  • Paginación normada: ?per_page default 20, máximo 100.
  • Colección Postman y environment sandbox publicados.