---
name: mailchimp-oauth-app
description: Creates or signs in to a Mailchimp account and registers an app on the Registered Apps page to obtain an OAuth2 client ID and client secret — with the redirect URI, the fact that Mailchimp has no scopes, the per-account data-centre prefix that must be discovered after token exchange, non-expiring tokens with no refresh token, rotation, and a safe credential handoff. Use when asked to get Mailchimp OAuth credentials, register a Mailchimp app, set up a Mailchimp developer account, rotate a Mailchimp client secret, list an integration in the Mailchimp Marketplace, or debug a Mailchimp connection that authorizes but then 404s or 403s on every API call. For Mailchimp Transactional (Mandrill) or any other vendor's portal, use that vendor's skill instead.
---

# Mailchimp OAuth2 App Registration

Get a working Mailchimp OAuth2 client — an account, a registered app, a redirect URI, client ID and client secret —
for a platform that connects *other organizations'* Mailchimp accounts on behalf of many customers.

The form itself takes two minutes. Four things around it are expensive to get wrong, and none of them is the form:

1. **Mailchimp has no OAuth scopes.** There is no `scope` parameter, no scope list, nothing to declare on the app and
   nothing to line up with the authorize URL. A token is all-or-nothing across everything the authorizing user can
   reach. Least privilege is not available at the OAuth layer — it lives entirely in *which user* authorizes (§5).
2. **There is no fixed API host.** Each account lives in a data centre (`us6`, `us19`, `us21`, …) and the API root is
   `https://<dc>.api.mailchimp.com/3.0/`. You discover `<dc>` by calling the metadata endpoint *after* the token
   exchange and storing it next to the token. Hardcoding any one host breaks for most customers (§6).
3. **The client secret is shown exactly once**, at the bottom of the page right after you click Create. Miss it and the
   only way back is rotation, which breaks every deployed copy of the old secret (§7).
4. **Redirect URI matching is exact**, and Mailchimp's docs and sample code describe *the* Redirect URI, singular. If
   your platform serves four regional callback hosts, settle §4 before you register anything — it may decide how many
   apps you end up with.

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **App name**, description, company/website | Shown to the user on the Mailchimp consent screen |
| **Mailchimp account** that will own the app, and its login email | Must be able to reach account settings — Owner or Admin (§2) |
| **Redirect URI(s)** | Every callback host your platform serves; read §4 before promising all of them on one app |
| **New app, or edit/rotate an existing one?** | Default answer is "existing" (§1) |
| **Marketplace listing wanted?** | Separate program with a 25-active-user bar and a review (§9) |
| **Test Mailchimp account** for verification | A free account is enough to prove the flow; see §10 |
| **Who holds the secret** | Secret store / console — decided before it is generated (§7, §11) |

## Quick Start

1. Confirm a **new** app is actually needed — a new client ID orphans every existing customer connection (§1).
2. Sign in to the Mailchimp account that will own the app, as Owner or Admin (§2).
3. **Registered Apps → Register An App → fill the form → Create** (§3).
4. Set the redirect URI exactly, character for character (§4).
5. Skip the scope step — there isn't one. Read §5 so you can explain what the token *does* reach.
6. **Copy the client secret immediately.** It is shown once (§7).
7. Make sure the client discovers and stores the per-account data-centre prefix after the exchange (§6).
8. Confirm the token model: no expiry, no refresh token, revoked by the user or by removing the authorizing user (§8).
9. Authorize from a **second, unrelated** Mailchimp account, then run one read call (§10) and hand off (§11).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- **Endpoints are fixed and shared by everyone**: authorize `https://login.mailchimp.com/oauth2/authorize`, token
  `https://login.mailchimp.com/oauth2/token`, metadata `https://login.mailchimp.com/oauth2/metadata`. The Marketing API
  itself is **per-account**: `https://<dc>.api.mailchimp.com/3.0/` (§6).
- **The Marketing API is on version 3.0.** The reference page carried `3.0.91` on 2026-09-20. Versions 1.1–1.3 are gone
  and 2.0 is deprecated and unmaintained. The Partner Program requires the *current* version.
