1. Overview
The Zendesk integration uses OAuth access and refresh tokens to read support tickets, comments, attachments, users, and Help Center articles from one verified Zendesk subdomain.
The normalized Zendesk subdomain is the provider account identity. Seedling uses incremental ticket and article synchronization without interpreting a transient provider failure as deletion.
2. Connection and scope
Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.
- Customer-managed OAuth client
- A Zendesk administrator creates an OAuth client for the account subdomain and completes an authorization-code flow that returns access and refresh tokens.
- Personal or workspace connection
- The token remains bounded by its Zendesk user, role, scope, and account permissions. Seedling verifies the viewer and account settings before storage.
3. Zendesk data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Tickets
- Ticket subject, description, status, priority, type, requester, submitter, assignee, group, organization, tags, custom fields, forms, brands, and lifecycle timing.
- Comments and attachments
- Public and internal ticket comments, authorship, attachment metadata, and authorized content available to the OAuth user.
- Help Center
- Authorized article content, labels, locale, author, section or category context, and archive or draft state where returned.
4. Read-only permission contract
The current connector requires Zendesk's read OAuth scope and a refresh token for recurring synchronization.
- read — read account resources exposed by the current ticketing and Help Center APIs, still bounded by the OAuth user's native role and permissions.
- Refresh-token support — renew short-lived access without asking the user to reconnect for every expiry.
- Seedling does not request ticket write scopes and does not create, update, solve, comment on, or delete Zendesk tickets or articles.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
- Internal comments, attachment content, requester identity, and ticket fields may contain sensitive support data. Seedling never treats an administrator or agent role as automatic workspace-wide audience proof.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Zendesk records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Zendesk credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.