Known differences

Zendesk

A Zendesk Support account that answers the Support API v2, incremental exports and Help Center reads zenpy and sync pipelines call, plus an MCP server.

Vendor reference: https://developer.zendesk.com/api-reference/ ↗. Machine-readable: compat/zendesk.json.

Surfaces

Kind	Path	Notes
REST	`/api/v2`	tickets, users, organizations, comments, search, views, macros, triggers, webhooks
REST	`/api/v2/incremental`	timestamp and cursor incremental exports, ticket events
REST	`/api/v2/help_center`	Help Center content, read-only
Webhooks	`/api/v2/webhooks`	trigger-driven webhook delivery
MCP	`/mcp`	ticket, user and organization tools with `limit`/`offset` paging

API versions: Support API v2

Supported

Offset pagination with the vendor's 100-per-page and 100-page depth limits, and cursor pagination with page[size]/page[after]
Incremental exports of tickets, users and organizations, the cursor ticket export, and ticket events with include=comment_events
The official SDK zenpy, per the README coverage matrix
OAuth Bearer and API-token Basic credentials; locally minted OAuth tokens are held to their scopes and X-On-Behalf-Of to the user's role
Triggers that fire webhooks on ticket create or update, with Liquid-style {{ticket.*}} placeholders
Zendesk's error envelopes

Not supported

Help Center, community and Talk authoring (create or update an article, create a post, buy a number)
Guide article translations and theme import or publish
The separate Chat and Sunshine products
Group create, update and delete; groups are read-only
/channels/voice/calls, which is not a documented Zendesk route; Talk reporting is stats/incremental/calls

Known differences and test guidance

Scenario	Difference from Zendesk	In your tests
Timestamp incremental export of a ticket you just wrote	As on Zendesk, tickets and ticket events from the most recent minute are withheld, and the window includes `start_time`, so records on the previous watermark come back.	Upsert rather than insert, and do not expect a fresh write in the next delta within a minute. Use the cursor export to resume strictly after the last record.
Authentication in open mode	Any credential is accepted and treated as the account owner unless it carries scopes or impersonates a user.	Do not test credential rejection in open mode.
Webhook delivery	Delivery is best-effort and off the request path; retries use compressed backoff, and a persistently failing webhook is not deactivated. Private and loopback endpoints are refused with 422 by default.	Poll your receiver for delivery rather than expecting it before the API call returns; do not test webhook deactivation.
Write timestamps	`created_at`/`updated_at` on writes use wall time; seeded data is deterministic.	Do not assert that new records sort among the seeded history.
Rate limits	There is no real per-account budget; 429s happen only when injected.	Inject `throttle` or `quota_limit` to test backoff.
Restarts	Durability is opt-in; MCP tool writes are not kept across a restart even when it is on.	Treat each run as starting from the seeded account.

Fault injection

Key	What the client sees
`throttle`	429 with `Retry-After` and Zendesk's "Number of allowed API requests per minute exceeded" body
`fail_next`	The next N calls fail as `throttle` does, then clear
`quota_limit`	429, the same body as `throttle`
`error_rate`	500 `{"error": "InternalServerError", "description": ...}` for the given fraction of calls
`latency_ms`	Fixed added latency on every data-plane request

Applies to every system

The hosted data plane is read-only: a write is refused with 403 writes_disabled. A SOQL, GraphQL or search POST is a read and is answered.
Faults are injected through POST /_admin/faults on a simulator you run yourself; POST /_admin/faults/reset clears them.
Rate limits do not happen on their own unless a page says so. Use fault injection to exercise a client's backoff.
Distributions come from aggregated metadata sketches of data Eon backs up; no customer records; all Era data is simulated.