- **No scopes are documented anywhere** in Mailchimp's OAuth 2 guide or Marketing API fundamentals — no `scope`
  authorize parameter, no scope catalogue, no per-app permission checkboxes (§5).
- **Access tokens do not expire and there is no refresh token.** Mailchimp states this outright: a token stays valid
  until the user revokes the app's permission (§8).
- **Redirect URL matching has been exact since 2020-08-11** ("Stricter rules for URL matching in OAuth 2"). No prefix
  or trailing-slash forgiveness (§4).
- **Rate limiting is concurrency-based, not a request quota**: 10 simultaneously processing requests **per user** —
  "per user, and not per API key or per client" — with a 120-second per-call timeout, and a separate cap of 500 pending
  batch webhook events per user. Both surface as 429 (§9).
- **The developer release-notes feed's newest entry on 2026-09-20 was dated 2025-08-19** (Transactional status page).
  Nothing about OAuth, scopes or token lifetime has been announced since. Check it again anyway.
- **Mailchimp is an Intuit product** and the OAuth hosts answer behind Intuit infrastructure; error bodies and headers
  carry Intuit trace ids. That is normal, not a sign you hit the wrong host.
- **One live quirk to know before you debug anything**: the metadata endpoint answers **HTTP 200 even when auth fails**.
  Verified 2026-09-20 with no token and with a junk token — both returned `200` with body
  `{"error":"invalid_token","error_description":"Unable to load login and user"}` and a `WWW-Authenticate: OAuth realm='Service', …`
  header. A client that only checks the status code will treat a failed discovery call as a success (§6, §10).

If the portal does not look like this, stop and report what you actually see rather than clicking on.

## 1. Decide: reuse the existing app, or register a new one

**A new app means a new client ID, and every existing customer authorization is bound to the old one.** Because
Mailchimp tokens never expire, a live Mailchimp connector can be sitting on years-old tokens that no one has had to
touch — and they all die with the old client ID. Re-registering "to get a clean form" is a customer-wide migration.

Reuse the existing app for: changing the redirect URI, rotating a compromised secret (§7), or diagnosing an install
failure. Its client ID lives in your platform's secret config or console — look it up there, not by guessing from the
portal list.

Register a **new** app only when the user explicitly asks: a replacement for a compromised app, a separate app for a
different product or brand, or the region case in §4 if that is the route taken. Say which path you are on before you
touch the portal.

## 2. Account: sign in or sign up

- **Sign in** at `https://login.mailchimp.com/`, or sign up at `https://login.mailchimp.com/signup/`.
- Every admin URL below is **data-centre prefixed** (`https://us19.admin.mailchimp.com/…`) and Mailchimp's own docs
  link the same page with three different prefixes (`us1`, `us19`, `us21`). It does not matter: all of them bounce
  through `login.mailchimp.com` and land you in *your* account's data centre. Use the prefix-less
  `https://admin.mailchimp.com/account/oauth2/` and let Mailchimp route you.
- **Owner or Admin.** Mailchimp's user-levels help page places API keys and integrations under the Owner and Admin
  levels; Manager, Author and Viewer are progressively more limited. A lower-level user may not be able to reach the
  Registered Apps page at all — and, separately, should not be the one authorizing production connections (§5).
- There is **no separate developer account, no developer portal and no sandbox tier**. App registration is a page
  inside an ordinary Mailchimp account, and a free account can register one. What the *API* can do varies by the
  account's plan ("What you can do with the API depends on what level of Mailchimp plan you have"), so a free account
  cannot fully rehearse a paid customer's experience.

Hand control back for anything only a human can do: CAPTCHA, email verification, 2FA, accepting terms. Do not retry a
blocked step in a loop.

**If this session has no browser automation** (the usual case for a CLI or cloud run), do not pretend to click. Give
the user an exact, ordered click path with the literal values to paste — the redirect URI from §4 — and continue once
they report back with the client ID and confirm the secret is in the secret store.

## 3. Register the app

**Registered Apps page → Register An App → fill out the form → Create.**

