Key takeaway
Knowing where records live is not enough to promise delivery. Establish who can extract which history through which supported route, then keep technical availability separate from disclosure authority.
Name the actor as well as the source system
A company may own a support archive while depending on another firm to run the exporter. Those are different facts. Write down the source account, export operator, application owner, authentication arrangement and specific API or supported export path before saying that a recipient can receive the records. Record credential references securely; do not put actual credentials in the commercial brief.
The owner decision is practical: is the promised package obtainable through this route within the proposed window? Rights, confidentiality and privacy are independent questions. Administrative access can help perform an authorized internal check without granting permission for a new external use. A vendor describing its connector does not establish your account's retained history, entitlement or disclosure authority.
Define the required evidence layers. Current ticket rows, historical changes, comments and attachments may answer different buyer questions. A successful current-state export should not be described as a complete event history. Keep each layer in the register until a permitted internal test establishes what is actually available.
Plan for actor-specific API changes
Zendesk's September 22, 2026 announcement is an example of why the actor matters. As checked October 12, it schedules restrictions on Incremental APIs for third-party developers to begin December 2, 2026, with a January 19, 2027 completion target and a December 17–January 4 rollout pause. These are future announced dates, not a report that every third-party route is already unavailable.
The announcement covers third-party apps and integrations whether or not they appear in Zendesk Marketplace. It says internal integrations may continue using Incremental APIs and third-party developers using affected APIs must migrate. Its alternatives table is endpoint-specific; the listed incremental voice calls and legs endpoints have no alternative there. Do not turn that table into a guarantee that another endpoint returns identical history.
Ask the platform owner to establish the actual integration classification and supported route. A project performed by a third party should not simply be renamed internal to avoid a restriction. The announcement cannot determine the classification of your implementation. If a proposal depends on an exception or extension, keep it unresolved until the responsible platform owner has current written evidence.
Complete an extraction route register
This hypothetical company is considering a support-record license. The register below is an invented planning exercise, not a test of a real Zendesk account or a claim of available inventory. Its company-maintained integration and contracted connector are deliberately listed separately. No row approves disclosure or a recipient sample.
The completed decision is to hold the proposed recurring commitment while the actor-specific change and missing-history questions are resolved. The owner can still prepare a bounded metadata description. A route that remains technically available may be a candidate for an authorized feasibility test; it is not a substitute for the rights review.
| Illustrative route | Evidence still needed | Decision before promising |
|---|---|---|
| Company-maintained internal ticket export | Internal classification, account access and retained period | Candidate for scoped internal test; rights remain separate |
| Third-party incremental ticket connector | Affected endpoint and supported migration design | Hold recurring promise across announced restriction dates |
| Historical voice incremental route | Account history and alternative supported method | Hold; announcement lists no alternative for calls/legs |
| Comments and linked attachments | Authorized retrieval, linkage and completeness results | Do not promise them from a successful ticket-row test |
Budget the actual request path
Zendesk documents both plan limits and endpoint-specific limits. Its current rate-limit table lists 10 requests per minute for Incremental Exports, or 30 with the High Volume add-on. A larger account plan limit does not automatically become the rate available to that endpoint or your particular job. The documentation also describes response rate headers and a Retry-After interval with 429 errors.
In a second hypothetical calculation, the extraction design needs 1,200 calls and the operating owner allocates three calls per minute to the job. Dividing 1,200 by three gives a 400-minute request budget, or six hours and forty minutes. This is a throughput-only planning lower bound under the invented allocation, not a completion forecast. Network work, retries, backoff, transformations, attachments and review may extend elapsed time.
Record where the 1,200-call estimate came from and what it excludes. Do not estimate requests from row count alone if pagination, linked objects or a second history endpoint changes the workload. Ask how the job shares capacity with ordinary business integrations and who can pause it if the source account becomes constrained. A deadline unsupported by that design should remain a proposed date.
Approve a feasibility check before a delivery promise
The smallest useful check specifies an approved internal scope, test role, endpoint/version, covered dates, expected layers, request controls and stop condition. Prefer a schema or synthetic demonstration where it answers the structural question. If inspecting actual records is necessary, the company needs authority for that internal access and handling; an inquiry does not authorize VOID or a prospective buyer to run the exporter.
Retain observed response limits, retrieved layers, missing relationships and the test's coverage limits. Distinguish unavailable through this route from absent in the source. An unreadable attachment or missing audit event may require another authorized investigation rather than an invented replacement. Have the operational owner accept the feasible scope and engineering budget before including them in a commercial delivery schedule.
Use inventory for source categories and readiness for the unresolved tasks. The support-history guide then helps interpret what the retained events mean. VOID can explore fit and an approved named introduction using metadata, with no upfront seller referral fee. Extraction assistance, a sample and any license or recurring feed are separate commitments; API access itself grants none of them.