Revise el acceso para cada acción: las lecturas requieren los permisos correspondientes, los cambios de registros necesitan vistas previas y claves de reintento, y los envíos también requieren una política activa revisada por el responsable. Incluya consentimiento, exclusiones, licencias y jurisdicciones en la revisión.
¿Cuáles son los niveles de riesgo?
| Nivel | Acciones | Control |
|---|---|---|
| R0 | workspace.context, workspace.capabilities | Ámbito workspace:read. Siempre visibles cuando se concede el ámbito. |
| R1 | companies.*, trade.*, contacts.*, leads.list, campaigns.list | Permiso de lectura correspondiente y acceso del espacio de trabajo. |
| R2 | leads.create, campaigns.draft | Permiso de creación, vista previa con dry_run, idempotency_key obligatorio para una escritura real. |
| R3 | email.send, sms.send | Permiso de envío, policy_id activo revisado por el responsable, vista previa con dry_run, idempotency_key obligatorio para un envío real. |
Use tools/list para descubrir las herramientas disponibles para su conexión. La disponibilidad depende de los permisos concedidos y del acceso del espacio de trabajo. Empiece con permisos de lectura; pida a un administrador que revise el acceso que falta en lugar de solicitar permisos amplios.
¿Cómo funcionan las políticas vigentes y las revisiones?
Antes de habilitar envíos, un responsable debe revisar la audiencia, el remitente, las afirmaciones del mensaje, el consentimiento, las exclusiones, las jurisdicciones aplicables, las licencias y los límites de presupuesto. Use un policy_id activo para los envíos permitidos y previsualice con dry_run: true. Una política permanente puede autorizar varios envíos; no implica que una persona apruebe cada mensaje por separado. Pause el trabajo si la elegibilidad o la autorización no están claras.
¿Cómo deben usarse las simulaciones y las claves de idempotencia?
- Envíe primero
dry_run: true(simulación) para cada acción R2/R3. El servidor valida los ámbitos, las políticas y los argumentos sin escribir registros ni enviar mensajes. - Genere un UUID
idempotency_keypor escritura prevista y reutilícela en los reintentos. Una clave repetida devuelve el resultado original en lugar de crear un lead, borrador o envío duplicado. - Nunca genere una clave nueva al reintentar una escritura que ha excedido el tiempo de espera. Guarde la clave junto al
request_iden sus propios registros. - Obligatorio para escribir o enviar realmente; reutilice el mismo UUID al reintentar la misma acción sin cambiar los argumentos.
¿Qué cuotas se aplican?
Los límites de solicitudes y uso dependen del acceso del espacio de trabajo y de la acción. Consulte el uso actual con su administrador. Ante quota_exceeded, respete Retry-After y la hora de restablecimiento indicada, y reintente con espera progresiva y acotada. No eluda los límites mediante reintentos paralelos, clientes adicionales o nuevas políticas.
quota_exceeded incluye reset_at y retry_after. Respete Retry-After y reintente con espera acotada. No lance reintentos paralelos ante un 429.
¿Cómo se revoca el acceso y se revisa la actividad?
- Revoque en
POST /oauth/revokeo elimine el cliente OAuth en Settings → Integrations. La revocación detiene tanto las llamadas MCP como las llamadas REST de agentes para ese token. - Revise los eventos de auditoría del espacio de trabajo para revisiones de políticas, envíos y cambios de política.
- Compruebe el uso diario y por ventana antes de aumentar límites o añadir un cliente nuevo.
- Rote cualquier token que haya aparecido en un registro, captura o incidencia. Nunca envíe el token a soporte; envíe el
request_idredactado, la marca temporal, el nombre de la herramienta y el código de error.