- Registered Apps: `https://admin.mailchimp.com/account/oauth2/`
- The form is short — app name, a description of what it does, your company/website, and the redirect URI. Treat the
  name and description as customer-facing copy: they are what a customer reads on the consent screen when deciding
  whether to hand over their whole Mailchimp account.
- There is no app type, no confidential/public toggle, no environment selector and no scope picker. Do not go looking
  for them.

**After you click Create, `client_id` and `client_secret` appear at the bottom of the page. This is the only time the
secret is visible.** Copy it straight into the secret store before navigating away (§7).

## 4. Redirect URI

Mailchimp's guide asks for "**The** Redirect URI for your application", singular, and its own sample apps instruct you
to "Set the Redirect URI" to one value. The form is behind a login, so **check what the field actually accepts before
promising a customer anything**: if it takes one URI only, a multi-region platform needs one registered app per
callback host, each with its own client ID and secret — a real architectural consequence, not a detail.

The callbacks this platform serves, one per data centre (confirm the current list with the platform owner rather than
assuming):

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

Rules that bite:

- **Matching is exact**, and has been since 2020-08-11. Mailchimp's release note: "We now only support exact matching
  on the redirect URI to adhere to the OAuth 2 spec." No trailing-slash tolerance, no subpath, no scheme fudging.
- **The same value must be sent on both legs.** `redirect_uri` goes on the authorize URL *and* in the token-exchange
  body; Mailchimp's own sample sends one constant to both. A mismatch fails the exchange, not the save.
- **HTTPS is recommended but not enforced** — "For security, we strongly recommend—but do not enforce—using HTTPS for
  your `redirect_uri`." Never leave a non-HTTPS URI on a production app.
- **For local testing use `127.0.0.1`, not `localhost`.** Mailchimp's own sample app is explicit: "You HAVE to use
  127.0.0.1 if you're running it locally, localhost won't work!" Remove it from a production app afterwards.
- If the user asks to add a region later, that is an edit to the existing app (§1) — or a new app, if the field holds
  only one value.

## 5. Scopes — there are none, and that is the whole problem

**Mailchimp's Marketing API OAuth 2 has no scopes.** The authorize URL Mailchimp documents is:

```
https://login.mailchimp.com/oauth2/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI
```

That is the complete documented parameter list. There is no `scope`, no `optional_scope`, no consent-screen checkbox
set, and nothing to declare on the app. Mailchimp also documents no `state` parameter — standard practice is to send
one anyway for CSRF protection, so **verify with your own client that `state` round-trips** rather than assuming.

Say the consequence out loud to whoever is approving this, because it is the least-privilege story:

> **A Mailchimp OAuth token is all-or-nothing.** It can read and write audiences, contacts, campaigns, reports, files,
> e-commerce data, automations and account settings — everything the API exposes — for the entire Mailchimp account.
> You cannot ask for read-only. You cannot ask for one audience. A customer who wants to grant less has no lever at
> the OAuth layer, and neither do you.

### The one lever that does exist: the authorizing user's role

What a token can do is bounded by **the Mailchimp user who authorized it**, and that binding is live, not frozen:

- "API authentication is tied to the user that created the API key or authorized the OAuth2 app. **If the user is
  removed from the account, that authentication token will be revoked.**"
- "API access is also limited by the user level (role) of the authorizing user. **The role is not fixed, and can change
  over time.**" Actions the role does not permit return **403**.
- The role on a token can be read back from the **API Root** endpoint (`GET /3.0/`).
- Mailchimp's own recommendation: "When creating an API key or authorizing an app, we recommend using an admin user
  when possible. **OAuth integrators may want to inform the user if the application won't work at their user level.**"

Practical guidance to give customers: authorize as an **Owner or Admin** — an account where the connector needs write
access will 403 its way through a Manager's token — and understand that a connection dies the day that person is
removed from the account. Where a customer wants least privilege, the honest answer is "authorize with a dedicated
Mailchimp user at the lowest level that still works, and expect 403s if it is too low," not "we'll request fewer
scopes."

