Brevo Scope Updates Replace the Whole Grant Set

Affiliation: Marketing Wiki's commissioning editor maintains Migma. Keep the approved Migma email separate from a custom Brevo app's permission change. Before updating that app, compare the entire current and desired grant sets: an apparently additive change can remove permissions when the management operation replaces the whole set.

Marketing Wiki Research Automation published this guide directly without independent review. Sources were checked on October 7, 2026. The permission sets below are synthetic, and no app, token, contact or campaign was changed.

The export and the grant have different owners#

Migma's export guide documents handing a reusable template to Brevo, with final review and sending completed in Brevo. Retain the reviewed creative and inspect the destination template. Exporting the email does not send it or approve a separate integration's access.

Brevo's October 6 changelog announces its machine-to-machine authentication guide. The M2M documentation says app scope updates are a full replacement, not a delta. The worksheet here governs a custom Brevo app beside the email handoff; it describes no undocumented change to Migma's connector.

Identify the exact app and Brevo account before reviewing permissions. The M2M guide documents one account per credential. A plausible app name is not evidence that its permissions belong to the intended destination account.

Write the complete desired set#

Suppose a fictional operations worker previously reads contacts, reads CRM records and modifies CRM records. Its new approved job reads both areas and updates a contact field, while CRM writing is being retired.

The original change worksheet is:

Current app grants:
  contacts:read, crm:read, crm:write

Desired app grants:
  contacts:read, contacts:write, crm:read

Added = desired minus current:
  contacts:write
Removed = current minus desired:
  crm:write
Retained = current intersect desired:
  contacts:read, crm:read

Review all three results. The new contact-write permission needs a justified purpose and an authorized owner. The removed CRM-write permission needs confirmation that no still-required caller depends on it. The retained permissions need to be carried into the replacement, not assumed to survive automatically.

For this example, submitting only contacts:write to a full-replacement update would leave only that grant. It would not mean “add contact writing to everything already configured.” Obtain the verified current configuration before constructing the desired set; if the installed management surface cannot establish it, hold the change instead of reconstructing it from memory.

Preserve exact catalog names. Sort and deduplicate the worksheet for review, but do not silently rename or change the case of permission identifiers. Keep the approved desired set with the change record so the operator can compare the actual result.

Write access does not supply read access#

Brevo's scope catalog explicitly says :write does not imply :read. It lists contacts:read separately from contacts:write and likewise separates the CRM permissions.

That matters when the worker lists a resource before modifying it. The proposed desired set retains contacts:read as well as adding contacts:write. Do not remove read access merely because the name of the new write permission sounds broader.

The catalog describes scope names and capabilities; it does not establish this fictional worker's actual dependency inventory. Check the real caller's approved operations through the current provider reference. Do not grant every possible future permission to avoid maintaining the set later.

The next token is another permission decision#

Configured app grants and permissions requested for a particular token are different sets. The M2M guide warns that omitting scope currently returns every permission configured on the app. An app grant expansion can therefore matter to callers that keep using that omitted-scope behavior.

Request the explicit permissions needed for the specific operation. A read-only investigation should not inherit contact writing simply because the app is allowed to request it. Inspect the issued token's granted permissions through the provider's supported methods, without putting tokens into public decoding tools or review documents.

Do not transfer the user-OAuth catalog's missing-scope error behavior to M2M. Follow the explicit warning for the grant you actually use. Also do not treat an app scope update as proof that an already issued token was revoked: the cited sources do not explain scope-change effects on existing tokens.

Close the change with observed configuration#

Have the authorized operator apply the complete reviewed set through the supported management command, then verify the resulting app configuration and a newly issued token's intended permissions. Exercise an authorized, non-sending read path first. Test any necessary write behavior only under a separately approved fixture and data boundary.

Keep the Migma creative approval and Brevo campaign review intact through that access change. A permission update cannot certify the email's content, audience or sender.

The separate credential-expiry guide covers renewing authentication without restarting an uncertain handoff. Begin this worksheet with current, desired, added, removed and retained sets; pause on any unexplained permission before changing the app.