gong 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-gong-access-key

Custody

customer_vault

Injection

header (Authorization)

A Gong API access key pair (Access Key and Access Key Secret, created by a Gong technical administrator on the company's API page) 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 Base64(<accessKey>:<accessKeySecret>) per RFC 7617 — 'Basic <base64>'. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Gong access key pairs do not carry an expiry and inherit full API access until revoked; rotation and revocation are performed by a technical administrator in the Gong web app, and an external deployment process owns re-issuing the pair and updating the vault entry — the executor injects the stored value verbatim and performs no credential lifecycle itself. Least privilege: issue a dedicated pair for this integration only and revoke it when the integration is retired; where the OAuth Bearer flow is available, request only the scopes these capabilities need ('api:calls:read:basic', 'api:calls:read:transcript', 'api:users:read', 'api:workspaces:read'). 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.

• gong-company-calls (api, pii): https://gong-instance.invalid/v2/calls
• gong-company-users (api, pii): https://gong-instance.invalid/v2/users
• gong-company-workspaces (api, internal): https://gong-instance.invalid/v2/workspaces

The endpoint host 'gong-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the company's own Gong API base URL host 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 deployment step. Gong assigns each company a base URL shown on the company's API authentication page in the Gong web app; the real substitution shape is '{region}.api.gong.io' (for example 'us-0000.api.gong.io'). This pack registers only endpoints the official Gong API V2 reference documents: listing calls by date range, retrieving call transcripts, listing users, and listing workspaces. Reads are collection reads: single-record reads (GET /v2/calls/{id}, GET /v2/users/{id}), the detailed-call query (POST /v2/calls/extensive) and user stats are not registered by this pack. Documented exclusions: this pack does not register any write path — uploading new calls (POST /v2/calls), adding call media (POST /v2/calls/{id}/media), CRM data upload, permission management including granting users individual access to calls, consent-meeting management, digital-interaction ingestion, and the data-privacy erasure endpoints (deleting all elements associated with an email address or phone number, which are destructive deletes) are all deliberate exclusions, not approximated capabilities. Gong records and transcribes conversations between the company's team members and external participants, so call and transcript data is registered at the pii class; transcripts are the verbatim content of those conversations and carry the highest confidentiality exposure of the four reads. The review state is draft, not library, for a concrete reason: this pack's custody model — a long-lived Basic-auth access key pair held in the customer's vault — has not yet been reviewed against the properties the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates any authentication mode on: issuance authority and delegation, scope, audience, TTL, revocation, executor access and bypass paths. That review is unfinished; Gong's OAuth 2.0 Bearer flow with per-endpoint scopes (available to published apps) is one candidate stronger model, not an automatic pass.

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

• https://help.gong.io/apidocs/introduction-2.md (retrieved 2026-09-21)
• https://help.gong.io/apidocs/retrieve-call-data-by-date-range-v2calls-2.md (retrieved 2026-09-21)
• https://help.gong.io/apidocs/retrieve-transcripts-of-calls-by-date-or-callids-v2callstranscript-2.md (retrieved 2026-09-21)
• https://help.gong.io/apidocs/list-all-users-v2users.md (retrieved 2026-09-21)
• https://help.gong.io/apidocs/list-all-company-workspaces-v2workspaces.md (retrieved 2026-09-21)
• https://help.gong.io/docs/what-the-gong-api-provides (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.