Migrate from Brevo

What changes

This guide covers Brevo's transactional email API, POST https://api.brevo.com/v3/smtp/email with an api-key header. Brevo uses camelCase fields (htmlContent, replyTo) and address objects; SendHQ uses snake_case fields and address strings.

• No SMTP relay and no Brevo-compatible endpoint. SendHQ is a JSON REST API at https://sendhq.cc/api/v1. There is no zero-code-change path: every call site moves to POST /emails. There is no official SendHQ SDK, so use your language's HTTP client behind one small adapter.
• Attachments are uploaded to a draft first and sent with draft_id, not inlined as base64 in the send body. There is no inline (CID) image support.
• Tags, categories, metadata, and custom variables have no equivalent on a send and are not returned in webhooks. Unknown JSON fields are ignored, not rejected, so remove them deliberately. Store your own correlation data against the returned em_… ID. labels file a message in the SendHQ mailbox; they are not analytics tags.
• Scheduled sends, open tracking, and click tracking are not available on POST /emails. Scheduling and open/click reports exist only for newsletter broadcasts.
• Suppression lists cannot be imported. SendHQ builds its list from its own bounces and complaints. Keep the exported list in your application during cutover (see below).
• Integration trial. Until a paid plan is active, a workspace can deliver only to the account email or a mailbox-simulator address (…@simulator.amazonses.com), and attachments need a paid plan.

Concept mapping

How each Brevo concept carries over. Where SendHQ has nothing equivalent, the row says so.

Sending: endpoint and fields

SendHQ limits that affect a migration

Before and after: Node.js

// @getbrevo/brevo
import { BrevoClient } from "@getbrevo/brevo";
const brevo = new BrevoClient({ apiKey: process.env.BREVO_API_KEY });

await brevo.transactionalEmails.sendTransacEmail({
  sender: { name: "Acme", email: "hello@example.com" },
  to: [{ email: user.email }],
  subject: "Welcome to Acme",
  htmlContent: "<p>Your account is ready.</p>",
});

// No SendHQ SDK: call the REST API with fetch (Node 18+).
const res = await fetch("https://sendhq.cc/api/v1/emails", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SENDHQ_API_KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": `welcome-${user.id}`, // one stable key per logical send
  },
  body: JSON.stringify({
    from: "Acme <hello@example.com>",
    to: [user.email],
    reply_to: "support@example.com",
    subject: "Welcome to Acme",
    html: "<p>Your account is ready.</p>",
    text: "Your account is ready.",
  }),
});
const body = await res.json();
if (!res.ok) throw new Error(`SendHQ ${res.status}: ${body.error?.message}`);
const emailId = body.id; // "em_…": store it with the event that caused the email

Before and after: Python

# brevo-python
import os
from brevo import Brevo
from brevo.transactional_emails import SendTransacEmailRequestSender, SendTransacEmailRequestToItem

client = Brevo(api_key=os.environ["BREVO_API_KEY"])
client.transactional_emails.send_transac_email(
    subject="Welcome to Acme",
    html_content="<p>Your account is ready.</p>",
    sender=SendTransacEmailRequestSender(name="Acme", email="hello@example.com"),
    to=[SendTransacEmailRequestToItem(email=user.email)],
)

# No SendHQ SDK: call the REST API with requests.
import os
import requests

res = requests.post(
    "https://sendhq.cc/api/v1/emails",
    headers={
        "Authorization": f"Bearer {os.environ['SENDHQ_API_KEY']}",
        "Idempotency-Key": f"welcome-{user.id}",  # one stable key per logical send
    },
    json={
        "from": "Acme <hello@example.com>",
        "to": [user.email],
        "reply_to": "support@example.com",
        "subject": "Welcome to Acme",
        "html": "<p>Your account is ready.</p>",
        "text": "Your account is ready.",
    },
    timeout=30,
)
if not res.ok:
    raise RuntimeError(f"SendHQ {res.status_code}: {res.json()['error']['message']}")
