zip 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-zip-api-credential

Custody

customer_vault

Injection

header (Authorization)

A Zip API credential, held in the client's own secret manager. The actual authentication scheme, issuance and renewal process, stored format, expiry, revocation path and available permission granularity are NOT established: Zip's API reference is gated behind an authenticated session, and the only official source available to this review is the ziphq.com integration-ecosystem marketing page, which describes per-API-key and per-OAuth-connection options with resource-, action- and user-role-level permissions but documents none of the underlying mechanics — do not read that page as establishing any of them. The exact header format is likewise NOT verifiable from the official documentation available to this review (third-party integrator documentation describes an API key sent as Basic auth) — the stored material must be the complete Authorization header value (scheme included), and the scheme must be confirmed against the gated API reference before enabling. If the credential proves to be OAuth-based, an external token process must mint and refresh tokens and the client secret stays with that process; expiry and revocation behaviour is NOT established and must be confirmed against the gated reference — an expired or revoked value must fail closed. Least privilege: grant the credential read permissions only, and only for the request, vendor and approval resources this pack registers — the ecosystem page's claim of resource- and action-level permissioning per key is unconfirmed against the reference, so a key that may write or approve anything this pack does not register is a finding. Executor hygiene: the credential must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must never appear in crash reports; the executor's memory, log and crash handling are otherwise the deployment's review.

• zip-requests (api, financial): https://zip-api-docs-gated.invalid/requests
• zip-vendors (api, pii): https://zip-api-docs-gated.invalid/vendors
• zip-approvals (api, financial): https://zip-api-docs-gated.invalid/approvals

READ THIS BEFORE ENABLING ANYTHING. Zip's API reference is gated: Zip's own help center states that API documentation is available only through an authenticated Zip session, and that Zip provides no public OpenAPI specification, Postman collection or PDF export. As of 2026-09-21 the gated reference returns 401 to unauthenticated requests, and the vendor's public developer hub (developers.ziphq.com) is an empty template. What this review could verify from official sources: Zip operates a REST API for extracting, creating and updating data across vendors, requests, invoices and POs, and describes authentication as per API key or OAuth connection with resource- and action-level permissions (both from the ziphq.com integration-ecosystem marketing page, not from the API reference — the actual scheme, issuance, expiry and permission granularity are NOT established), and the API host api.ziphq.com is live. What this review could NOT verify: any endpoint path, method, parameter or response shape — api.ziphq.com returns 401 for every path including nonexistent ones, so unauthenticated probing cannot confirm routes, and the paths written here (/requests, /vendors, /approvals) appear only in third-party integrator documentation, not in any official Zip document this review retrieved. Consequently the endpoint host 'zip-api-docs-gated.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): before enabling, a reviewer with access to the gated reference (sign in to Zip, question-mark menu, API Documentation) must verify every path, method and payload against it and substitute the real host and the verified paths in every endpoint, every resource locator and every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together. Allowlisting the reserved host does not make an unsubstituted pack safe: an unsubstituted pack fails closed at DNS but has no reviewed destination, so it is not a registration of anything. All capabilities are registered as collection reads only at R0. Documented exclusions, framed as what this pack does not register: every create, update and delete; request approval actions (no approval endpoint could be verified, so no approve capability is registered — the scoped request-approve capability is omitted, not downgraded); users, purchase orders, invoices, payments, agreements and audit logs; the Zip MCP server surface; and webhook subscriptions. This pack stays in the draft review state until the gated-reference verification above is performed. AAES has not been certified by Zip; nothing here is a vendor guarantee.

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

• https://docs.ziphq.com/api/v2/help_center/en-us/articles/49398321531675.json (retrieved 2026-09-21) — Zip help-center article, as of that retrieval date: API documentation is available only through an authenticated Zip session and Zip provides no public OpenAPI specification, Postman collection or PDF export
• https://ziphq.com/capabilities/integration-ecosystem (retrieved 2026-09-21)
• https://api.ziphq.com/ (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.