Brevo API: gyakorlati fejlesztői útmutató

Brevo API útmutató fejlesztőknek: hitelesítés, alap-URL, kapcsolatok, tranzakciós e-mail, kampányok, CRM-objektumok, webhookok, korlátok és valós tapasztalatok.

Tajo Team

Frissítve 2026. aug. 19.

0 látogatás · 7 nap

Brevo API

Brevo API?

A Brevo egyetlen REST API-t tesz közzé, amely átfogja a tranzakciós üzenetküldést, a marketingkampányokat, a kapcsolati adatokat és a CRM-rekordokat. Az első 201-es választ nagyjából két perc alatt eléred. Egy olyan éles integráció, amely nem veszít csendben adatot, jóval tovább tart, mert a legfontosabb korlátok egy része vagy dokumentálatlan, vagy ellentmond annak, amit az API magáról állít.

Ez az útmutató mindkét felét lefedi: a végpontokat, SDK-kat és hitelesítést, amelyre az első napon szükséged van, és azokat a platformkorlátokat, amelyekre már a szállítás előtt tervezned kell.

Mit fed le a Brevo API

Minden egyetlen hoszt és egyetlen verzióútvonal alatt él. A fejlesztői dokumentáció négy termékterületre bontja a felületet:

Üzenetküldés: tranzakciós e-mail, SMS és WhatsApp, beleértve a kötegelt küldést, az időzítést és az üzenetaktivitást.
Marketingplatform: kapcsolatok, listák, szegmensek és e-mail kampányok.
E-kereskedelem: termékek, rendelések és vásárlói eseménykövetés.
Beszélgetések: a chatwidget és a programozott beszélgetéskezelés.

Ezek a területek egy fiókon, egy kapcsolati adatbázison és egy API-kulcson osztoznak. Ez kényelmes, és időnként veszélyes is: egy teszt gondolatmenettel megírt szkript ugyanazokkal a kapcsolatokkal beszélget, amelyeknek a kampányaid küldenek.

Tranzakciós kontra marketing

A két család elég eltérően viselkedik ahhoz, hogy az összekeverésük legyen a leggyakoribb tervezési hiba.

	Tranzakciós	Marketing
Elsődleges végpont	`POST /v3/smtp/email`	`POST /v3/emailCampaigns`
Címzés	Explicit címzettek a kérésben	`listIds` vagy `segmentIds`
Kiváltó ok	Az alkalmazásod, valós időben	Időzítve vagy kérésre
Jellemző mennyiségi mintázat	Folyamatos, egyszerre egy üzenet	Lökésszerű, egy nagy küldés
Sebességkorlát-hozzáállás	Nagyon magas, standard csomagon másodpercenként 1000 kérés	Alacsony, a kampányvégpontok az általános plafon alá esnek

Ha még azt mérlegeled, hogy a Brevo egyáltalán a megfelelő platform-e, a platform áttekintése lefedi ezt a terepet.

Hitelesítés és kulcskezelés

A Brevo egy egyszerű API-kulcsot használ egyedi fejlécben. A fejléc neve api-key, nem Authorization, és nincs Bearer előtag. Ez szinte mindenkit megzavar, aki előbb valamelyik másik üzenetküldő API-t használta.

curl https://api.brevo.com/v3/account \
  -H "api-key: $BREVO_API_KEY"

A kulcsokat a Brevo alkalmazásban hozod létre, a fiókbeállítások alatt, az SMTP and API részben, az API keys fülön. Minden kulcsnak adj beszédes nevet, amely arra a rendszerre utal, amelyik használja. A kulcs értéke pontosan egyszer jelenik meg a létrehozáskor, így ha elveszíted, újat generálsz, nem pedig visszaszerzed a régit.

Néhány gyakorlati szabály:

Adj ki külön kulcsot minden telepítési célkörnyezethez és minden szolgáltatáshoz. Egy kompromittált kulcs visszavonása soha ne állítson le három egymástól független rendszert.
A szokásos API-kulcsok fiókszintűek. Minden kulcsot úgy kezelj, mint teljes hozzáférést a kapcsolatokhoz, a küldéshez és a CRM-adatokhoz.
A Brevo OAuth 2.0-t is támogat azokhoz az alkalmazásokhoz, amelyek más Brevo-fiókok nevében járnak el, ezt a kulcsfolyamattal együtt írja le az authentication schemes oldal.
Az MI-asszisztensek által használt MCP-szerver külön tokent vár, és az tényleg bearer fejlécet használ. Ez a token ugyanazon az API keys képernyőn készül, de nem cserélhető fel egy REST-kulccsal.

