Autenticación y API keys

Cada clave pertenece a una integración y a un único workspace. Envía el secreto en todas las solicitudes:

Authorization: Bearer YOUR_API_KEY

El identificador de la ruta debe coincidir con el workspace de la clave. No uses la cookie del dashboard como credencial de integración.

Elige permisos por operación

• Perfiles: contacts:read, contacts:write y contacts:delete.
• Suscripción: contacts:email:subscribe. Registrar o importar evidencia requiere además el permiso explícito contacts:email:consent:import.
• Audiencias: segments:read y segments:write. Este último también permite crear y guardar definiciones de campos personalizados; leerlas usa contacts:read.
• Envíos: emails:send:transactional o emails:send:marketing según la finalidad.
• Consulta de correo y analítica: emails:read. Consultar eventos de un correo exige también events:read.
• Eventos externos de automatización: events:write.

La clave y su integración deben permanecer activas y permitir la operación. La autorización se comprueba de nuevo al procesar trabajo pendiente; una clave revocada no mantiene acceso por haber iniciado antes una operación.

Rota credenciales

Crea una clave nueva, actualiza el secreto del backend, comprueba una operación permitida y revoca la anterior. El secreto solo aparece al crear la clave; no se recupera desde el listado. Una repetición idempotente de la creación tampoco vuelve a revelarlo.

La idempotencia se vincula a la integración, por lo que rotar sus claves no crea una identidad de operación distinta. Mantén la misma clave de idempotencia para reintentar la misma operación con una credencial nueva de esa integración.

Distingue los límites de acceso

Las claves no tienen permisos administrativos de facturación, miembros, remitentes, diseños, difusiones, automatizaciones ni webhooks. Esas rutas requieren sesión humana. Una ruta no ofrecida a integraciones devuelve 404; añadir permisos no la habilita.

Consulta Integraciones y API keys y errores.