zendesk v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-zendesk-api-token

Custody

customer_vault

Injection

header (Authorization)

A Zendesk API token used as HTTP Basic credentials, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Basic', one separating space, then the Base64 encoding of '{email_address}/token:{api_token}' exactly as Zendesk's API reference shows — 'Basic <base64>'. Token issuance is an external process: an admin enables API token access in the Zendesk Admin Center (Apps and integrations > APIs > Zendesk API) and adds a token; the executor performs no token lifecycle itself and injects the stored value verbatim. Note that Zendesk's own security documentation marks API tokens deprecated and directs existing basic-authentication/API-token customers to migrate to OAuth access tokens; where the deployment supports it, prefer OAuth. Custody boundary — account-level token, user-selected identity: an API token is an account-level credential managed in the Admin Center (the page lets an admin view, add or delete tokens, and more than one token can be active at the same time), while the '{email_address}/token' prefix selects which user the request authenticates AS — Zendesk warns that, as passwords, API tokens can be used to impersonate anyone in the account, including admins. Deactivating or deleting the user whose email prefixes the token prevents authentication AS that user, but does not necessarily revoke the account-level token value for other eligible users: deleting the token in the Admin Center revokes the value itself, and Zendesk documents that deleting a token deactivates it permanently. Least privilege: the token authenticates AS the user whose email prefixes it and inherits that user's full permissions, so pair the token with a dedicated least-privilege service account whose role covers exactly the registered capabilities. Expiry: API tokens do not expire on their own. Boundary: if the deployment also runs OAuth against the same account, deleting this API token (or the OAuth client) does NOT revoke already-issued OAuth access or refresh tokens, which must be revoked separately. OAuth 2.0 with scoped access tokens is the stronger option where the deployment supports it; review the owning account's role and token inventory before enabling. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• zendesk-account-tickets (api, pii): https://your-org.zendesk.invalid/api/v2/tickets
• zendesk-account-users (api, pii): https://your-org.zendesk.invalid/api/v2/users
• zendesk-account-organizations (api, internal): https://your-org.zendesk.invalid/api/v2/organizations

The endpoint host 'your-org.zendesk.invalid' is a reserved non-production placeholder (.invalid is an RFC 2606 reserved TLD that can never resolve): substitute the account's own Zendesk subdomain host (your-subdomain.zendesk.com — the documented Zendesk API subdomain for the account; this review found no Zendesk documentation supporting host-mapped support domains as an interchangeable API destination, so none is offered) before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required pre-enablement step. Note that allowlisting the reserved placeholder host does NOT make an unsubstituted pack safe: an unsubstituted pack has never been bound to the account it claims to govern, and its review says nothing about that account. This pack registers only endpoints the official Zendesk Ticketing API reference documents: the tickets, users and organizations collection reads, single-ticket creation and single-ticket update. All read capabilities cover the COLLECTION read only: single-record reads (GET /api/v2/tickets/{ticket_id}, /api/v2/users/{user_id}, /api/v2/organizations/{organization_id}), show_many, search, autocomplete, counts and incremental exports are not registered by this pack. Effect-level declaration: a ticket create sets the ticket's first comment, and a ticket update can add a comment; Zendesk documents that end users can see public comments, that collaborators receive email notifications when tickets are updated, and that tickets created through the API may trigger business rules that send email notifications to end users — so the unrestricted effect of both write operations includes transmitting to the customer, and both declare send at the R3 floor alongside create/update. send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer): a public reply cannot be un-emailed once delivered. An internal-note-only ticket create or update (comment with public=false) is NOT registered: the public flag is a request-body property of the same POST/PUT endpoint, and a pack registers an endpoint, not a body value, so nothing in the registration would enforce the note-only restriction — the honest outcome is to register the write at its unrestricted effect (send/R3) or not at all, and an estate that wants an R2 note-only capability must enforce the flag in an adapter it reviews itself. Documented exclusions: this pack does not register ticket delete, bulk delete or permanent delete, ticket merge, mark-as-spam (which suspends the requester), user create/update/delete or merge, organization create/update/delete or merge, the Requests API, side conversations, and satisfaction-rating writes — a documented exclusion, not an approximated capability. Data-class rationale: tickets and users identify individuals and carry their correspondence, so both are pii; organizations describe customer companies (names, domains, notes) and are registered internal. The review state is draft, not library: the endpoints are verified against the provider documents named in the review block, but the custody-model review the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates on — issuance authority, scope, audience, TTL, revocation, executor access and bypass paths — is unfinished for this pack.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.zendesk.com/api-reference/ticketing/tickets/tickets/ (retrieved 2026-09-21)
• https://developer.zendesk.com/api-reference/ticketing/users/users/ (retrieved 2026-09-21)
• https://developer.zendesk.com/api-reference/ticketing/organizations/organizations/ (retrieved 2026-09-21)
• https://developer.zendesk.com/api-reference/introduction/security-and-auth/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.