Alap-URL, verziózás és az első írás

Az alap-URL a https://api.brevo.com/v3/. A verzió az útvonalban van, nem fejlécben, és a v3 a jelenlegi generáció. Ebben az útmutatóban minden útvonal ehhez az alaphoz képest értendő.

Egy első írás informatívabb, mint egy első olvasás, mert azokat a részeket mozgatja meg, amelyek általában rosszul vannak beállítva (különösen az ellenőrzött feladókat):

curl -X POST https://api.brevo.com/v3/smtp/email \
  -H "api-key: $BREVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sender": { "name": "Ops", "email": "[email protected]" },
    "to": [{ "email": "[email protected]", "name": "Dev" }],
    "subject": "First transactional send",
    "htmlContent": "<html><body><p>It works.</p></body></html>",
    "tags": ["smoke-test"]
  }'

A sikeres küldés 201-et ad vissza egy messageId értékkel. Az időzített küldés 202-t ad.

A végpontok, amelyeket tényleg használni fogsz

Kapcsolatok

A POST /v3/contacts létrehoz egy kapcsolatot. A törzs átveszi az email mezőt, egy attributes térképet az egyedi mezőknek, a listIds értéket, az ext_id mezőt a saját külső kulcsodnak, és azt a két jelzőt, amely a gyakorlatban a legfontosabb: az updateEnabled, amely upserté alakítja a hívást, és a getId, amelytől a válasz visszaadja a kapcsolat azonosítóját.

Az olvasás a GET /v3/contacts végponton megy, amely a limit (alapértelmezetten 50, legfeljebb 1000) és az offset paraméterrel lapoz, valamint támogatja a modifiedSince és a createdSince értéket UTC-ben. Az inkrementális szinkronizálás támaszkodjon a modifiedSince értékre a teljes lista végigjárása helyett. Vedd figyelembe, hogy a filter paraméter csak egyenlőségoperátort támogat, így minden ennél kifejezőbb dolog a szegmensekbe tartozik.

Tömeges betöltéshez a POST /v3/contacts/import elfogadja a fileUrl, fileBody vagy jsonBody mezőt, a listIds értéket célozza, aszinkron fut, és processId értéket ad vissza. A Brevo 10 MB-os maximális törzsméretet dokumentál, és azt ajánlja, hogy maradj 8 MB közelében, mert a feldolgozás felfújja a hasznos terhet. Add meg a notifyUrl értéket, hogy értesülj az eredményről lekérdezgetés helyett.

Tranzakciós e-mail

A POST /v3/smtp/email az igásló. A sender, to, subject és htmlContent mezőkön túl ezeket érdemes ismerned:

templateId a params mezővel, amely a beágyazott tartalmat egy Brevo-sablonra és annak változóbehelyettesítéseire cseréli. Az egyes verziók paraméterei 100 KB-ban, a paraméterek összesített mérete 1000 KB-ban van korlátozva.
messageVersions, amely egy hívásban küld személyre szabott változatokat, verziónként legfeljebb 99 címzettnek.
tags, amelyet mindig érdemes beállítanod. A címkék visszajönnek a webhook-eseményeken, és ez az egyetlen olcsó mód arra, hogy egy kézbesítési eseményt összekapcsolj az őt előállító kódúttal.
scheduledAt a batchId értékkel a jövőbeli küldésekhez, amelyeket esetleg csoportosan szeretnél visszavonni.
headers Title-Case formában az egyedi SMTP-fejlécekhez.

Egyetlen kérés legfeljebb 2000 címzettet fogad el. A végpont és a kampányküldés közötti különbséghez a tranzakciós e-mail útmutató adja az üzenetküldési stratégia nézetét.

E-mail kampányok

