> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rippit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zendesk

> Technical reference for the Rippit Zendesk data integration: authorization, the read scope, API endpoints, sync behavior, and rate limiting.

A read-only OAuth integration that syncs Zendesk tickets into Rippit on a schedule. For what applies to every integration, see [how data integrations work](/plg/data-integrations). For the security model, see [Data integration security](/security/data-integrations).

## Connection summary

|                                |                                           |
| ------------------------------ | ----------------------------------------- |
| Authorization                  | OAuth 2.0 authorization code grant        |
| Scope requested                | `read` (the only scope)                   |
| Writes to Zendesk              | None. All requests are `GET`              |
| Credentials shared with Rippit | None. No password, no API token           |
| Required Zendesk role          | Admin, to authorize                       |
| Required Rippit role           | Workspace admin                           |
| API base                       | `https://<subdomain>.zendesk.com/api/v2`  |
| Sync method                    | Scheduled polling, incremental per object |
| Attachments                    | Downloaded and stored by Rippit           |
| Maximum historical backfill    | 90 days                                   |
| Field selection limit          | 150 columns                               |

## Before you connect

Rippit can read only what the authorizing account can read. Use a dedicated Zendesk service account so you control what it can see, the audit trail is unambiguous, and the connection does not break when someone leaves.

You will need that account's Zendesk subdomain and admin credentials. You authenticate against Zendesk, never against Rippit, and Rippit never receives the password.

## Data handling

| Question                                      | Answer                                                |
| --------------------------------------------- | ----------------------------------------------------- |
| Is ticket content ingested, or only metadata? | Full content. Comment bodies arrive via ticket audits |
| Are attachments stored?                       | Yes, downloaded and stored rather than linked         |
| Can Rippit modify Zendesk?                    | No. Read scope only, no write code path exists        |
| Is data used to train models?                 | No. Inference only                                    |

## API endpoints

| Object                            | Endpoint                                              | Method |
| --------------------------------- | ----------------------------------------------------- | ------ |
| Tickets                           | `/incremental/tickets/cursor.json`                    | GET    |
| Ticket detail                     | `/tickets/show_many.json?ids=`                        | GET    |
| Ticket audits (comment bodies)    | `/ticket_audits.json`, `/tickets/<id>/audits.json`    | GET    |
| Agents and admins                 | `/search.json`, `/users.json`                         | GET    |
| User detail, including requesters | `/users/show_many.json?ids=`                          | GET    |
| Organizations                     | `/organizations/show_many.json?ids=`                  | GET    |
| Custom statuses                   | `/custom_statuses.json`, `/custom_statuses/<id>.json` | GET    |
| Side conversation events          | `/tickets/<id>`, read off the parent ticket           | GET    |

The `show_many.json?ids=` endpoints are batch lookups of specific records, not list sweeps. Rippit requests only the tickets, users, and organizations already referenced by data it has synced. Agents and admins are the exception: that roster is swept in full, via `/users.json`.

## Sync behavior

|                        |                                                                                |
| ---------------------- | ------------------------------------------------------------------------------ |
| Tickets                | Incremental Export API, cursor pagination, 1000 per page                       |
| Ticket detail          | Refetched by ID, 100 per request, 5 concurrent                                 |
| Ticket audits          | Separate endpoint, not Incremental Export. Paged backward, or per ticket by ID |
| Agent and admin roster | Refreshed hourly                                                               |
| Resumption             | High water mark per object. Changed records only, no full rescan               |
| Update handling        | A ticket updated after sync is repulled on the next pass                       |
| Expected latency       | Up to 3 hours                                                                  |

Sync runs on a schedule rather than on ticket events, which is why data is hours behind rather than immediate.

## Rate limiting

* Requests are batched and cursor paginated to minimize call volume
* `429` responses trigger backoff and retry rather than immediate repeat
* Workers pace against remaining rate limit rather than competing with each other
* Other integrations sharing your Zendesk instance are not starved

## Limiting ingestion scope

Set at connection time:

| Control         | Limit             |
| --------------- | ----------------- |
| Backfill window | Up to 90 days     |
| Field selection | Up to 150 columns |