Brevo API key expiration is a bigger concern than it first appears for developers running low-traffic websites. A contact form, password-reset flow, or occasional signup confirmation can work flawlessly for months—then silently fail precisely because nobody needed to send an email.

A Reddit user recently highlighted that mismatch: they had chosen Brevo’s “no expiration” setting for small client sites and personal projects, only to find that unused credentials were still disabled after 90 days. The complaint is understandable, but the most useful lesson is broader: transactional email credentials are production dependencies, whether an app sends 10,000 messages a day or one message a quarter. [1]

What changed with Brevo API key expiration?

Brevo now documents two separate credential lifecycles. First, an API key can have a fixed expiry date chosen when it is created. Second, and independently, an API key is deactivated when it has not made a successful API call for 90 days. That inactivity rule also applies when the key is configured with no fixed expiration date. Brevo says it sends reminders seven days before deactivation and on the day it happens. [2][3]

Brevo publicly announced the addition of custom expiry dates for API and SMTP keys on May 12, 2026. Its release note says a key with no fixed expiry will still expire after 90 days of inactivity. That wording makes the important distinction clear: “no expiration” means no scheduled calendar-date expiry, not permanent validity regardless of use. [4]

For teams that send regularly, the rule may be nearly invisible. A busy ecommerce app, SaaS product, or marketing workflow naturally makes successful API calls well within every 90-day window. The operational problem appears at the other end of the spectrum: brochure sites, seasonal businesses, agencies managing many small properties, internal tools, demos, and hobby products.

The original concern is about reliability, not just convenience

The source Reddit post does not argue that keys should never be managed or rotated. It describes a practical deployment model: set up a website once, configure a transactional mail provider, and expect a rarely used form or signup email to remain available. For that model, an inactivity timeout creates a failure mode that is difficult to detect through normal traffic monitoring.

A web application can be healthy in every other respect. The homepage loads. The database works. Forms accept submissions. Yet the final mail API request is rejected because a secret was deactivated. The person discovering the issue is often a customer who never gets a confirmation message—or a client who sees their first lead vanish.

Fixed expiration and inactivity deactivation are not the same thing

Confusion around Brevo API key expiration is understandable because the user interface exposes an expiry setting, while the inactivity policy is a separate control. These concepts solve different problems.

A fixed expiry is predictable. A developer might deliberately create a key that expires in 30 days for a contractor, a temporary migration, or a staging environment. The date is known in advance, can be recorded in documentation, and can be included in a rotation plan.

An inactivity deactivation is conditional. It depends on whether a specific credential completes a successful request. A key used for a quiet contact form can therefore remain technically correct in environment variables, pass code review, and still be disabled later because the expected business event never occurred.

Brevo’s documentation confirms that the remedy is either to make a successful API call before the 90-day period ends or reactivate a key that is already deactivated. It also recommends naming each key by integration and using restricted permissions rather than full account access where possible. [2][3]

Why this distinction matters in incident response

A timed credential expiration generally creates a planned maintenance event. An inactivity control creates a latent incident: there may be no error until the first real customer action after a long quiet period. The difference matters because organizations monitor planned rotations and deployed versions differently from event-driven code paths.

Consider three examples:

A local accountant’s website: The contact form may receive no leads during a slow 90-day stretch, then fail just before tax season.
A SaaS trial product: New signups might be sporadic, so the first user after a quiet period never receives verification or welcome email.
An agency portfolio: Each client has a separate sending account and credential. Checking every site manually is not scalable, especially when there are dozens of accounts.

In each case, the credential is not actually unused from a business perspective. It is provisioned for an on-demand function. That difference between “not called lately” and “not needed anymore” is the core operational tension.

Why low-volume transactional email is uniquely vulnerable

Marketing email is scheduled; transactional email is triggered. That simple distinction changes how credential controls behave in production.

Campaign platforms often have regular list syncs, scheduled sends, segmentation calls, or reporting requests. Those activities may keep an API key active even when message volume drops. A minimalist transactional implementation may do none of that. It might make exactly one request only when someone submits a form, asks for a magic link, receives an invoice, or requests an account deletion.

For a developer, this means low email volume is not equivalent to low importance. A password-reset email can be the most consequential email an application sends even if it is sent only a few times per year. A single missed quote-request email can be more expensive to a small business than a monthly email-platform bill.

The quiet-path monitoring gap

Many teams monitor uptime with synthetic HTTP checks that request public pages. Others monitor application errors through logs or observability tools. Neither practice necessarily validates the ability to send email.

Email delivery has multiple failure domains:

The application must accept the user event.
The app must retrieve the expected secret from its environment or secret manager.
The credential must authenticate successfully with the provider.
The sending domain must be verified and aligned.
The provider must accept the message.
The message must traverse recipient-side filtering and reach an inbox or generate a measurable event.

