Mailchimp Marketing API keys

• trufflehog 3.97.4
• gitleaks 8.30.1
• Twin source data-center suffix by example · observed 2026-09-23 · the page states "if your API key is 0123456789abcdef0123456789abcde-us6, then the data center subdomain is us6" and that the <dc> URL prefix "corresponds to the data center for your account" — establishing a literal us<N> data-center suffix after the dash. It backs a marker twin only; the 32-byte hex body stays tool-corroborated and the positive tier is unchanged

Mailchimp's own fundamentals page (mailchimp.com/developer/marketing/docs/fundamentals/, observed 2026-09-23) states the key shape only by example — "if your API key is 0123456789abcdef0123456789abcde-us6, then the data center subdomain is us6" — and that example body is 31 hex bytes, documentation noise against both pinned tools' 32: trufflehog 3.97.4's mailchimp detector matches [0-9a-f]{32}-us[0-9]{1,2} anywhere, gitleaks 8.30.1's mailchimp-api-key rule a keyword-plus-assignment-gated [a-f0-9]{32}-us\d\d with exactly two digits. This contract adopts the one-or-two-digit range the provider's own single-digit example corroborates, so a single-digit-datacenter key is an expected gitleaks false negative. The value has a grammar (unlike twilio-auth-token's bare hex) and is scored on it, but every positive carries the same-line mailchimp keyword gitleaks and the product both require; a keyword-less key is an accepted product false negative not fixtured here, per the new-relic-license-key precedent for keyword-gated grammars. Audience/list/campaign ids are far shorter than 32 hex bytes and a bare -us<N> suffix never matches without the body. redact-secret#313 (PR #678) froze the identical grammar on the product side. Since 2026-09-24 (docs/decisions/2026-09-24-stop-asserting-provider-undecided-format-properties.md) the claim covers us<N> data-center suffixes only: whether any other literal (keyhacks admits any [0-9a-z]{2,5}, e.g. eu6) is ever issued is not stated by Mailchimp, so no scored fixture asserts silence on it. Likewise whether the body may carry g-z letters (the 2009 staff regex and keyhacks admit [0-9a-z]; both provider examples are hex) is outside the claim: the pattern claims hex bodies only and no scored fixture asserts silence on a g-z byte.