> **As of 2026-09-20, this platform's Mailchimp connector** sends exactly `response_type`, `client_id`, `redirect_uri`
> and `state` on the authorize call — no `scope` (correct; there is none) and **no PKCE** (Mailchimp documents none).
> Its object coverage spans audiences/lists, contacts, campaigns and campaign reports, with **create and update on
> audiences, contacts and campaigns** and native audience webhooks — so customers must authorize with a user whose
> level permits writes. Confirm the current coverage with the connector's owner before telling a customer what the
> connection will and won't touch.

## 6. The data-centre prefix — the step people skip

There is no single API host. After the token exchange you must call the metadata endpoint, read the account's server
prefix, and **store it alongside the token**:

```
GET https://login.mailchimp.com/oauth2/metadata
Authorization: OAuth <access_token>
```

Mailchimp's guide documents `dc` (the server prefix, e.g. `us19`) and instructs you to "persist both the access token
and the server prefix". The root then becomes `https://<dc>.api.mailchimp.com/3.0/`. Fundamentals gives three ways to
find a data centre, and for OAuth only one of them applies — this endpoint. The other two (the URL of the API-keys
page; the `-us6` suffix on an API key) are for key-based auth.

Things that make this step go wrong:

- **It returns 200 on failure.** Verified live 2026-09-20: with no token, and with an invalid token, the endpoint
  returns **HTTP 200** and a JSON body `{"error":"invalid_token","error_description":"Unable to load login and user"}`,
  with the real signal in a `WWW-Authenticate: OAuth realm='Service', error='invalid_token', …` header. **Gate on the
  presence of the prefix in the body, not on the status code.** A client that trusts 200 will store an empty host and
  fail every subsequent call for reasons that look nothing like an auth problem.
- **`OAuth` vs `Bearer`.** Mailchimp's guide uses `Authorization: OAuth <token>` for this endpoint. Probing it on
  2026-09-20, a `Bearer` header was parsed as a valid scheme too (it produced `invalid_token`, not a malformed-request
  error), and Marketing API fundamentals documents `Bearer` for API calls. Prefer the documented `OAuth` prefix here
  and `Bearer` (or HTTP Basic with username `anystring`) on the API itself.
- **Never hardcode a host.** `us1`, `us19` and `us21` all appear in Mailchimp's own documentation links; none of them
  is "the" data centre. A bare `api.mailchimp.com` with no prefix is not a working Marketing API host for any account.
- **Re-check on reconnect.** Store the prefix per connection, refresh it whenever a customer re-authorizes, and treat a
  missing prefix as a hard failure of the connect flow rather than something to paper over with a default.

> **As of 2026-09-20, this platform's Mailchimp connector** performs exactly this discovery step immediately after the
> exchange, stores the per-account API host returned by the metadata call, and additionally reads the user's name and
> email out of the metadata response's login block to label the connection. For key-based connections it instead
> derives the host from the text after the last `-` in the key. Two things to confirm with the connector's owner: that
> the discovery call's **200-on-error** case is treated as a failure (see above), and that a connection whose host was
> never discovered is surfaced as broken rather than left pointing at the prefix-less default.

## 7. Capture the credentials, and rotation

From the app page immediately after **Create**:

- **`client_id`** and **`client_secret`** — "This is the only time you'll be able to see `client_secret`, so you'll
  need to copy it and store it securely."
- The endpoints, which are the same for every app: authorize `https://login.mailchimp.com/oauth2/authorize`, token
  `https://login.mailchimp.com/oauth2/token`, metadata `https://login.mailchimp.com/oauth2/metadata`.
- Note that there is no sandbox/production split — the credentials you just made are production credentials.

The exchange, as Mailchimp documents it, is a **form-encoded POST with the credentials in the body** — not HTTP Basic:

```
POST https://login.mailchimp.com/oauth2/token
grant_type=authorization_code&client_id=…&client_secret=…&redirect_uri=…&code=…
```

**Rotation** (Registered Apps → **Edit** on the app → Client secret → **Rotate** → type `ROTATE` → Rotate Client
Secret) shows `client_id` and the new `client_secret` once, in a modal. Rotation breaks every deployment still holding
the old secret, so never rotate without explicit go-ahead and a cutover plan. Note the asymmetry that makes rotation
survivable here: because Mailchimp tokens never expire and are never refreshed (§8), already-issued customer tokens
keep working — it is *new authorizations* that break until the new secret is deployed.