A 90-day API-key deactivation occurs at step three. A homepage uptime check cannot find it. A provider dashboard warning might, but only if the correct account owner receives it, recognizes which client integration it affects, and acts before the deadline.

This is why “we will notice the warning email” is not a complete reliability strategy. Email notices are useful alerts, but they should back up an inventory and test process rather than substitute for one.

Why providers use inactivity controls in the first place

The policy is inconvenient for dormant integrations, but it has a legitimate security rationale. Long-lived static API keys are high-value secrets. If a key is committed to a repository, copied into an old deployment, exposed in a browser bundle, or retained by a former contractor, its owner may not know it is compromised for months or years.

Inactivity deactivation reduces the window in which an abandoned secret can be abused. It can also prompt account owners to reconsider whether an old integration still needs broad access. Brevo’s key-management documentation supports restricted access controls, allowing a key to be limited to the specific resources and permissions an integration needs. [3]

OWASP similarly recommends centralizing secret storage, provisioning, auditing, rotation, and lifecycle management. Its guidance emphasizes that unmanaged credentials scattered across code and configuration files make it harder to contain exposure and understand who is using what. [5]

Security and availability are both real requirements

The mistake is treating security and reliability as opposing choices. A permanent, full-account API key hard-coded into a shared codebase is not a good answer. But neither is a production design where a critical transactional workflow can disappear after a long lull with no external monitoring.

The better objective is controlled continuity:

A credential has only the permissions its workload needs.
The secret is stored outside source control.
The integration is tested at a known interval.
Failures create actionable alerts.
Rotation or replacement does not cause downtime.
Ownership survives staff, client, and vendor changes.

A provider’s inactivity policy may be one way to reduce stale-secret risk. Your application architecture still has to make the resulting lifecycle observable and recoverable.

How to keep a Brevo key active without creating bad email data

Brevo says a successful API call resets the inactivity issue for an API key. Importantly, its documentation refers to a successful API call—not specifically a sent email. That gives developers a cleaner option than periodically generating fake transactional messages. [2]

Prefer a harmless authenticated API health check

For an API-based integration, schedule a small authenticated request that verifies the actual credential your production app uses. A read-only account or configuration endpoint is usually conceptually preferable to creating contacts, updating records, or sending a message solely to prove a key is alive.

The health-check job should run from the same production environment, or at least with the same secret and intended network controls, as the deployed application. A check performed from a developer laptop with a copied key proves very little about the live website.

A reasonable cadence is monthly or every 30 to 60 days. That leaves time to investigate failures well before the 90-day threshold. Do not run the check exactly on day 89; a failed scheduled job, provider outage, deployment issue, or time-zone misunderstanding could eliminate your recovery window.

A minimal health check should:

retrieve the production credential from the normal secret store;
make a read-only authenticated request that requires the intended permission scope;
record success, failure, response status, and key identifier—not the secret itself;
alert a monitored operations channel after one or two failures; and
be reviewed as part of routine client or service ownership checks.

If you need implementation examples and integration patterns, start with the provider-neutral email API reference and setup guides, then adapt the check to the narrowest available permission set.

Do not use fake customer email as a keepalive

A common workaround is to send a test message every few months. It can work mechanically, but it is usually inferior to a harmless API call.

Test emails can pollute delivery analytics, create confusing audit trails, affect internal inbox rules, consume plan quota, and accidentally reach a real recipient if configuration changes. Sending to a sink mailbox is safer than sending to a customer, but it still tests a different path from a simple credential-health check and may complicate reporting.

If you must test the complete sending pipeline, do it deliberately. Use a dedicated controlled recipient, clear subject tags such as [synthetic email check], a separate message stream or category where available, and monitoring that distinguishes the synthetic message from customer traffic. That is a delivery test—not merely a key keepalive.

Remember SMTP is a separate path

Changing from the API to SMTP is not automatically an escape from the policy. Brevo’s SMTP-key documentation says that choosing “no expiration” means only that the key has no fixed expiry date and points to the separate inactivity policy. It also advises keeping active SMTP keys in use by sending at least one email every 90 days. [6]

That difference is significant. An API health check can be read-only. SMTP naturally validates through sending. Before switching protocols, confirm the current provider rules for the specific credential type and ask whether the replacement has merely shifted the same operational obligation.

Build a transactional-email reliability layer

A scheduled keepalive is useful, but it should be one part of a more durable design. The right architecture treats email as an external dependency with its own state, retries, logging, and alerting.

Separate user experience from provider submission

For a contact form, do not make the user’s browser wait for a third-party mail provider before showing a success page. First validate the request, apply rate limiting and bot defenses, persist the lead or inquiry, and enqueue an email task. Then process that task server-side.