A POST /v3/emailCampaigns megköveteli a name és sender mezőt, plusz pontosan egy tartalomforrást: htmlContent (legalább 10 karakter, 1 MB alatt), htmlUrl vagy templateId. A célközönség a recipients mezőbe kerül listIds vagy segmentIds formában, a scheduledAt pedig a YYYY-MM-DDTHH:mm:ss.SSSZ UTC-formátumot használja. A kiegészítő útvonalak lefedik az azonnali küldést, a tesztküldést, az állapotfrissítést és a kampányjelentés lekérését.

Cégek, üzletek és objektumok

A Brevo CRM-je két, egymást átfedő írási úttal rendelkezik, és nem mindegy, melyiket választod.

A CRM-útvonalak a POST /v3/companies, PATCH /v3/companies/{id}, DELETE /v3/companies/{id} és az üzletek megfelelő készlete. Ezek szinkronok. Egy PATCH 204-et ad vissza, amint a módosítás életbe lépett.

Az objektum-API a tömeges út: a POST /v3/objects/{object_type}/batch/upsert legfeljebb 1000 rekordot és kérésenként 1 MB-ot fogad, rekordonként legfeljebb 500 attribútumot, és objektumtípusonként és rekordonként legfeljebb 10 kapcsolati rekordot. 202-t ad vissza egy processId értékkel, ami elfogadottat jelent, nem alkalmazottat.

curl -X POST https://api.brevo.com/v3/objects/company/batch/upsert \
  -H "api-key: $BREVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "records": [
      {
        "identifiers": { "id": 12345 },
        "attributes": { "domain": "acme.example", "industry": "retail" }
      }
    ]
  }'

A Brevo CRM útmutató az objektummodellt az üzemeltető szemszögéből mutatja be.

Hivatalos SDK-k

A Brevo a getbrevo GitHub-szervezet alatt tartja karban a klienseket:

Nyelv	Repó
Node.js	`github.com/getbrevo/brevo-node`
Python	`github.com/getbrevo/brevo-python`
PHP	`github.com/getbrevo/brevo-php`
Java	`github.com/getbrevo/brevo-java`
C#	`github.com/getbrevo/brevo-csharp`
Go	`github.com/getbrevo/brevo-go`
Ruby	`github.com/getbrevo/brevo-ruby`

A Node-kliens az @getbrevo/brevo néven települ:

npm install @getbrevo/brevo

import { BrevoClient } from "@getbrevo/brevo";

const brevo = new BrevoClient({ apiKey: process.env.BREVO_API_KEY });

const result = await brevo.transactionalEmails.sendTransacEmail({
  subject: "Order confirmed",
  htmlContent: "<html><body><p>Thanks for your order.</p></body></html>",
  sender: { name: "Acme", email: "[email protected]" },
  to: [{ email: "[email protected]", name: "Customer" }],
  tags: ["order-confirmation"],
});

console.log("Message ID:", result.messageId);

A Python-kliens a pip install brevo-python paranccsal települ. Ha nem szeretnél két végpont kedvéért SDK-függőséget cipelni, a nyers HTTP-felület elég kicsi ahhoz, hogy közvetlenül hívd, ami egyben elszigetel az SDK-verziók kavargásától is:

import os
import requests

BASE = "https://api.brevo.com/v3"
HEADERS = {
    "api-key": os.environ["BREVO_API_KEY"],
    "Content-Type": "application/json",
}

def upsert_contact(email, attributes, list_ids):
    response = requests.post(
        f"{BASE}/contacts",
        headers=HEADERS,
        json={
            "email": email,
            "attributes": attributes,
            "listIds": list_ids,
            "updateEnabled": True,
        },
        timeout=30,
    )
    response.raise_for_status()
    return response

Létezik egy MCP-szerver is a https://mcp.brevo.com/v1/brevo/mcp címen az MI-asszisztenseknek, amelyet ugyanazon a beállítási képernyőn generált bearer tokennel hitelesítesz. Felfedezéshez és fiókkal kapcsolatos kérdésekhez hasznos, éles adatutakhoz nem.

Webhookok

A webhookokból tudod meg, mi történt egy küldés után. A POST /v3/webhooks létrehoz egyet, url, events, type mezőkkel, valamint opcionálisan a channel (email vagy sms), a batched, az egyedi headers és egy auth objektum megadásával.

Három webhooktípus létezik, eltérő eseményszókinccsel:

