Conectá agentes, automatizaciones y sistemas externos

Una integración necesita una credencial, la URL base de esta instalación y solamente los permisos indispensables para su trabajo.

1. Abrí Agentes e integraciones.
2. Creá una credencial con un nombre descriptivo y alcance mínimo.
3. Guardá la clave en el secret store del integrador. Se muestra una sola vez.
4. Comprobá la identidad con GET /api/agent/v1/me.

curl --fail-with-body \
  -H "Authorization: Bearer <TOKEN>" \
  "https://inmos.wizzi.com.ar/api/agent/v1/me"

Podés desarrollar y comercializar agentes, automatizaciones o conectores compatibles con Wizzi sin acceder a una cuenta real durante el desarrollo. El cliente en común aporta la autorización cuando decide contratar el servicio.

WhatsApp, Telegram, n8n, Make, el proveedor de IA, el alojamiento y los costos de esa infraestructura pertenecen al servicio del integrador. Wizzi aporta la API autorizada, el servidor MCP y los eventos.

Enviá la credencial como Bearer token. No envíes agencyId, userId, roles ni permisos: el servidor los resuelve y valida en cada solicitud.

Authorization: Bearer gi_live_<prefijo>.<secreto>

La API v1 devuelve siempre el envelope { data, error, requestId }. La especificación OpenAPI es la fuente de verdad para rutas, métodos y cuerpos.

Toda escritura debe llevar una clave de idempotencia estable. Si el integrador reintenta la misma operación, reutiliza la misma clave.

Idempotency-Key: 00000000-0000-0000-0000-000000000000

curl --fail-with-body \
  -H "Authorization: Bearer <TOKEN>" \
  "https://inmos.wizzi.com.ar/api/agent/v1/properties?search=Mitre&pageSize=10"

El servidor MCP expone tools pequeñas y explícitas. Funciona con clientes compatibles como Claude, Cursor, n8n u otra infraestructura que implemente MCP remoto.

{
  "url": "https://inmos.wizzi.com.ar/api/agent/mcp",
  "headers": {
    "Authorization": "Bearer <TOKEN>"
  }
}

El agente debe buscar primero, resolver un ID inequívoco y recién después escribir. Nunca coloques la credencial en el prompt, la memoria del agente ni los mensajes del usuario.

Registrar o deshacer pagos, pagar liquidaciones y cambiar estados sensibles de contratos requieren aprobación humana desde la sesión web.

X-Confirmation-Id: <CONFIRMATION_ID>

La confirmación queda ligada a la acción, el recurso y todos sus parámetros. Cambiar el monto, el ID o cualquier otro parámetro la invalida.

Los webhooks notifican cambios; la API sigue siendo la fuente de verdad. Solo se aceptan destinos HTTPS públicos y las entregas se firman con HMAC-SHA256.

X-Wizzi-Event: contract.activated
X-Wizzi-Delivery-Id: <DELIVERY_ID>
X-Wizzi-Signature: sha256=<HEX_HMAC>
Content-Type: application/json

Verificá la firma sobre los bytes crudos exactos antes de parsear el body. Deduplicá entregas repetidas usando X-Wizzi-Delivery-Id o el ID del evento y respondé rápidamente con 2xx.

Catálogo de eventos

Las suscripciones guardan una selección concreta. Cuando se agregan tipos nuevos, actualizá o recreá el webhook para incorporarlos.

• Crear una credencial distinta por sistema y aplicar mínimo privilegio.
• Guardar tokens y secretos únicamente en un secret store.
• No incluir credenciales en prompts, logs, capturas ni repositorios.
• Usar HTTPS, timeouts, backoff e idempotencia en todas las escrituras.
• Validar la firma del webhook antes de procesar el body.
• Revocar inmediatamente una integración ante cualquier sospecha.