This pattern makes provider errors visible without losing the underlying customer request. If the email credential is inactive, the queue can retry after remediation, notify an administrator, or route the request to another channel. A one-step browser-to-provider integration has fewer moving parts but gives you fewer recovery options.

For authentication messages and password resets, the standard is higher. Queueing can still help, but messages need short delivery windows and clear failure handling. Track provider acceptance, bounces, complaints, and delivery webhooks where available. If an account-verification email cannot be sent, the application should surface a controlled support or retry path rather than leaving the user in an ambiguous state.

Use a useful email-event model

At minimum, record these fields for every transactional request:

internal event ID and message type;
intended recipient address or a privacy-safe reference to it;
provider and sending domain;
API request result and provider message ID;
retry count and final outcome;
timestamp of provider acceptance; and
bounce, complaint, suppression, or delivery-webhook status when available.

This data changes an unexplained support ticket—“I never got the email”—into a diagnosable event. You can determine whether the app failed before creating the request, the key was rejected, the provider accepted the message, or the address was suppressed.

It also helps distinguish an API-key incident from a deliverability incident. A key deactivation creates an authentication or authorization failure. A message that is accepted but lands in spam is a sender-authentication, reputation, content, recipient, or mailbox-provider issue. The remediation is different.

Scope credentials per application and environment

One account-wide key reused across five clients, production and staging environments, and several unrelated forms may seem easy to administer. In practice, it creates a large blast radius and unclear ownership.

Use a distinct key for each meaningful workload: for example, client-a-prod-contact-form, client-a-prod-auth, and client-a-staging. Give each only the permissions it needs. A contact-form sender should not require list deletion, campaign administration, payment access, or broad contact exports.

This approach has an operational advantage beyond security. When a key nears inactivity or fails, the credential name tells you what will break and who owns the decision. It also allows an agency to rotate or revoke one customer integration without risking another.

Evaluating alternatives to Brevo for dormant integrations

Leaving a provider may be appropriate, but a migration should be based on an explicit requirements matrix rather than a reaction to one setting. The Reddit author’s priorities—multiple accounts, low-volume affordability, and simple transactional sending—are reasonable, but they are not identical to every team’s needs.

Start by writing down the non-negotiables:

Credential lifecycle: Do keys automatically expire or deactivate after inactivity? Is the policy documented?
Scope: Can keys be restricted by domain, action, environment, or account?
Account model: Can an agency isolate clients with subaccounts, organizations, servers, or separate billing?
Low-volume economics: Is there a permanent free tier, a paid minimum, or a trial that ends?
Observability: Are logs, webhooks, credential last-used data, and alerting available?
Sending model: Does the service support the API, SMTP, templates, inbound handling, suppression behavior, and regions you need?
Exit cost: Can you export templates, domains, suppression lists, and event data when changing providers?

A documented example: Resend

Resend’s documentation currently states that its API keys do not expire automatically and remain valid until manually deleted. It flags keys unused for 30 or more days for review and recommends routine rotation, but its stated behavior is not the same as automatic inactivity deactivation. It also supports keys with full access or restricted sending access, including domain restrictions. [7]

That may better fit a low-traffic contact form whose main requirement is that a deployed credential remains usable until the owner intentionally changes it. It does not eliminate the need for secret storage, monitoring, or rotation—if anything, the lack of forced inactivity deactivation makes your own secret inventory more important.

For a feature-by-feature assessment of sending workflows, account isolation, and operational trade-offs, see the Brevo vs Resend comparison. Do not migrate simply because a provider says “keys never expire”; validate how its domains, suppression rules, quotas, support, and billing model fit the client portfolio you actually operate.

A documented example: Postmark

Postmark is another option for transactional-first workloads. Its developer documentation supports server-level and account-level API tokens, and its pricing FAQ says its Developer plan includes 100 emails per month with no trial expiration date. [8][9]

That pricing structure may suit truly small sites, but a permanent free developer plan is not automatically an agency multi-account solution. Check whether each client needs separate ownership, whether a single account can cleanly isolate billing and access, and how messages are organized across servers and streams. Treat pricing, credentials, account topology, and support boundaries as a combined decision.

The key question is not “Which provider is best?”

A provider can be excellent for high-volume marketing and awkward for a dormant transactional integration. Another can be excellent for a developer-centric API and unsuitable for a client that needs extensive campaign automation. The right alternative depends on your failure mode.

If the unacceptable event is “an occasional contact form stops sending without a request,” put credential persistence and health monitoring at the top of the scorecard. If the unacceptable event is “one compromised agency key exposes every customer,” prioritize account isolation, permission scopes, IP controls, and auditable rotation. Often, both requirements point to separate credentials and better operations—not necessarily the same vendor.

Migrating without breaking live forms and auth flows