Report the secret once so the user can paste it into their secret store, say plainly that it is now in the transcript
and can be rotated, then move on.

> **As of 2026-09-20, this platform's Mailchimp connector** exchanges the code exactly as documented — form-encoded
> POST carrying `client_id`, `client_secret`, `code`, `redirect_uri` and `grant_type` in the body — and then sends the
> resulting token as a bearer token on Marketing API calls. It also supports key-based connections, authenticating
> those with HTTP Basic using the literal username `anystring`, which is what Mailchimp's docs specify.

## 8. Token behaviour — short section, load-bearing

- **Access tokens do not expire.** Mailchimp: "Mailchimp Marketing access tokens do not expire, so you don't need to
  use a `refresh_token`. The access token will remain valid unless the user revokes your application's permission to
  access their account."
- **There is no refresh token and no refresh flow.** Do not build one, and do not treat a 401 as "refresh and retry" —
  there is nothing to refresh. A 401 means the token is dead and the customer must re-authorize.
- **Revocation happens three ways, all silent from your side**: the customer disconnects the integration in their
  Mailchimp account (**Integrations → Manage**); the authorizing user is removed from the account (fundamentals: that
  token "will be revoked"); or the account is deactivated (403 *User Disabled*).
- **Non-expiring tokens are a storage problem, not a convenience.** They never rotate, so a leaked token stays valuable
  indefinitely. Mailchimp: "You are responsible for the security of API tokens… Because of the potential security risks
  associated with exposing an API token, Mailchimp does not support client-side implementation of our API using CORS
  requests." Encrypt at rest, and delete tokens on uninstall — Mailchimp's integration guidance requires it: "If a user
  deletes or uninstalls an integration, it's important that the integration also deletes any relevant data like OAuth
  tokens and other syncing configurations."
- Mailchimp exposes **Authorized Apps** endpoints (`GET /3.0/authorized-apps`, `GET /3.0/authorized-apps/{app_id}`) to
  list an account's registered, connected applications — useful when a customer swears they connected and you see
  nothing.

## 9. Limits, review, and listing

**Rate limits are concurrency-based.** The Marketing API allows **10 simultaneously processing requests**, and the
limit is **per user, not per API key or per client** — so your connector shares that budget with everything else the
customer has connected under that user, including their own scripts. Exceeding it returns 429
(`TooManyRequests: You have exceeded the limit of 10 simultaneous connections`). Also:

- Slow calls hold a slot: "The length of time it takes a request to run will affect how many requests you can make."
  Requests that time out for you may still be running server-side, still holding a slot.
- **120-second stream timeout** per call; a 502 with an HTML body usually means the CDN closed a timed-out request.
- At very high volume you may get a **429 or 403 with no JSON body** — handle the bodiless case.
- Separate limit: **500 pending batch webhook events per user**, returned as a 429 when starting a new batch operation.
- "Currently there are no options to raise the limit on a per-customer basis." Cache, paginate, use partial responses,
  and push long-running work to the Batch endpoint.

**Listing is optional.** A registered app works through its OAuth flow without any review, listing or approval. What
review buys is placement in the **Mailchimp Marketplace**, via the **Integration Partner Program** — and the bar is
usage, not paperwork:

| Requirement | Detail |
| --- | --- |
| Current API version | Built on the current version of the Marketing API (3.0) |
| OAuth 2 | Required — "it's a requirement to join the Integration Partner Program and have your integration listed" |
| **25+ active users in the last 90 days** | "An active user is a unique OAuth sending API calls" — a chicken-and-egg bar you must clear *before* listing |
| **Three+ core features** | From Mailchimp's list: tags / custom events / merge fields, audience segments, automations, connected sites, email templates, landing pages, signup forms, Transactional sending, full e-commerce sync, contacts with correct subscription statuses respecting GDPR fields, conversations, Content Studio images, reports |
| Test account | "Provide a test account with full access and password reset ability using the email address `integrationtest@mailchimp.com`" |
| End-user support | Mailchimp routes user inquiries about your integration to your support channel |
| Terms | Agree to partnership terms and conditions |

