MerCRM

Documentación · se prende por plan

API y agentes

La misma API que usa la consola, con permisos por módulo y herramientas para un modelo.

No hay una API «para integraciones» distinta de la que mueve el producto: lo que hace la pantalla lo hace la API, con las mismas reglas y los mismos límites. Se conecta con un token Bearer creado en Ajustes → Tokens de API.

Lo primero que hace un agente

  • GET /api/v1/auth/me — qué permisos trae este token y por qué persona actúa.
  • GET /api/v1/schema — el contrato completo: cada recurso con sus rutas, el vocabulario del negocio y las reglas que un agente debe respetar. No hace falta mandarle documentación aparte.

Las reglas que no dependen del prompt

  • Un agente nunca puede más que la persona por la que actúa, y lo que escribe queda a nombre de ella con la marca de que entró por agente.
  • Los permisos son por módulo: leer la bandeja y cotizar son dos permisos distintos, y se dan de uno en uno.
  • Cuando se agrega un módulo, sus permisos no se reparten solos entre los tokens que ya existían.
  • Publicar una propuesta o el portal de un proyecto es de personas. Un token recibe 403 aunque actúe por alguien.
  • Un token sin persona detrás no puede crear una propuesta ni contestarle a un cliente: sería una voz de la empresa que nadie firmó.

Como herramientas MCP

El mismo contrato llega ya masticado a un modelo: cada herramienta dice para qué sirve, qué necesita y qué error va a recibir si se equivoca. Los errores dicen qué falta —un permiso, una persona detrás del token, o que eso lo hace un humano— para que el agente sepa qué pedir en vez de reintentar a ciegas.