email_id = res.json()["id"]  # "em_…": store it with the event that caused the email

Before and after: curl

curl https://api.brevo.com/v3/smtp/email \
  -H "api-key: $BREVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sender": {"name": "Acme", "email": "hello@example.com"},
    "to": [{"email": "customer@example.net"}],
    "replyTo": {"email": "support@example.com"},
    "subject": "Welcome to Acme",
    "htmlContent": "<p>Your account is ready.</p>",
    "textContent": "Your account is ready."
  }'

curl https://sendhq.cc/api/v1/emails \
  -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: welcome-user-42" \
  -d '{
    "from": "Acme <hello@example.com>",
    "to": ["customer@example.net"],
    "reply_to": "support@example.com",
    "subject": "Welcome to Acme",
    "html": "<p>Your account is ready.</p>",
    "text": "Your account is ready."
  }'

Attachments

Brevo takes an attachment array of hosted urls or base64 content with a name. In SendHQ, fetch or decode each file, upload it to a draft, and send with draft_id.

# 1. Create a draft (same from/to/subject as the send).
curl https://sendhq.cc/api/v1/drafts \
  -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from":"billing@example.com","to":["customer@example.net"],"subject":"Invoice 1042"}'
# -> {"id":"dr_…","attachments":[]}

# 2. Upload each file as raw bytes (at most 10 files, 10 MB in total).
curl https://sendhq.cc/api/v1/drafts/dr_123/attachments \
  -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/pdf" \
  -H "X-Filename: invoice-1042.pdf" \
  --data-binary @invoice-1042.pdf

# 3. Send with draft_id. The draft's files go with the message.
curl https://sendhq.cc/api/v1/emails \
  -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: invoice-1042" \
  -d '{"from":"billing@example.com","to":["customer@example.net"],"subject":"Invoice 1042","text":"Your invoice is attached.","draft_id":"dr_123"}'

Move the domain

Brevo authenticates a domain with a brevo-code TXT record at the root, a DKIM TXT record at mail._domainkey, and a DMARC record. SendHQ's DKIM CNAMEs use different selectors, so both can stay published. Keep exactly one DMARC record and, if you publish SPF, one SPF record with include:amazonses.com merged in.

Records for SendHQ

1. Add the domain with POST /domains {"name": "example.com"} or in the dashboard. Read the exact records with GET /domains/:id; GET /dns/provider?domain_id=… also returns the relative host to type at your DNS provider.
2. Publish the three DKIM CNAME records SendHQ returns: <token>._domainkey.example.com pointing to <token>.dkim.amazonses.com. These prove ownership and sign your mail. Cloudflare users can authorize a one-time setup instead, and Domain Connect providers get a consent link.
3. SPF: keep exactly one v=spf1 record per name. If you publish SPF for SendHQ, merge include:amazonses.com into the existing value; never add a second SPF record.
4. DMARC: keep exactly one record at _dmarc.example.com. If you have none, SendHQ recommends v=DMARC1; p=none; adkim=r; aspf=r while you confirm all legitimate mail passes.
5. Run POST /domains/:id/verify until the status is verified. DNS can pass through pending, checking, and propagating first.

Webhooks and events

Brevo webhooks are protected by IP allowlisting, basic auth, or a bearer token rather than a body signature. SendHQ signs each request, so add verification. Correlate on data.email_id where you used message-id, and read data.recipient where you used email.

Create an endpoint with POST /webhooks {"url": "https://example.com/webhooks/sendhq", "events": [...]} (omit events for all). The response includes the signing secret whsec_…; store it as SENDHQ_WEBHOOK_SECRET. Up to 10 endpoints per workspace. Each request is one JSON event, {"type", "created_at", "data"}, signed with the Standard Webhooks scheme (webhook-id, webhook-timestamp, webhook-signature: v1,<base64 HMAC-SHA256 of id.timestamp.body>). Answer 2xx within 10 seconds; failures are retried 8 times over about 27 hours with the same webhook-id, so deduplicate on it. Events can arrive out of order.

