apollo 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-apollo-api-key

Custody

customer_vault

Injection

header (x-api-key)

An Apollo API key, held in the client's own secret manager. The stored material must be the complete x-api-key header value: Apollo's own documentation sends the bare key with no scheme prefix. Key scoping, reconciled against the retrieved endpoint references: each of the five registered endpoints' reference pages lists its API key access as the endpoint path itself OR a master key, so endpoint-scoped authorization is documented for every capability in this pack — including the two sequence operations (api/v1/emailer_campaigns/search and api/v1/emailer_campaigns/add_contact_ids). Apollo documents the scoped key as the default key kind (you pick the endpoints; calls to unselected endpoints return 403) and reserves master keys for the few endpoints that require one (for example get a list of users), which this pack does not register. Least privilege is therefore a scoped key granted exactly the five registered endpoints — a master key is NOT required here and would also authorize the write and enrichment surfaces this pack excludes; do not use one. Key lifecycle, per Apollo's create-and-manage documentation: keys are created at Settings > Integrations > API Keys with a name, description and endpoint selection, and existing keys can be regenerated or permanently deleted in the Apollo developer dashboard; no scheduled expiry is documented, so a key remains valid until regenerated or deleted and rotation and revocation are external administrative actions owned by the deployment — an expired, regenerated or deleted value must fail closed. The executor injects the stored value verbatim and performs no credential lifecycle itself. 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.

• apollo-people (api, pii): https://api.apollo.io/api/v1/mixed_people/api_search
• apollo-contacts (api, pii): https://api.apollo.io/api/v1/contacts/search
• apollo-organizations (api, internal): https://api.apollo.io/api/v1/mixed_companies/search
• apollo-sequences (api, internal): https://api.apollo.io/api/v1/emailer_campaigns/search

Every capability in this pack targets Apollo's real shared API host api.apollo.io, so no host substitution is required; the only placeholder is EMAILER_CAMPAIGN_ID in the enrollment path, an UPPERCASE path segment the deployment binds to a concrete sequence before enabling. This pack registers only endpoints verified against the official Apollo developer documentation at docs.apollo.io: people API search, contact search, organization search, sequence search, and add contacts to a sequence. The four reads are documented as POST search endpoints whose effect is a COLLECTION read only — single-record reads and all other endpoints are not registered. Apollo documents that the people API search endpoint does not return email addresses or phone numbers, and that organization search consumes 1 Apollo credit per page — credits are the deployment's budget review, not a bound this pack can state. Effect-level declaration for enrollment: Apollo documents sequences as outreach campaigns used to reach out to contacts over a planned period of time, and documents the add-contacts endpoint as adding contacts to an existing sequence — placing a person into outreach that Apollo then sends, so the documented effect is transmission to a destination outside AAES's control and the capability is declared send at the R3 floor. send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer): once Apollo's sequence emails reach the contact they cannot be un-sent, and an irreversible action cannot be taken without a person. Documented exclusions, framed as what this pack does not register: people enrichment and bulk people enrichment (which spend credits and can reveal personal emails and phone numbers), contact create/update/delete, organization enrichment, account management, sequence creation/update/activation/deactivation/archival, removing or stopping contacts in a sequence, email account and mailbox management, tasks, calls and dialer surfaces, CRM synchronization and push surfaces (a share effect), webhooks, and user administration — a documented exclusion, not an approximated capability. Authentication: Apollo's own documentation authenticates with an 'x-api-key' header carrying the API key; see the credential note for least-privilege key scoping.

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

• https://docs.apollo.io/ (retrieved 2026-09-21)
• https://docs.apollo.io/reference/people-api-search (retrieved 2026-09-21)
• https://docs.apollo.io/reference/search-for-contacts (retrieved 2026-09-21)
• https://docs.apollo.io/reference/organization-search (retrieved 2026-09-21)
• https://docs.apollo.io/reference/search-for-sequences (retrieved 2026-09-21)
• https://docs.apollo.io/reference/add-contacts-to-sequence (retrieved 2026-09-21)
• https://docs.apollo.io/docs/create-api-key (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.