Tranzakciós: sent, request, delivered, hardBounce, softBounce, blocked, spam, invalid, deferred, click, opened, uniqueOpened, unsubscribed.
Marketing: spam, opened, click, hardBounce, softBounce, unsubscribed, listAddition, delivered, contactUpdated, contactDeleted.
Bejövő: inboundEmailProcessed és reply, amelyekhez ráadásul kell egy domain érték is.

curl -X POST https://api.brevo.com/v3/webhooks \
  -H "api-key: $BREVO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://yourapp.example/hooks/brevo",
    "type": "transactional",
    "events": ["delivered", "hardBounce", "spam", "unsubscribed"],
    "description": "Deliverability signals"
  }'

Három dolgot kell jól csinálnod. Először: egy fiók az összes típust együttvéve legfeljebb 40 webhookot tarthat, ezért a kezelődön belül irányíts esemény szerint, ahelyett hogy eseményenként külön végpontot regisztrálnál. Másodszor: használd a batched jelzőt, ha nagy mennyiségre számítasz, hiszen egyetlen sok eseményt hordozó kérést sokkal olcsóbb feldolgozni, mint sok kérést. Harmadszor: védd a fogadót. A Brevo közzéteszi a küldő IP-tartományait, és a végpontod ezekre a tartományokra való korlátozása a dokumentált megközelítés. Második rétegként add hozzá a saját megosztott titkodat a headers mezőn keresztül.

A kezelőknek idempotensnek kell lenniük. A deduplikációs kulcs az üzenetazonosító, az eseménytípus és az időbélyeg együttese legyen.

Sebességkorlátok és hibakezelés

A Brevo sebességkorlátai végpontonként és csomagszintenként érvényesek, és a végpontok közötti szórás óriási.

Végpont	Standard	Professional és Enterprise
`POST /v3/smtp/email`	1000 RPS	2000 RPS
`POST /v3/transactionalSMS/send`	150 RPS	200 RPS
`/v3/contacts/...`	10 RPS, 36 000 RPH	20 RPS, 72 000 RPH
`POST /v3/events`	10 RPS, 36 000 RPH	Enterprise-on magasabb
`GET /v3/smtp/emails`	2 RPS, 7200 RPH	3 RPS, 10 800 RPH
Minden más	100 RPH	200 RPH

Az utolsó sor az, amelyik fáj. A küldés gyakorlatilag mérés nélküli, míg a kampánykezelés, a CRM-olvasások és a legtöbb adminisztratív hívás standard csomagon egy közös, óránkénti 100 kéréses kereten osztozik. Egy naiv visszatöltés, amely minden írás előtt kiolvas egy cégrekordot, két percen belül feléli az egyórányi keretet.

Minden válasz hordozza az x-sib-ratelimit-limit, x-sib-ratelimit-remaining és x-sib-ratelimit-reset fejlécet. Olvasd ki őket sikernél is, ne csak hibánál. A korlát túllépése 429-et ad, és a helyes válasz az, hogy megvárod a reset fejlécben szereplő intervallumot, majd exponenciális visszalépést alkalmazol szórással.

async function callBrevo(path, init, attempt = 0) {
  const response = await fetch(`https://api.brevo.com/v3${path}`, {
    ...init,
    headers: { "api-key": process.env.BREVO_API_KEY, "Content-Type": "application/json", ...init.headers },
  });

  if (response.status === 429 && attempt < 5) {
    const reset = Number(response.headers.get("x-sib-ratelimit-reset") || 1);
    const backoff = Math.pow(2, attempt) * 250 + Math.random() * 250;
    await new Promise((r) => setTimeout(r, reset * 1000 + backoff));
    return callBrevo(path, init, attempt + 1);
  }

  return response;
}

A 429-et és az 5xx-et próbáld újra. A 400-at vagy a 409-et soha ne próbáld újra vakon, mert mindkettő általában azt jelenti, hogy a kérés rossz, nem azt, hogy korai, és egy 409 kifejezetten más lépést igényel, nem ismétlést.

Tesztelés levélküldés nélkül

Add hozzá az X-Sib-Sandbox fejlécet drop értékkel egy tranzakciós küldéshez. A Brevo ellenőrzi a kérést, 201-et ad vissza egy messageId értékkel, semmit nem kézbesít, és nem ír e-mail naplóbejegyzést.