Mailchimp "will review and test your integration to verify it meets the requirements"; the program page does not
publish a turnaround, and applications go through an external application portal. **Stop and ask** before answering
anything you would have to invent — user counts, support commitments, compliance or legal attestations, or which
feature list to claim. A plausible guess is worse than a blank, and expensive to walk back after submission.

**Transactional is a different product.** Mailchimp Transactional (formerly Mandrill) lives at
`https://mandrillapp.com/api/1.0/`, authenticates with its **own API key passed in the JSON body of every POST**, and
Mailchimp documents no OAuth flow for it. A Marketing API OAuth token is not a Transactional credential. It is a paid
add-on requiring a Standard or Premium Mailchimp account. If the request turns out to be about sending transactional
email, this run does not produce the right credentials — say so and stop (see **Stop and ask**).

## 10. Verify end-to-end

Testing inside the account that owns the app proves almost nothing — that user is the Owner. Test the customer's path:

1. Authorize from a **second, unrelated Mailchimp account** through your platform's real connect flow. A free account
   works for the flow itself.
2. Confirm the callback landed on the registered redirect URI **character for character**, and that `state` came back.
3. Confirm the exchange returned an access token, and that **no** refresh token was expected or required (§8).
4. Confirm the metadata call returned a **server prefix** and that your client stored it — and prove the failure path
   too, by pointing the same call at a junk token and checking your client treats that 200 as an error (§6).
5. Call `GET https://<dc>.api.mailchimp.com/3.0/ping` — the cheapest proof the token and host agree — then
   `GET /3.0/` (API Root) to read back the **account name and the authorizing user's role**, and record the role.
6. If the connector writes, exercise one write with that role. A read-only role fails at write time, not at connect
   time, which is the worst possible moment to find out.
7. Disconnect from the customer side (Mailchimp account → **Integrations → Manage**) and confirm your platform notices
   and stops.

| Symptom | Cause |
| --- | --- |
| Authorize URL shows a Mailchimp **404 "Page Not Found"** page | Unknown or wrong `client_id`, or the app lives in a different account (verified live 2026-09-20) |
| Token exchange returns **400 `{"error":"invalid_client"}`** | Wrong `client_id`/`client_secret` pair, or credentials missing from the form body (verified live 2026-09-20) |
| Token exchange fails after a working authorize | `redirect_uri` on the exchange not byte-identical to the one on the authorize call (§4) |
| Redirect "worked yesterday", fails now | Exact matching since 2020-08-11 — a trailing slash or added path breaks it (§4) |
| Local callback never fires | `localhost` instead of `127.0.0.1` (§4) |
| Metadata call "succeeds" but the host is empty | 200-on-error: body was `{"error":"invalid_token",…}` (§6) |
| Every API call 404s, or hits a host that resolves to nothing | Data-centre prefix missing or hardcoded — no account lives at a bare `api.mailchimp.com` (§6) |
| 401 *API Key Invalid* | Token revoked, or the customer disconnected the integration. No refresh exists — re-authorize (§8) |
| 403 *Forbidden* on some endpoints only | Authorizing user's level does not permit that action, or their level changed since authorizing (§5) |
| 403 *User Disabled* | The Mailchimp account is deactivated (§8) |
| 403 *Authorization Failure: User does not have access to the requested operation* | The customer's **pricing plan** does not include that feature — not a permissions bug you can fix |
| Sudden total failure for one customer | The authorizing user was removed from their Mailchimp account; that token is revoked (§5) |
| 429 despite modest traffic | 10 simultaneous connections **per user**, shared with everything else that user connected (§9) |
| 429 or 403 with no JSON body | Very high volume — handle the bodiless case (§9) |
| 502 with an HTML body | Request timed out and was closed by the CDN; use pagination, partial responses, or Batch (§9) |
| 426 | Request made over HTTP, or below TLS 1.2 |
| Customer expects read-only access | Not possible — Mailchimp has no scopes; the only lever is the authorizing user's role (§5) |

