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

Custody

customer_vault

Injection

header (Authorization)

A Mailchimp Marketing API key presented as HTTP Basic authentication, held in the client's own secret manager. The retrieved quick-start guide authenticates with --user "anystring:${apikey}": the username may be any string and the password is the API key. The stored material must be the complete Authorization header value (scheme included): 'Basic ' followed by the base64 encoding of '<anystring>:<apikey>' exactly as issued. There is no token-issuance exchange: the key IS the credential, generated in the account's API Keys section and shown only once at creation, per the retrieved quick-start guide, so the custody job stores it once and the executor injects it verbatim; renewal means generating a new key in the account and updating the reference. Expiry and revocation: the retrieved guides document no automatic expiry for API keys — treat a key as valid until deleted; deleting (or disabling) the key in the account revokes it immediately and a revoked key fails closed. Note that simply stopping the creation of new keys does NOT invalidate already-issued keys: each issued key stays valid until that key itself is deleted. Least privilege, stated honestly: Mailchimp documents that an API key provides full account access and offers no per-key scoping for API-key authentication, so least privilege cannot be expressed in the key itself — it must come from which account and user issues the key and from AAES policy and capability scope; the retrieved guides point to OAuth 2 as the alternative for integrations acting on behalf of other users. 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.

• mailchimp-audiences (api, pii): https://mailchimp-dc.invalid/3.0/lists
• mailchimp-campaigns (api, internal): https://mailchimp-dc.invalid/3.0/campaigns

The endpoint host 'mailchimp-dc.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): the Marketing API host is data-center-specific (<dc>.api.mailchimp.com, where <dc> is the server prefix visible in the account's browser URL, e.g. us19, per the retrieved quick-start guide), so substitute the customer's real <dc>.api.mailchimp.com host before enabling, in every endpoint, in the resource locators and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. The Marketing API is version 3.0 (the retrieved fundamentals page: version 2.0 is deprecated, versions 1.x are gone). Tiering rationale: campaign send delivers email to an entire list of end recipients, so although the vendor operation is a POST to an actions subresource it is registered as create and send at the R3 floor — send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Member upsert is registered as create, update and send at the R3 floor: the unrestricted request body can set a member's status to pending, which triggers Mailchimp's double-opt-in confirmation email to that address — a message to an end recipient — and can set status to subscribed, which re-enables marketing mail; an installer's intention is not a restriction, so consent enforcement must come from policy and review, not from this registration. Campaign send is registered as create and send at the R3 floor: a campaign can be edited after creation, and targeting, subscription status and exclusions determine the actual recipients. Documented exclusions — this pack does not register: permanent member erasure (the members delete-permanent action, Mailchimp's GDPR-oriented irreversible erasure — the truly irreversible member operation, deliberately left out); batch operations (one call executing many operations, which would defeat per-call review); automation flows and classic automation queue management (programmed sends outside a single reviewed action); transactional email (the separate Mandrill/Transactional API); webhook management (redirecting where member events flow); template, segment and interest-category administration; e-commerce store operations; and the OAuth2 authorization-code flow for third-party integrations — each is a different registration requiring its own review, and none is approximated here. Documentary limitation recorded at the 2026-09-21 re-review: the operation-specific reference pages for the member add-or-update call and the campaign send action returned only the reference site's API index from the review environment, so upsert's delivery effects and campaign-send targeting remain verified against guide-level documentation only — one reason this pack stays draft.

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

• https://mailchimp.com/developer/marketing/docs/fundamentals/ (retrieved 2026-09-21)
• https://mailchimp.com/developer/marketing/guides/quick-start/ (retrieved 2026-09-21)
• https://mailchimp.com/developer/marketing/api/campaigns/ (retrieved 2026-09-21)
• https://mailchimp.com/developer/marketing/api/lists/ (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.