curl -X POST https://api.brevo.com/v3/smtp/email \
  -H "api-key: $BREVO_API_KEY" \
  -H "X-Sib-Sandbox: drop" \
  -H "Content-Type: application/json" \
  -d '{ "sender": { "email": "[email protected]" }, "to": [{ "email": "[email protected]" }], "subject": "Sandbox", "htmlContent": "<p>hi</p>" }'

Értsd meg, mit bizonyít ez, és mit nem. A sandbox mód kizárólag a kérés formátumát validálja. Semmit nem mond a feladó hitelesítéséről, a sablonok megjelenítéséről vagy a kézbesíthetőségről. Tarts fenn külön Brevo-fiókot mindannak az integrációs teszteléséhez, ami kapcsolatokhoz vagy CRM-adatokhoz nyúl, mert a sandbox mód a küldést fedi le, az API többi részét nem.

Korlátok, amelyek meghatározzák az integrációd tervezését

Ezek azok a megkötések, amelyek csak akkor bukkannak elő, amikor egy integráció valódi fiókon, nagy mennyiséggel fut. Több közülük ellentmond annak, amit az API magáról állít. Egyik sem alku tárgya, így az egyetlen értelmes válasz az, ha köréjük tervezel.

A cégekhez domain kell, és domainenként csak egy cég lehet

A GET /v3/crm/attributes/companies minden attribútumot nem kötelezőként jelent, és a cég létrehozásának referenciája is csak a name mezőt sorolja kötelezőnek. A gyakorlatban a POST /v3/companies egy nem üres domain attribútum nélkül 400-at ad hiányzó kötelező alapértelmezett attribútumokról szóló üzenettel. Az üres sztring ugyanúgy elbukik, mint az elhagyása.

Ami rosszabb: a domain egyediségét a rendszer kikényszeríti. Egy már használatban lévő domainre felvitt második cég 409-et ad. A B2B kereskedelemben ez szerkezeti gond: azok a leányvállalatok, amelyek egy vásárlói e-mail-domainen osztoznak, nem létezhetnek külön cégekként a Brevóban. Egy kapcsolat szinkronizálása is elég ahhoz, hogy megjelenjen egy cég az adott kapcsolat e-mail-domainjén, így egy létrehozás ütközhet olyan céggel, amelyet senki nem hozott létre kifejezetten. A helyes kezelő 409-nél átveszi a meglévő céget, ahelyett hogy hibára futna vagy újrapróbálkozna.

A nem deklarált attribútumok csendben eltűnnek

Ez a platform legveszélyesebb viselkedése, és a Brevo világosan dokumentálja: ha egy attribútum megjelenik egy kérésben, de korábban nem volt definiálva az objektum sémájában, semmi nem történik. Nincs hiba, nincs attribútumlétrehozás, nincs figyelmeztetés.

Egy 2xx válasz tehát nem bizonyíték arra, hogy az adatod megérkezett. Előbb olvasd ki a sémát, a saját kliensedben dobj el mindent, ami nincs deklarálva, és inkább tagadd meg egy olyan szinkronizálás futtatását, amelynek az attribútumai nem léteznek, mint hogy egy hónapig fél rekordokat írj, mielőtt bárki észrevenné.

Az attribútumszűrőket elfogadja, de figyelmen kívül hagyja

A GET /v3/companies?filters[attributes.domain]=... 200-at ad, és figyelmen kívül hagyja a szűrőt. Két teljesen eltérő szűrő ugyanazokat a rekordokat adja vissza. Ezen az útvonalon nincs működő mód arra, hogy attribútum alapján keress meg egy céget.

Ezt kombinálva azzal, hogy a szűretlen lista nagy fiókokon bármilyen oldalméretnél 504-gyel időtúllépésbe fut, egy létező cég a dokumentált úton valóban megtalálhatatlan lehet. A kerülőút a GET /v3/objects/company/records végigfésülése sort=desc rendezéssel, ami gyors, lapozható, visszaadja az attribútumokat, és értelmes oldalszámra korlátozható. Egy cég, amely épp 409-et váltott ki, szinte mindig pillanatokkal korábban jött létre, így a legújabbtól visszafelé haladó keresés gyorsan megtalálja.