A transactional-email migration is not a one-line change from one endpoint to another. It affects sending domains, DNS records, templates, secrets, bounce handling, logs, and sometimes product behavior.

Use a parallel, reversible cutover

A safer sequence looks like this:

Inventory every message type, sending domain, environment, template, webhook, and current credential.
Verify the sending domain with the new provider and publish the required SPF, DKIM, and DMARC-alignment records before changing application traffic.
Create narrowly scoped production credentials and store them in your normal secret-management system.
Send controlled tests for every message type, including HTML rendering, plain text, reply-to behavior, links, and attachments where relevant.
Update one environment or a small percentage of non-critical traffic first.
Confirm provider acceptance, webhook events, mailbox placement where practical, and application logging.
Keep the old integration available briefly for rollback, but do not dual-send customer messages unless the workflow is explicitly designed to prevent duplicates.
Revoke old keys only after verifying the replacement is deployed everywhere.

The last point matters. Resend’s rotation guidance makes the same general recommendation: deploy and verify the replacement key before deleting the old one, because overlapping validity supports a no-downtime transition. [7]

Preserve suppression intelligence

A migration that ignores bounces and complaints can damage deliverability. If your old provider has a suppression list, export and review it where lawful and appropriate before importing it into a new system. Continuing to send to known hard-bounce or complaint-prone recipients wastes volume and can harm sender reputation.

For contact forms, validate the recipient addresses your application controls—for example, the business inbox receiving the form—and make sure reply paths are monitored. For user-facing transactional email, use accurate From identities, publish authentication records, and avoid treating a new sending provider as a clean slate that removes the need for good list hygiene.

Operational checklist for agencies and small teams

The 90-day rule is most painful when nobody knows all the deployed integrations. A lightweight credential register prevents that.

Maintain a private inventory with one row per credential, not merely per provider account. Include:

client or product owner;
application and environment;
provider account or subaccount;
credential label and last four characters where available;
permission scope and sending domain;
secret-storage location—not the secret value;
last successful health-check timestamp;
alert destination and escalation owner;
renewal, rotation, or inactivity policy; and
tested rollback instructions.

Review it quarterly, and test the most dormant workflows deliberately. The point is not bureaucracy. It is to make sure an old website still has a responsible owner before its first important message fails.

For the smallest sites, this can be a spreadsheet plus one scheduled job and an alerting inbox. For a larger agency, it may become infrastructure-as-code, a secret manager, centralized logs, and automated account reporting. The underlying control is the same: every production secret should have a purpose, an owner, a scope, and a test.

The real lesson from Brevo’s 90-day policy

The Reddit complaint correctly identifies a product-expectation problem. Most users interpret “no expiration” as “this key will remain valid until I revoke it.” Brevo’s current documentation defines it more narrowly: no fixed date, but still subject to inactivity deactivation. [2][4]

Whether that policy is acceptable depends on the application. For a frequently active API, it may be a sensible security feature with no meaningful downside. For a low-volume form or side project, it introduces maintenance work that can outweigh the attraction of a free tier or familiar interface.

The best response is not to gamble on a quiet customer action keeping credentials alive. Either implement a safe monitored API health check, or choose a provider whose documented credential lifecycle matches the operational promise you need to make. In both cases, use restricted keys, preserve message-level observability, protect the secret, and test the email path before a customer has to discover it for you.

FAQ

Does Brevo’s “no expiration” setting mean an API key never expires?

No. Brevo says “no expiration” means the key has no fixed calendar expiry date. A key that does not make a successful API call for 90 days is still deactivated under its separate inactivity policy. [2][3]

Can a Brevo API key be kept active without sending a fake email?

Yes, based on Brevo’s documentation, a successful API call is what matters for the inactivity rule. A scheduled, read-only authenticated health check is generally cleaner than generating artificial transactional messages. Ensure the request uses the same production key and has monitoring around failures. [2]

Does switching from the Brevo API to SMTP avoid the 90-day rule?

Not necessarily. Brevo’s SMTP-key documentation also distinguishes no fixed expiry from its inactivity policy. Verify the current rules for the specific credential type before changing protocols. [6]

Are non-expiring API keys less secure?

They can be riskier if teams forget they exist, give them broad access, or store them poorly. A non-expiring key can still be managed safely through narrow permissions, secure storage, monitoring, documented ownership, and deliberate rotation. OWASP recommends centralized secret lifecycle management for precisely these reasons. [5]

What should an agency monitor for low-volume email integrations?

Monitor credential health, provider API failures, message-queue failures, sending-domain status, bounces, suppressions, and the complete outcome of a controlled test message. Also maintain a register showing the client owner, application, key scope, secret location, and alert recipient for every deployed integration.

Brevo API Key Expiration: How the 90-Day Inactivity Rule Affects Low-Volume Apps