data always carries email_id, from, to, and subject (plus cc, thread_id, and template_key when present). Event-specific fields: email.delivered → recipients; email.delivery_delayed → recipients, delay.type, delay.diagnostic, delay.expiration; email.bounced → recipient, bounce.type (Permanent or Transient), bounce.sub_type, bounce.diagnostic, bounce.suppressed (one event per bounced recipient); email.complained → recipient, complaint.feedback_type; email.failed → reason; email.received → inbox_id, category. There are no open, click, or unsubscribe webhook events.

// Standard Webhooks signature check (any Standard Webhooks library also works).
import crypto from "node:crypto";

export function verifySendHQ(rawBody, headers, secret = process.env.SENDHQ_WEBHOOK_SECRET) {
  const id = headers["webhook-id"];
  const timestamp = headers["webhook-timestamp"];
  const signatures = String(headers["webhook-signature"] || "").split(" ");
  if (!id || !timestamp || Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) return null;
  const key = Buffer.from(secret.replace(/^whsec_/, ""), "base64");
  const expected = crypto.createHmac("sha256", key).update(`${id}.${timestamp}.${rawBody}`).digest();
  const ok = signatures.some((entry) => {
    const [version, value] = entry.split(",");
    const given = Buffer.from(value || "", "base64");
    return version === "v1" && given.length === expected.length && crypto.timingSafeEqual(given, expected);
  });
  return ok ? JSON.parse(rawBody) : null; // { type, created_at, data: { email_id, … } }
}

# Standard Webhooks signature check with the standard library.
import base64, hashlib, hmac, json, os, time

def verify_sendhq(raw_body: bytes, headers) -> dict | None:
    msg_id = headers.get("webhook-id")
    timestamp = headers.get("webhook-timestamp")
    signatures = (headers.get("webhook-signature") or "").split(" ")
    if not msg_id or not timestamp or abs(time.time() - int(timestamp)) > 300:
        return None
    secret = os.environ["SENDHQ_WEBHOOK_SECRET"].removeprefix("whsec_")
    signed = f"{msg_id}.{timestamp}.".encode() + raw_body
    expected = base64.b64encode(hmac.new(base64.b64decode(secret), signed, hashlib.sha256).digest()).decode()
    if not any(s.startswith("v1,") and hmac.compare_digest(s[3:], expected) for s in signatures):
        return None
    return json.loads(raw_body)  # {"type", "created_at", "data": {"email_id", ...}}

Suppressions and bounces

Export blocked contacts with GET /v3/smtp/blockedContacts (limit up to 100, offset). Each entry has email, reason.code (for example hardBounce, contactFlaggedAsSpam, unsubscribedViaEmail), blockedAt, and senderEmail:

offset=0
while :; do
  page=$(curl -s "https://api.brevo.com/v3/smtp/blockedContacts?limit=100&offset=$offset" -H "api-key: $BREVO_API_KEY")
  [ "$(echo "$page" | jq '.contacts | length')" -eq 0 ] && break
  echo "$page" | jq -r '.contacts[] | [.email, .reason.code] | @csv' >> brevo-blocked.csv
  offset=$((offset + 100))
done

SendHQ adds a suppression automatically for every permanent bounce and every complaint it sees, and refuses later sends to that address with 422. Read it with GET /suppressions (paged with limit and offset) or GET /blocked-recipients. There is no endpoint to import another provider's suppression list into it.

• Transactional sends: keep the exported list in your own database and check it in your SendHQ adapter before calling POST /emails. Drop that check once SendHQ has run long enough to build its own list.
• Newsletter contacts: import the addresses with POST /contact-imports and a status column of unsubscribed, bounced, or complained. Those rows import as unsubscribed, so broadcasts skip them. This does not block POST /emails.