Objektumtípusonként egymillió rekord, és nincs tömeges törlés

A POST /v3/objects/{type}/batch/upsert 400-at ad, amint egy objektumtípus elér egymillió rekordot. Nemcsak a létrehozásokat blokkolja, hanem a frissítéseket is: egy meglévő rekord megcímzése a saját numerikus azonosítójával ugyanúgy elbukik. A teljes objektumírási út egyszerre zárul be.

A plafon alá visszakerülni lassú, mert a POST /v3/objects/{type}/batch/delete 403-at ad a Brevo szabványos objektumtípusaira, például a company típusra. Az egyetlen út a DELETE /v3/companies/{id}, hívásonként egy rekord, nagyjából 156 ms-onként. 124 000 rekord így történő kitakarítása 20 párhuzamos munkással órákig tartott. Ütemezetten figyeld a rekordszámot, ahelyett hogy egy elbukott szinkronizálásból értesülnél a plafonról, és a nagy mennyiségű frissítéseket a PATCH /v3/companies/{id} végponton keresztül vezesd, amelyre nem vonatkozik ilyen korlát.

Az `ext_id` a Brevo azonosítója, nem a tiéd

Az objektumrekordokon az identifiers.ext_id a Brevo saját CRM-cégazonosítóját tartalmazza, egy Mongo-stílusú sztringet. Ez nem szabadon használható külső kulcs. Ha az upsertet a saját platformod azonosítójára állított ext_id értékre kulcsolod, az egyeztetés helyett duplikátumokat hoz létre. A külső azonosítód egy saját, deklarált attribútumba tartozik.

Az objektum-upsertek aszinkronok, a CRM-írások nem

A batch/upsert 202-t és egy processId értéket ad vissza, majd később alkalmazza a változást. Egy nem létező azonosító aszinkron módon bukik el, és a hívód továbbra is 202-t kap. A PATCH /v3/companies/{id} 204-et ad, és szinkron módon lép életbe. Ha a szinkronizálásod sikert jelent, utólagos olvasás nélkül csak a szinkron út érdemli meg ezt a szót.

Rövid integrációs ellenőrzőlista

Külön API-kulcsok szolgáltatásonként és környezetenként, személyi változásoknál rotálva.
Minden írás egy kliensen megy át, amely olvassa a sebességkorlát-fejléceket, és 429-nél visszalép.
Az attribútumsémát indításkor ellenőrzöd, és a szinkronizálás megtagadja a futást, ha hiányoznak az attribútumai.
A cég létrehozásánál a 409 azt jelenti, hogy átveszed, nem azt, hogy újrapróbálod.
A tömeges utak az objektum-API-t használják az átbocsátásért, a CRM-útvonalakat pedig mindenhez, amit vissza kell igazolni.
A webhookok idempotensek, kötegeltek, IP-korlátozottak, és megosztott titkot tartalmazó fejlécet hordoznak.
Az inkrementális kapcsolatszinkronizálás a modifiedSince értéket használja, nem teljes listabejárást.

Ennek a rétegnek a megépítése és karbantartása valódi mérnöki munka: sémaellenőrzés, visszalépés, átvételi logika, egyeztetés. A Tajo azért létezik, hogy ezt magára vegye, és a Shopify- és kereskedelmi adatokat szinkronban tartsa a Brevo kapcsolataival, cégeivel és eseményeivel anélkül, hogy bárkinek kézzel kellene megírnia az újrapróbálkozási és deduplikációs logikát. Ha inkább magad drótozod össze, a Brevo integrációs útmutató végigveszi azokat az adatmodell-döntéseket, amelyek a kód előtt jönnek.

Fő tanulságok

Az API egyetlen REST-felület a https://api.brevo.com/v3/ címen, amelyet bearer token helyett egy api-key fejléccel hitelesítesz.
A sebességkorlátok vadul egyenetlenek: a küldés gyakorlatilag mérés nélküli, míg a legtöbb más végpont standard csomagon óránként 100 kérésen osztozik.
Hivatalos SDK-k hét nyelvre léteznek, de a HTTP-felület elég egyszerű ahhoz, hogy közvetlenül hívd, ha csak néhány végpontra van szükséged.
A sandbox mód kizárólag a kérés formátumát validálja, ezért tarts külön fiókot mindennek a tesztelésére, ami a küldésen túlmutat.
Egy 2xx válasz nem bizonyítja, hogy az írás életbe lépett. A nem deklarált attribútumok csendben eltűnnek, az objektum-upsertek pedig aszinkronok.
Tervezz a fix korlátok köré: domainenként egy cég, objektumtípusonként egymillió rekord, nincs tömeges törlés a szabványos objektumokra, és az attribútumszűrők csendben nem csinálnak semmit.

