AI Coding Assistants

You are integrating with the Visito M2M API.

Base URL: https://platform-api.visitoai.com/m2m/v1
Authentication: Authorization: Bearer $VISITO_M2M_TOKEN
Token location: server-side environment variable only
Machine-readable contract: use the current Visito openapi.json

Important rules:
- Never expose the M2M token in browser or mobile client code.
- Use only the scopes required for the integration.
- Send operations are asynchronous and return 202 Accepted with status "queued".
- Include Idempotency-Key on outbound send requests.
- Treat structured error codes as stable programmatic signals.
- Retry a send only with the same request body and the same Idempotency-Key.
- Do not invent routes or fields that are absent from the API contract.

Channels:
- GET /channels

Conversations:
- GET /conversations
- GET /conversations/{conversationId}
- GET /conversations/{conversationId}/messages
- POST /conversations/{conversationId}/reply

WhatsApp templates:
- GET /whatsapp-templates/{channelId}
- POST /whatsapp-templates/{channelId}
- POST /whatsapp-templates/{channelId}/send

Custom AI tools:
- GET /tools
- POST /tools
- GET /tools/{toolId}
- PATCH /tools/{toolId}
- DELETE /tools/{toolId}
- POST /tools/{toolId}/test
- GET /tools/logs
- GET /tools/logs/{logId}

GET requests:
- Retry 429, 502, and 503 with exponential backoff and jitter.

POST send requests:
- On timeout or transient failure, retry only with the identical body and identical Idempotency-Key.
- Never create a new idempotency key merely because the first response was lost.

After 202 Accepted:
- Persist conversationId, replyId, requestEventId, correlationId, and Idempotency-Key.
- Read the conversation messages endpoint and match requestEventId to messages[].eventId.
- Treat queued as pending; do not report it as delivered.

Do not automatically retry:
- 400, 401, 403, 404, or 409

Build a TypeScript backend client for Visito's M2M API.

Base URL: https://platform-api.visitoai.com/m2m/v1
Auth header: Authorization: Bearer process.env.VISITO_M2M_TOKEN

Implement:
1. listChannels(): GET /channels
2. listConversations(params): GET /conversations
3. getConversation(conversationId): GET /conversations/{conversationId}
4. listConversationMessages(conversationId, params):
   GET /conversations/{conversationId}/messages
5. sendReply(conversationId, body, idempotencyKey):
   POST /conversations/{conversationId}/reply
6. listWhatsappTemplates(channelId): GET /whatsapp-templates/{channelId}
7. sendWhatsappTemplate(channelId, body, idempotencyKey):
   POST /whatsapp-templates/{channelId}/send

Requirements:
- keep token server-side only
- require Idempotency-Key for sendReply and sendWhatsappTemplate
- parse JSON error responses with error.code and error.message
- preserve optional error.details
- retry GET requests on 429, 502, and 503 with exponential backoff and jitter
- retry a send only with the identical body and identical Idempotency-Key
- do not retry 400, 401, 403, or 404
- return typed queued responses for 202 sends
- persist replyId, requestEventId, and correlationId for reconciliation
- do not add endpoints or fields not present in the supplied OpenAPI definition

Create a CRM sync job using Visito's M2M API.

Flow:
1. GET /channels and find the WhatsApp channel to use.
2. GET /conversations?limit=50 to sync the current work queue.
3. GET /conversations/{conversationId} before acting on a conversation.
4. GET /conversations/{conversationId}/messages for the external transcript.
5. If a human-approved outbound template should be sent:
   - GET /whatsapp-templates/{channelId}
   - choose an APPROVED template by name and language
   - POST /whatsapp-templates/{channelId}/send with Idempotency-Key

Output:
- typed API client
- durable idempotency key strategy
- execution log with conversationId, replyId, requestEventId, status, and error code
- unit tests for success, 429 retry, insufficient scope, and duplicate idempotency replay

Register a Visito custom AI tool for my backend.

Tool:
- name: check_availability
- description: Check available rooms for a date range and guest count.
- method: POST
- endpoint URL: https://example.com/visito/tools/check-availability
- auth: X-Tool-Key header from process.env.VISITO_TOOL_KEY
- parameters: JSON Schema with checkIn, checkOut, and guests

Use:
- POST /tools to create the tool
- POST /tools/{toolId}/test to verify it
- GET /tools/logs?toolId={toolId} for diagnostics

Requirements:
- do not log secrets
- validate tool input before calling Visito
- return concise JSON from my backend endpoint
- include tests for the generated route handler