Templates

Fetch each template with GET /v3/smtp/templates/{templateId} (subject, htmlContent). Brevo variables are written {{params.NAME}}; in SendHQ they become {{name}} with a declared variable, and the params object becomes template.data.

SendHQ hosted templates support plain variable substitution only: {{variable}}, where a variable key is lowercase letters, numbers, and underscores, declared with a type (text, number, url, or boolean), a required flag, and an optional fallback. Values are HTML-escaped; a url variable may only fill a whole href or src. There are no conditionals, loops, partials, helpers, or nested objects. Templates that use them need the logic moved into your code (render the varying part yourself and pass the result as html/text, or pass a precomputed text value).

# 1. Create the template (key: lowercase letters, numbers, hyphens).
curl https://sendhq.cc/api/v1/templates \
  -H "Authorization: Bearer $SENDHQ_API_KEY" -H "Content-Type: application/json" \
  -d '{"name":"Password reset","key":"password-reset"}'
# -> {"template":{"id":"tmpl_…","key":"password-reset"},"draft":{"revision":1,…},…}

# 2. Save the converted content and declare every variable.
curl -X PUT https://sendhq.cc/api/v1/templates/tmpl_123/draft \
  -H "Authorization: Bearer $SENDHQ_API_KEY" -H "Content-Type: application/json" \
  -d '{"revision":1,"name":"Password reset","subjectTemplate":"Reset your password, {{first_name}}",
       "htmlTemplate":"<p>Hi {{first_name}},</p><p><a href=\"{{reset_url}}\">Reset password</a></p>",
       "textTemplate":"Hi {{first_name}}, reset your password: {{reset_url}}",
       "variables":[{"key":"first_name","type":"text","required":true},{"key":"reset_url","type":"url","required":true}],
       "sampleData":{"first_name":"Asha","reset_url":"https://example.com/reset/abc"}}'

# 3. Check the exact output, then publish an immutable release.
curl -X POST https://sendhq.cc/api/v1/templates/tmpl_123/render -H "Authorization: Bearer $SENDHQ_API_KEY" \
  -H "Content-Type: application/json" -d '{"data":{"first_name":"Asha","reset_url":"https://example.com/reset/abc"}}'
curl -X POST https://sendhq.cc/api/v1/templates/tmpl_123/publish -H "Authorization: Bearer $SENDHQ_API_KEY"

# 4. Send by key: exactly one To recipient, no cc/bcc, no subject/html/text.
curl https://sendhq.cc/api/v1/emails -H "Authorization: Bearer $SENDHQ_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: reset-8f2c" \
  -d '{"from":"Acme <security@example.com>","to":["customer@example.net"],
       "template":{"key":"password-reset","data":{"first_name":"Asha","reset_url":"https://example.com/reset/abc"}}}'

Inbound email

This guide covers Brevo's transactional sending API only. If you also need receiving in SendHQ:

SendHQ receives mail into inboxes it stores; it does not post parsed messages to a URL of your choice, and it has no route expressions. To move receiving:

1. Verify the domain for sending first, then call POST /domains/:id/inbound/setup. It returns the one MX record to publish. When the domain already has MX records that point elsewhere (your team mailboxes, or the old provider), SendHQ uses inbound.<domain> instead, so existing mail keeps flowing. Check it with POST /domains/:id/inbound/verify.
2. Create each address with POST /inboxes {"domain_id": "dom_…", "local_part": "support", "name": "Support"}.
3. Subscribe a webhook to email.received. Its data has email_id, inbox_id, from, to, subject, and category; fetch the body with GET /emails/:id (html, text, attachments) and each file with GET /attachments/:id. Reply in the same thread with reply_to_email_id.
4. To keep a copy flowing to a human mailbox, use PUT /inboxes/:id/forwarding {"forward_to": "team@example.net"}; addresses other than the account owner's must confirm first.