Gyakran Ismételt Kérdések

Mi a Brevo API alap-URL-je?

Minden Brevo REST-hívás a https://api.brevo.com/v3/ címre megy. A verzió az útvonal része, és a v3 a jelenlegi generáció, így például a tranzakciós küldés teljes útvonala https://api.brevo.com/v3/smtp/email.

Hogyan hitelesítesz a Brevo API-nál?

A kulcsodat egy api-key nevű HTTP-fejlécben küldöd el. A Brevo nem használ Authorization vagy Bearer fejlécet a szokásos API-kulcsokhoz. A kulcsokat a fiókbeállításokban, az SMTP and API részen, az API keys fülön hozod létre, és az értéket a rendszer csak egyszer mutatja meg.

Mekkorák a Brevo API korlátai?

A korlátok végpontonként és csomagszintenként eltérnek. Standard fiókon a tranzakciós küldési végpont másodpercenként 1000 kérést enged, a kapcsolatokhoz tartozó végpontok másodpercenként 10-et, minden más végpont pedig óránként 100 kérésre van korlátozva. A Professional és Enterprise csomagok magasabb szintet kapnak. A korlát túllépése 429-es választ ad.

Vannak hivatalos Brevo SDK-k?

Igen. A Brevo Node.js, Python, PHP, Java, C#, Go és Ruby klienseket ad ki a getbrevo GitHub-szervezet alatt. A Node-csomag az @getbrevo/brevo az npm-en, a Python-csomag pedig a brevo-python a PyPI-n.

Hogyan tesztelhetem a Brevo API-t valódi e-mail küldése nélkül?

Add hozzá az X-Sib-Sandbox fejlécet drop értékkel egy tranzakciós küldéshez. A Brevo ellenőrzi a kérést, 201-et ad vissza egy messageId értékkel, semmit nem küld el, és nem ír e-mail naplóbejegyzést. Csak a kérés formátumát ellenőrzi, a kézbesíthetőséget nem.

Milyen webhook-eseményeket támogat a Brevo?

A tranzakciós webhookok a sent, request, delivered, hardBounce, softBounce, blocked, spam, invalid, deferred, click, opened, uniqueOpened és unsubscribed eseményeket fedik le. A marketing webhookok kiegészülnek a listAddition, contactUpdated és contactDeleted eseményekkel. A bejövő webhookok az inboundEmailProcessed és a reply eseményt kezelik. Egy fiók összesen legfeljebb 40 webhookot tarthat.

Létrehozhatok két céget ugyanazzal a domainnel a Brevóban?

Nem. A Brevo kikényszeríti a domain egyediségét a cégrekordokon, és 409-es hibát ad domain-egyediségi üzenettel, ha megpróbálod. A helyes integrációs viselkedés az, hogy átveszed a meglévő céget, ahelyett hogy újrapróbálnád a létrehozást.

Miért adott sikeres választ a Brevo API-írásom, ha semmi nem változott?

Az objektum- és CRM-írások csendben eldobják azokat az attribútumokat, amelyek nincsenek deklarálva az objektum sémájában. A Brevo ezt a viselkedést nyíltan dokumentálja: nincs hiba, és nem jön létre attribútum. Előbb olvasd ki a sémát, és ellenőrizd az írást, ahelyett hogy megbíznál egy 2xx státuszban.

Van tömeges törlés a Brevo API-ban?

A Brevo szabványos objektumtípusaira, például a company típusra nincs. A tömeges törlési útvonal 403-at ad rájuk, így a takarítás rekordonként egy hívással fut a DELETE /v3/companies/{id} végponton keresztül. A tömeges takarítást órákban tervezd, ne percekben.

Cikk megosztása:

Vissza az összes cikkhez

business-tools