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
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.