Cutover plan

1. Prepare. Verify every From domain in SendHQ while Brevo keeps sending. DKIM records for different providers live under different selectors, so both can stay published for the whole cutover. Activate a paid plan before real traffic; the integration trial only delivers to your own address.
2. Build the switch. Route every send through one adapter with a provider setting per stream, for example EMAIL_PROVIDER_PASSWORD_RESET=sendhq, plus an optional percentage (hash the recipient or user ID so one person always gets the same provider). Keep the Brevo code path intact.
3. Parallel run. Keep both webhook handlers live. Store which provider sent each message next to its ID, so events, retries, and support lookups go to the right place.
4. Ramp. Start with one low-volume stream (password resets, receipts) to an internal list, then real users. Raise the SendHQ share as the workspace daily limit rises; the first day allows 100 recipients, and anything over the limit returns 429, which your adapter should send back to Brevo during the ramp instead of dropping.
5. Monitor. Watch GET /deliverability/stats, GET /deliverability/reputation, webhook email.bounced and email.complained rates, and your own 4xx/5xx counts per provider. A 423 means one From address is paused for bounce or complaint rates: stop that stream and clean its list.
6. Roll back by flipping the stream setting back to Brevo. Nothing in DNS has to change for a rollback while both providers' records stay published.
7. Finish. When every stream has run cleanly on SendHQ, remove the Brevo SDK, credentials, webhook endpoint, and DNS records that only it used (its DKIM selector, tracking or return-path CNAMEs, and its SPF include).

Hand this to your coding agent

Paste this into Claude Code, Cursor, Codex, or another coding agent at the root of your repository. It is self-contained: it lists the SendHQ endpoints, fields, and limits so the agent does not have to guess, and it asks for a report of anything it could not map. Review the diff like any other change, and register the webhook URL and DNS records yourself.

Migrate this codebase from Brevo to SendHQ. Keep user-visible behaviour identical. Do not send real email, change DNS, or call production APIs while working.

STEP 1: INVENTORY
Search the whole repository (application code, workers, scripts, infrastructure as code, CI config, .env examples, docs) for every use of Brevo, including: the @getbrevo/brevo npm package (BrevoClient, TransactionalEmailsApi, SendSmtpEmail), the brevo-python / brevo_python packages, sib-api-v3-sdk style clients, raw HTTP calls to api.brevo.com/v3/smtp/email, SMTP transports pointed at smtp-relay.brevo.com, BREVO_* or SENDINBLUE_* env vars, and transactional webhook handlers.
List each call site with: what it sends (transactional, marketing, inbound handling), the Brevo features it uses (templates and params, messageVersions, attachments, tags, scheduledAt, batchId, transactional webhooks), and the env vars it reads.

