Mailchimp package v1.0.0

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, according to the reviewed 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, and no revocation semantics either — keys can be deleted in the account, but whether deletion takes effect immediately for in-flight use, and whether any revocation cut-off exists, is not stated in any retrieved source. Treat an issued key as valid until the deployment verifies deletion behavior against the live account, and review that behavior before enabling.

Least privilege: 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.

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, according to the reviewed 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).

Approval classification: 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 minimum R3 tier — send is one of the designated actions requiring human approval.

Member upsert is registered as create, update and send at the minimum R3 tier: 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; intended limits need a separate enforceable control, so consent enforcement must come from policy and review, not from this registration.

Campaign send is registered as create and send at the minimum R3 tier: 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, resolved 2026-09-23: at the 2026-09-21 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. The member-upsert claims were guide-documented at that time (the retrieved create-your-first-audience guide shows the PUT /3.0/lists/{list_id}/members/{subscriber_hash} member update path, names the add-or-update list member endpoint, and states that adding a contact with status pending sends a double-opt-in confirmation email).

On 2026-09-23 the campaign-send operation page (https://mailchimp.com/developer/marketing/api/campaigns/send-campaign/) was retrieved live: it now server-renders the operation entry — post /campaigns/{campaign_id}/actions/send, 'Send a Mailchimp campaign. For RSS Campaigns, the campaign will send according to its schedule. All other campaigns will send immediately.' — and the page's own backing data document (the site's Gatsby page-data JSON) carries the full reference with operationId postCampaignsIdActionsSend, so the send path is now corroborated at operation level, not section-index level.

Honestly stated: Mailchimp publishes no standalone OpenAPI or Swagger document at the probed vendor URLs (those URLs return the site's landing shell, HTTP 200 but no spec); the corroboration above rests on the vendor's own reference site and its backing data, not on a separate published specification.