{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/brevo-email-token-expiry-handoff","id":"brevo-email-token-expiry-handoff","slug":"brevo-email-token-expiry-handoff","title":"Renew the Brevo Credential Without Restarting the Email Handoff","description":"Separate Brevo M2M token expiry from the approved Migma creative and remote job. Renew a credential without blindly recreating a template or resending a campaign.","dek":"Three-clock timeline and renewal decision record for a fictional training newsletter.","category":"Email Operations","topics":["Migma","email marketing","Integrations"],"publishedAt":"2026-10-07","updatedAt":"2026-10-07","lastVerifiedAt":"2026-10-07","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma sending and export options","url":"https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff"},{"title":"Brevo M2M authentication","url":"https://developers.brevo.com/docs/oauth-m2m-authentication?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff"},{"title":"Brevo changelog","url":"https://developers.brevo.com/changelog?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff"}],"wordCount":766,"body":"Affiliation: Marketing Wiki's commissioning editor maintains Migma. Keep the reviewed Migma email as one identifiable creative artifact while a separate integration manages its Brevo credentials. An expiring access token is a reason to renew authentication, not to recreate the email or repeat an uncertain send.\n\nMarketing Wiki Research Automation published this guide directly without independent review. Sources were checked on October 7, 2026. The timeline and renewal procedure are proposed operating methods; no token exchange or provider operation was tested.\n\n## Establish the actual handoff owner\n\n[Migma's export guide](https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff) documents exporting a reusable template to Brevo, with final review and sending completed there. Exporting does not send the email. Focus the intended Migma email, preserve its reviewed version, and inspect the destination template before delivery.\n\nBrevo's [October 6 changelog](https://developers.brevo.com/changelog?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff) announces its machine-to-machine authentication guidance. The [current M2M guide](https://developers.brevo.com/docs/oauth-m2m-authentication?utm_source=marketingwiki&utm_medium=referral&utm_campaign=brevo-email-token-expiry-handoff) describes a private server-to-server client_credentials flow that acts as the server itself, with one account per credential. It is different from an application acting on behalf of an end user.\n\nThis article addresses a custom integration around that handoff. The sources do not establish that Migma's existing Brevo connector uses M2M internally. Do not migrate a working connector's authentication based on an assumption about its implementation.\n\n## Draw three clocks before troubleshooting\n\nThe creative approval, credential validity and remote job each have their own lifecycle. A fictional training newsletter illustrates the distinction:\n\n| Time | Creative state | Credential state | Handoff state |\n| --- | --- | --- | --- |\n| 09:00 | Approved Migma version retained | Token issued | No destination operation yet |\n| 09:40 | Same approved version | Remaining lifetime recorded | Template operation submitted |\n| 10:05 | Same approved version | Token expired under the example assumptions | Destination outcome still being investigated |\n\nThese times are synthetic. Brevo documents a roughly one-hour token lifetime and shows an expires_in response field. Use the actual response and a reliable clock for a real integration. Do not calculate validity from when an operator happened to open the campaign page.\n\nThe expired token can explain why a later readback needs renewed authentication. It does not establish whether the earlier operation succeeded. Conversely, a valid token does not prove that the correct Migma version reached the intended Brevo account.\n\n## Renew the credential, retain the operation\n\nBrevo documents no refresh token for this grant. Request another access token with client_credentials when needed. Request an explicit scope: the guide warns that omitting it currently grants every permission configured on the app rather than failing closed.\n\nKeep credential renewal inside the integration's secure authentication layer. Store secrets using the team's approved secret-management controls; do not put tokens into campaign briefs, screenshots or comment threads. Retain the account identity, submitted artifact reference and supported destination operation identifier outside the token's lifetime.\n\nBefore attempting another write, answer these questions in order:\n\n1. Was the earlier request submitted, or did authentication fail before submission?\n2. Is there a supported destination identifier or response to recover?\n3. Can an authenticated read establish what already exists?\n4. Does the documented operation support a safe retry, and under what conditions?\n\nIf submission is unresolved, renew authentication and investigate the same operation. Do not create a replacement template simply to get a response that looks clearer. Where a provider cannot resolve the outcome, escalate it as unknown rather than treating expiry as evidence of failure.\n\n## Define a renewal record the operator can inspect\n\nUse this original record without including any secret value:\n\n```text\nCreative: reviewed Migma email and version\nDestination: named Brevo account and intended template\nCredential: app reference, issued time and response lifetime\nRequested permissions: explicit scope for the next operation\nExisting operation: submitted reference or unresolved submission\nRenewal purpose: readback or specifically authorized continuation\nResult: artifact recovered, safe retry established or escalation needed\n```\n\nChoose a renewal margin based on measured request duration and the actual integration's behavior. This guide proposes no universal number of seconds and makes no promise that a token accepted at request start remains acceptable throughout every long operation.\n\n## Return to the email review after access is restored\n\nOpen the recovered template in Brevo. Compare its content, variables and links with the accepted Migma version, then separately review audience, sender, subject and timing. Restored authentication supplies access; it does not approve those campaign settings.\n\nThe separate [retry contract](/articles/email-api-retry-idempotency-contract) covers repeated-write semantics. Begin here by retaining one destination operation across a credential renewal in an authorized non-sending rehearsal. The desired evidence is the same approved artifact recovered under new authentication, without an unexplained duplicate."}