Operational considerations for Zendesk Reader
The following links provide additional guidance and best practices for deploying and managing Zendesk integrations in Striim.
Recovery behavior
Initial load: recovery is not supported. If an initial-load run is interrupted or fails, you must rerun the initial load.
Incremental load: supports standard Striim recovery semantics (A1P/E1P) to resume from the most recent checkpoint.
API rate limiting
Zendesk imposes global and per-user/app request limits. When limits are exceeded, the API returns HTTP 429 responses and the reader may halt until limits reset.
Reduce concurrency (Thread pool count) and/or increase Polling interval to lower request frequency.
Limit the scope of sync by narrowing the Objects list instead of using broad wildcards.
Lower Fetch size (maximum 100) to decrease per-call payload and retry pressure.
Stagger multiple applications reading from the same Zendesk account to avoid bursts.
Metrics monitored by the Zendesk Reader
Metric | Description |
|---|---|
Number of deletes | Number of delete operations |
Number of DDLs | Number of data definition language operations |
Number of PKUpdates | Number of primary key update operations |
Number of updates | Number of update operations |
Number of inserts | Number of insert operations |
For more information, see Monitoring Guide.
Limitations
Initial Load for Tickets, Users, and Organizations retrieves only active records. Zendesk automatically archives tickets 120 days after closing, and the API used for Initial Load does not return archived records. To retrieve all records including archived tickets, users, and organizations, use Automated mode.
Custom objects are not supported.
Some secondary objects depend on primary objects (for example, comments- or metrics-related objects may require the corresponding primary ticket object). If a dependent primary is not selected, reads may be empty.