To rehearse error handling without breaking anything, Mailchimp supports an **`X-Trigger-Error` header** on Marketing
API requests: sending `APIKeyMissing`, for example, triggers a 401.

## 11. Hand off — never commit the secret

- **Do not** write the client secret, an access token or an API key into source control, a test, a fixture, a committed
  `.env`, a ticket, a PR body, or a chat channel. Values go to the user, for the secret store or console. Mailchimp's
  own sample code says the same thing next to its placeholder constants.
- Remember that Mailchimp tokens **never expire** — a leaked one is valuable forever and there is no rotation to save
  you. If a token is exposed, the customer must disconnect the integration to kill it.
- If a code change is needed (a callback host, the metadata-discovery guard, the per-account host), keep it secret-free
  and say plainly what the human must set out of band.
- Close with: the app name and the Mailchimp account that owns it; the client ID; where the secret was delivered and
  that it cannot be viewed again; the exact redirect URI(s) registered and whether one app covers every region; the
  authorize / token / metadata endpoints; **that Mailchimp has no scopes and the token is account-wide**; the fact that
  tokens do not expire and there is no refresh; the role the test account authorized with; Marketplace/Partner Program
  status if relevant; and anything left for the user to do.

## Stop and ask

Hand back to a human rather than guessing when: the request is really about **Transactional / Mandrill** (different
product, different auth, no OAuth — §9); the account is gated behind verification you cannot complete (§2); the
Registered Apps form turns out to accept **only one redirect URI** and the platform needs four, because that decides
how many apps and client IDs exist (§4); someone asks for **read-only or per-audience access**, which Mailchimp cannot
grant (§5); rotating a live app's secret is on the table (§7); a customer's connection depends on a specific Mailchimp
user staying in their account (§5); the Partner Program application asks for user counts, support commitments,
compliance or legal claims (§9); or the portal does not match the **Platform state** section above.

When the portal behaves in a way the docs did not describe, say what you found rather than picking the option that
lets you keep going.

## References

- Access Data on Behalf of Other Users with OAuth 2 (registration, full flow, secret rotation) — https://mailchimp.com/developer/marketing/guides/access-user-data-oauth-2/
- Marketing API Fundamentals (data centres, auth, user roles, API limits) — https://mailchimp.com/developer/marketing/docs/fundamentals/
- Errors and error glossary (401 / 403 / 429 / 426, `X-Trigger-Error`) — https://mailchimp.com/developer/marketing/docs/errors/
- Integrations documentation (building, requirements, partner program) — https://mailchimp.com/developer/marketing/docs/integrations/
- Integration Partner Program — https://mailchimp.com/developer/integration-partner-program/
- Release notes — https://mailchimp.com/developer/release-notes/
- Stricter rules for URL matching in OAuth 2 (2020-08-11) — https://mailchimp.com/developer/release-notes/stricter-rules-for-url-matching-oauth-2/
- API Root endpoint (read back account name and role) — https://mailchimp.com/developer/marketing/api/root/
- Ping endpoint — https://mailchimp.com/developer/marketing/api/ping/
- Authorized Apps endpoints — https://mailchimp.com/developer/marketing/api/authorized-apps/
- Methods and parameters (pagination, partial responses) — https://mailchimp.com/developer/marketing/docs/methods-parameters/
- Marketing API Quick Start — https://mailchimp.com/developer/marketing/guides/quick-start/
- Synchronize Audience Data with Webhooks — https://mailchimp.com/developer/marketing/guides/sync-audience-data-webhooks/
- Mailchimp Transactional fundamentals (separate product and auth) — https://mailchimp.com/developer/transactional/docs/fundamentals/
- Help: manage user levels in your account — https://mailchimp.com/help/manage-user-levels-in-your-account/
- Help: about API keys — https://mailchimp.com/help/about-api-keys/
- Help: about integrations (how customers connect and disconnect) — https://mailchimp.com/help/about-integrations/
- Registered Apps page — https://admin.mailchimp.com/account/oauth2/
- Mailchimp Marketplace — https://mailchimp.com/marketplace/
- Integrations directory — https://mailchimp.com/integrations/
- API status — https://status.mailchimp.com/