STEP 2: SENDHQ API FACTS (use exactly these; do not guess or invent other endpoints)
- Base URL: https://sendhq.cc/api/v1
- Auth: header "Authorization: Bearer <SENDHQ_API_KEY>". Keys start with re_. Server side only, never in browser or mobile code.
- There is no SendHQ SDK, no SMTP relay, and no Brevo-compatible endpoint. Call the REST API with the project's existing HTTP client (fetch, axios, requests, httpx, net/http, ...).
- Send one: POST /emails, Content-Type: application/json. Fields:
  from (string, "Name <addr@verified-domain>", required; the domain must be verified in SendHQ)
  to (string or array of strings, required), cc, bcc (string or array). At most 100 addresses across to+cc+bcc.
  subject (string), html (string), text (string). One of html, text, or template is required.
  reply_to (ONE address string, not an array)
  headers (object of string to string; not allowed: From, To, Cc, Bcc, Subject, Date, Message-ID, In-Reply-To, References, Content-Type, MIME-Version)
  message_class ("transactional" default, or "marketing", which adds SendHQ's unsubscribe link and headers unless you supply your own one-click List-Unsubscribe)
  template ({"key": "...", "data": {...}} or {"id": "tmpl_..."}; not combinable with subject/html/text; exactly one to and no cc/bcc)
  draft_id (attachments, see below), reply_to_email_id (thread a reply), labels (array of up to 10 mailbox label names)
  Response 201: {"id": "em_...", "providerMessageId": "...", "threadId": "..."}. Persist id.
- Unknown fields (tags, metadata, categories, custom variables, scheduled times, tracking flags) are ignored. Do not send them.
- Idempotency: header "Idempotency-Key" (max 200 chars), one stable key per logical send. Retrying the identical body with the same key replays the stored response (response header Idempotent-Replayed: true). Same key with a different body returns 409.
- Batch: POST /emails/batch {"emails": [ ...up to 100 send objects ]} returns 201 or 207 with {"data": [{"index", "ok", "id"} or {"index", "ok": false, "error": {"message", "status"}}], "count", "successful", "failed"}.
- Attachments: POST /drafts {"from", "to", "subject"} returns {"id": "dr_..."}; then for each file POST /drafts/{id}/attachments with the raw bytes as the body, header Content-Type: <mime type> and X-Filename: <name>; then POST /emails with "draft_id": "dr_...". Max 10 files and 10 MB per message. No inline/CID images.
- Errors: JSON {"error": {"message", "status", "code"?}}. 400 invalid input, 401 bad key, 402 trial or plan limit, 403 domain not verified or not owned, 404 missing resource, 409 idempotency conflict, 413 attachments too large, 422 recipient suppressed or unsubscribed, 423 this From address is paused, 429 usage or daily limit, 502/503 transient. Retry only 429/502/503, with backoff and the same Idempotency-Key and identical body.
- Webhooks: create with POST /webhooks {"url": "https://...", "events": [...]}; the response has "secret": "whsec_...". Event types: email.sent, email.delivered, email.delivery_delayed, email.bounced, email.complained, email.failed, email.received. One JSON event per request: {"type", "created_at", "data"}; data has email_id, from, to, subject, and per type: delivered -> recipients; delivery_delayed -> recipients, delay {type, diagnostic, expiration}; bounced -> recipient, bounce {type "Permanent"|"Transient", sub_type, diagnostic, suppressed}; complained -> recipient, complaint {feedback_type}; failed -> reason; received -> inbox_id, category. No open, click, or unsubscribe events.
  Verify Standard Webhooks signatures on the RAW body: headers webhook-id, webhook-timestamp, webhook-signature ("v1,<base64>", space separated if several). Expected = base64(HMAC-SHA256(key = base64-decode(secret without "whsec_"), message = "{webhook-id}.{webhook-timestamp}.{raw body}")). Constant-time compare, reject timestamps older than 5 minutes, dedupe on webhook-id, return 2xx within 10 seconds.
- Suppressions: SendHQ suppresses permanent bounces and complaints itself (GET /suppressions, GET /blocked-recipients). There is no import endpoint.
- Templates: POST /templates {"name", "key"}; PUT /templates/{id}/draft {"revision", "name", "subjectTemplate", "htmlTemplate", "textTemplate", "variables": [{"key", "type": "text"|"number"|"url"|"boolean", "required"}], "sampleData"}; POST /templates/{id}/render {"data"}; POST /templates/{id}/publish. Only {{variable}} substitution with lowercase_snake_case keys: no conditionals, loops, partials, or nested objects.
- Inbound: POST /domains/{id}/inbound/setup returns the MX record to publish; POST /inboxes {"domain_id", "local_part", "name"} creates an address; an email.received webhook carries data.email_id and data.inbox_id; GET /emails/{id} returns from, to, subject, html, text, and attachments (download with GET /attachments/{id}). Mail is stored, not forwarded to your URL.
- Full contract: https://sendhq.cc/openapi.json and https://sendhq.cc/docs/brevo-migration

STEP 3: FIELD MAPPING FROM BREVO
- sender {name, email} -> from "Name <email>". to/cc/bcc [{email, name}] -> arrays of "Name <email>" strings. replyTo {email} -> reply_to "email".
- htmlContent -> html, textContent -> text, subject -> subject, headers -> headers.
- templateId + params -> template {"key": "<new SendHQ key>", "data": params}.
- messageVersions -> POST /emails/batch, one message per version (max 100 per call).
- attachment ([{url}] or [{content, name}]) -> fetch/decode, upload to a draft, send with draft_id.
- tags, scheduledAt, batchId -> not supported; remove and report.
- {messageId} -> {"id": "em_..."}.
- Webhooks: request/sent -> email.sent; delivered -> email.delivered; deferred -> email.delivery_delayed; soft_bounce -> email.bounced (Transient); hard_bounce -> email.bounced (Permanent); spam -> email.complained; blocked, invalid_email, error -> email.failed or the synchronous error; opened, unique_opened, click, unsubscribed, proxy_open -> no SendHQ event, report. Add Standard Webhooks signature verification.
- Leave Brevo marketing (contacts, campaigns) code alone unless it sends transactional mail; list it in the report.

STEP 4: IMPLEMENT
- Create one SendHQ email adapter module with the same function signatures the app already uses, so call sites change as little as possible. Read the key from SENDHQ_API_KEY.
- Keep the Brevo implementation behind a switch (for example EMAIL_PROVIDER=sendhq|brevo, optionally per stream) so the team can run both and roll back. Default it to brevo.
- Env vars: add SENDHQ_API_KEY and SENDHQ_WEBHOOK_SECRET to every .env example, config schema, secret manifest, and deployment config where BREVO_API_KEY (or however the project names it) appear. Do not delete the Brevo variables yet.
- Generate one Idempotency-Key per logical send from data you already have (for example "<event>-<record id>") and reuse it on retries.
- Webhooks: add a SendHQ webhook route next to the existing Brevo handler. Map SendHQ events onto the same internal handlers (for example delivered, hard_bounce, spam). Correlate by the em_ id you stored at send time, not by Brevo message IDs.
- Suppressions: keep honouring the existing Brevo suppression data (export it to the app's database if the app does not already store it) and check it in the adapter before sending.
- SMTP senders: replace each SMTP transport that targets smtp-relay.brevo.com with the HTTP adapter; SendHQ has no SMTP relay.

STEP 5: TESTS
- Unit-test the adapter with a mocked HTTP client: exact URL, method, headers (Authorization, Content-Type, Idempotency-Key) and JSON body for a plain send, cc/bcc, reply_to, custom headers, a template send, a batch, and an attachment send (draft, upload, send with draft_id).
- Test error handling for 401, 409, 422, 423, 429 and 503, and that only 429/502/503 are retried with the same key.
- Test the webhook route: a valid signature is accepted, a tampered body, an old timestamp, and a wrong secret are rejected, a repeated webhook-id is processed once, and each event type reaches the right internal handler.
- Run the existing test suite and keep it green.

STEP 6: REPORT
Finish with a list of everything you could not map one-to-one, with file paths, for example: tags, scheduled sends, open/click handlers, Brevo marketing features, SMTP senders. Also list the env vars added, the webhook URL to register in SendHQ, and the DNS records the team must add by hand. Do not remove Brevo code or credentials; the team will do that after cutover.

Provider references

Provider details on this page were checked against these official pages on November 7, 2026. Check them again before you migrate; provider APIs change.

• Send a transactional email
• Batch send transactional emails
• Node.js SDK
• Python SDK
• SMTP integration
• Create a webhook
• Transactional webhooks
• Secured webhooks
• Get blocked contacts
• Get a template
• Send a transactional email (params)
• Domain authentication