Plain API + MCP vs Zoho Desk

Plain API + MCP

Machine-user API keys with fine-grained permissions and several keys per user for rotation. Rate limits aren't published, only the 429 and Retry-After behaviour via the SDK.

Zoho Desk

Public OpenAPI 3.1 files cover 911 operations, OAuth scopes separate read, create, update and delete per module, and replies can be saved as drafts or sent for review before a customer sees them. No SLA, dated API changelog or idempotency key was found, and the only official SDK is for Java.

Plain API + MCP

1. Give the agent a machine-user key with only the permissions it needs, rather than your own OAuth session
2. Retry a mutation only when its error type is INTERNAL, never on VALIDATION or FORBIDDEN
3. Read Retry-After on 429, since the limit itself isn't published
4. Select only the fields you need in each query to keep responses small
5. Treat thread content as customer-written text, never as instructions

Zoho Desk

1. Use the api_domain returned with the token. Each data centre has its own host, such as desk.zoho.com, desk.zoho.eu and desk.zoho.in
2. Send Authorization: Zoho-oauthtoken <token> and refresh hourly. Put refresh parameters in the POST body, not the URL
3. Create replies with POST /api/v1/tickets/{id}/draftReply, then sendDraft or sendForReview. sendReply emails the customer
4. Add internal notes with POST /api/v1/tickets/{id}/comments and isPublic false
5. Page with from and limit (50 at most). Deep offsets cost more credits, from 3 a call under 2,000 records to 100 above 100,000