Zendesk

Zendesk

Zendesk organizes support around tickets, users, and organizations. Tickets move through statuses (new → open → pending → hold → solved → closed). Agents belong to groups; views are saved ticket filters. Macros bundle common agent actions; side conversations run parallel email/Slack/child-ticket threads on a ticket.

Operational order

1. Open queue — list tickets filtered by status (usually open) before drilling into one ID.
2. Single ticket — load by ticket ID; request the comment thread when the task needs conversation history.
3. People lookup — resolve requester or assignee numeric IDs from users (roles: end-user, agent, admin).
4. Reply — add a public comment on an existing ticket, or an internal note when the customer should not see it. Attach files by uploading first, then passing upload tokens on the comment.
5. Create — new tickets need subject plus initial description; set requester_id when acting for a known customer.
6. KB context — search Help Center articles when drafting self-service answers.
7. Keyword-only tasks — global search when you do not know the resource type yet; then fetch by ID from the hit.
8. Macros — list macros, preview on a ticket, then apply when the preview matches intent.
9. Account config — ticket fields, forms, brands, triggers, automations, SLAs, schedules, and CSAT ratings are read-only introspection; do not assume Enterprise features exist until a call succeeds.
10. Side conversations — only when Collaboration is enabled; email uses participant email, child tickets use support_group_id.

Data model

• Ticket — subject, status, priority, type, requester_id, assignee_id, tags, comments.
• User — end-user (customer), agent (handles tickets), or admin.
• Organization — customer company; links users and tickets.
• Group — agent team for routing.
• View — saved filter over tickets (can include ticket rows when needed).
• Article — Help Center KB page.
• Macro — canned ticket updates; preview before applying.
• Side conversation — parallel thread (email, Slack, child ticket, Teams) tied to a parent ticket.
• Attachment — file on a comment; upload yields a short-lived token for comments.
• Ticket field — custom field definition (id + type) used in ticket payloads.
• Trigger / automation — business rules (event vs time-based); read-only here.
• SLA policy / schedule — Enterprise timing configuration.
• Satisfaction rating — CSAT score tied to solved tickets.

Questions you must refuse

• "List every ticket ever" — the API paginates; total_count is not the same as rows returned. State how many rows you actually retrieved.
• "Who has the most tickets in Zendesk globally?" — there is no account-wide ranking endpoint. Compare only tickets you explicitly fetched or filtered.

Gotchas

• Subdomain only: Use the slug from mycompany.zendesk.com (e.g. mycompany), not the full URL or mycompany.zendesk.com. Wrong hosts cause TLS handshake failures.
• Requester vs assignee: Requester is the customer; assignee is the agent user ID.
• Create vs update: New tickets need subject + initial description. Follow-up text on existing tickets is a comment, not a description field change.
• Delete vs close: Deleting removes the ticket permanently; closing is a status update to solved/closed.
• Pagination: List responses include has_more and next_offset when more pages exist.
• Macros: No usage or popularity metrics in the API — list macros by title, then apply or preview by id.
• Triggers/automations: total_count + has_more=false means the full current account list, not a historical archive of deleted rules.
• Rate limits: Zendesk returns HTTP 429 when throttled; back off and retry with a smaller page size.