Brevo API: ڈویلپرز کے لیے ایک عملی گائیڈ

ڈویلپرز کے لیے Brevo API گائیڈ: تصدیق، بیس URL، رابطے، ٹرانزیکشنل ای میل، مہمات، CRM آبجیکٹس، ویب ہکس، ریٹ لمٹس اور حقیقی دنیا کی حدود۔

Tajo Team

اپ ڈیٹ ہوا 19 اگست، 2026

0 وزٹس · 7 دن

Brevo API

Brevo API?

Brevo ایک ہی REST API فراہم کرتا ہے جو ٹرانزیکشنل پیغام رسانی، مارکیٹنگ مہمات، رابطوں کے ڈیٹا اور CRM ریکارڈز پر پھیلی ہوئی ہے۔ پہلی ریکویسٹ سے 201 حاصل کرنے میں تقریباً دو منٹ لگتے ہیں۔ ایسا پروڈکشن انٹیگریشن بنانے میں کہیں زیادہ وقت لگتا ہے جو خاموشی سے ڈیٹا نہ کھوئے، کیونکہ سب سے اہم پابندیوں میں سے کئی یا تو دستاویز شدہ نہیں ہیں یا اس کے خلاف ہیں جو API خود اپنے بارے میں بتاتا ہے۔

یہ گائیڈ دونوں پہلوؤں کا احاطہ کرتی ہے: وہ اینڈ پوائنٹس، SDKs اور تصدیق جن کی آپ کو پہلے دن ضرورت ہوگی، اور وہ پلیٹ فارم حدود جن کے گرد آپ کو شپ کرنے سے پہلے ڈیزائن بنانا ہوگا۔

Brevo API کس چیز کا احاطہ کرتا ہے

سب کچھ ایک ہی ہوسٹ اور ایک ہی ورژن پاتھ کے نیچے موجود ہے۔ ڈویلپر دستاویزات اس سطح کو چار پروڈکٹ حصوں میں تقسیم کرتی ہیں:

پیغام رسانی: ٹرانزیکشنل ای میل، SMS اور واٹس ایپ، بشمول بیچ سینڈز، شیڈولنگ اور پیغامات کی سرگرمی۔
مارکیٹنگ پلیٹ فارم: رابطے، لسٹیں، سیگمنٹس اور ای میل مہمات۔
eCommerce: پروڈکٹس، آرڈرز اور گاہک کے ایونٹ ٹریکنگ۔
Conversations: چیٹ وجیٹ اور پروگرام کے ذریعے گفتگو کا انتظام۔

یہ حصے ایک ہی اکاؤنٹ، ایک ہی رابطہ ڈیٹابیس اور ایک ہی API کی استعمال کرتے ہیں۔ یہ سہولت بھی ہے اور کبھی کبھار خطرہ بھی: اسٹیجنگ کے تصور پر لکھی گئی اسکرپٹ انہی رابطوں سے بات کر رہی ہوتی ہے جن کو آپ کی مہمات بھیجی جاتی ہیں۔

ٹرانزیکشنل بمقابلہ مارکیٹنگ

دونوں خاندان اتنے مختلف انداز میں کام کرتے ہیں کہ ان کو آپس میں گڈمڈ کرنا سب سے عام ڈیزائن کی غلطی ہے۔

	ٹرانزیکشنل	مارکیٹنگ
بنیادی اینڈ پوائنٹ	`POST /v3/smtp/email`	`POST /v3/emailCampaigns`
مخاطب سازی	ریکویسٹ میں واضح وصول کنندگان	`listIds` یا `segmentIds`
ٹرگر	آپ کی ایپلی کیشن، حقیقی وقت میں	شیڈول شدہ یا طلب پر بھیجا گیا
عام حجم کی شکل	مسلسل، ایک وقت میں ایک پیغام	جھٹکوں میں، ایک بڑا سینڈ
ریٹ لمٹ کی صورتحال	بہت زیادہ، معیاری پلانز پر فی سیکنڈ 1,000 ریکویسٹس	کم، مہم کے اینڈ پوائنٹس عمومی حد کے تحت آتے ہیں

اگر آپ ابھی تک یہ فیصلہ کر رہے ہیں کہ Brevo آپ کے لیے صحیح پلیٹ فارم ہے بھی یا نہیں، تو پلیٹ فارم کا جائزہ اس موضوع کا احاطہ کرتا ہے۔

تصدیق اور کی کا انتظام

Brevo ایک سادہ API کی کو کسٹم ہیڈر میں استعمال کرتا ہے۔ ہیڈر کا نام api-key ہے، Authorization نہیں، اور کوئی Bearer پیشوند نہیں ہوتا۔ یہ بات تقریباً ہر اس شخص کو الجھا دیتی ہے جس نے پہلے کوئی دوسرا میسجنگ API استعمال کیا ہو۔

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

کیز Brevo ایپ میں اکاؤنٹ سیٹنگز کے تحت، SMTP and API سیکشن میں، API keys ٹیب پر بنتی ہیں۔ ہر کی کو ایسا وضاحتی نام دیں جو اس سسٹم سے جڑا ہو جو اسے استعمال کرتا ہے۔ کی کی ویلیو بننے کے وقت بالکل ایک بار دکھائی جاتی ہے، لہٰذا اگر آپ اسے کھو دیں تو پرانی کو بحال کرنے کے بجائے نئی بنائیں۔

چند عملی اصول:

ہر ڈیپلائمنٹ ہدف اور ہر سروس کے لیے الگ کی جاری کریں۔ ایک متاثرہ کی کو منسوخ کرنے سے تین غیر متعلقہ سسٹمز کبھی بند نہیں ہونے چاہئیں۔
معیاری API کیز پورے اکاؤنٹ پر لاگو ہوتی ہیں۔ ہر کی کو رابطوں، بھیجنے اور CRM ڈیٹا تک مکمل رسائی سمجھیں۔
Brevo ان ایپلی کیشنز کے لیے OAuth 2.0 کی حمایت بھی کرتا ہے جو دوسرے Brevo اکاؤنٹس کی جانب سے عمل کرتی ہیں، جس کی وضاحت کی فلو کے ساتھ authentication schemes میں موجود ہے۔
AI اسسٹنٹس کے استعمال کردہ MCP سرور ایک الگ ٹوکن لیتا ہے اور وہ bearer ہیڈر استعمال کرتا ہے۔ وہ ٹوکن اسی API keys اسکرین میں بنتا ہے لیکن REST کی کے ساتھ تبادلہ پذیر نہیں ہے۔

بیس URL، ورژننگ اور آپ کی پہلی رائٹ

بیس URL https://api.brevo.com/v3/ ہے۔ ورژن ہیڈر کے بجائے پاتھ میں ہے، اور v3 موجودہ نسل ہے۔ اس گائیڈ کا ہر پاتھ اسی بیس کے نسبت سے ہے۔

پہلی رائٹ پہلی ریڈ سے زیادہ معلوماتی ہوتی ہے، کیونکہ یہ اکاؤنٹ کے ان حصوں کو آزماتی ہے جو عام طور پر غلط کنفیگر ہوتے ہیں (خاص طور پر تصدیق شدہ سینڈرز):

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"]
  }'

کامیاب سینڈ messageId کے ساتھ 201 واپس دیتا ہے۔ شیڈول شدہ سینڈ 202 واپس دیتا ہے۔

وہ اینڈ پوائنٹس جو آپ واقعی استعمال کریں گے

رابطے

POST /v3/contacts ایک رابطہ بناتا ہے۔ باڈی email، کسٹم فیلڈز کے لیے attributes میپ، listIds، آپ کی اپنی بیرونی کی کے لیے ext_id، اور وہ دو فلیگز لیتی ہے جو عملی طور پر سب سے اہم ہیں: updateEnabled، جو کال کو اپسرٹ میں بدل دیتا ہے، اور getId، جو جواب میں رابطے کی آئی ڈی واپس کراتا ہے۔

ریڈز GET /v3/contacts سے گزرتی ہیں، جو limit (ڈیفالٹ 50، زیادہ سے زیادہ 1000) اور offset کے ساتھ صفحہ بندی کرتا ہے، اور UTC میں modifiedSince اور createdSince کی حمایت کرتا ہے۔ بتدریج سنک کو پوری فہرست چھاننے کے بجائے modifiedSince پر انحصار کرنا چاہیے۔ خیال رہے کہ filter پیرامیٹر صرف مساوات کے آپریٹر کی حمایت کرتا ہے، اس لیے اس سے زیادہ اظہاری کوئی بھی چیز سیگمنٹ میں ہونی چاہیے۔

بلک لوڈنگ کے لیے، POST /v3/contacts/import ‏fileUrl، fileBody یا jsonBody قبول کرتا ہے، listIds کو ہدف بناتا ہے، اور غیر ہم وقتی طور پر چلتا ہے، processId واپس دیتے ہوئے۔ Brevo 10 MB کی زیادہ سے زیادہ باڈی دستاویز کرتا ہے اور 8 MB کے قریب رہنے کی سفارش کرتا ہے کیونکہ پارسنگ پے لوڈ کو پھلا دیتی ہے۔ notifyUrl فراہم کریں تاکہ آپ کو پولنگ کے بجائے نتیجہ خود معلوم ہو جائے۔

ٹرانزیکشنل ای میل

POST /v3/smtp/email اصل محنتی اینڈ پوائنٹ ہے۔ sender، to، subject اور htmlContent کے علاوہ، جاننے کے قابل فیلڈز یہ ہیں:

templateId بمع params، جو ان لائن مواد کی جگہ Brevo ٹیمپلیٹ اور اس کے متغیرات کی تبدیلیاں رکھ دیتا ہے۔ انفرادی ورژن پیرامز 100 KB تک محدود ہیں، مجموعی پیرامز 1000 KB تک۔
messageVersions، جو ایک ہی کال میں ذاتی نوعیت کے مختلف نسخے بھیجتا ہے، فی ورژن 99 وصول کنندگان تک۔
tags، جو آپ کو ہمیشہ مقرر کرنے چاہئیں۔ ٹیگز ویب ہک ایونٹس پر واپس آتے ہیں، اور یہی وہ واحد سستا طریقہ ہے جس سے ڈیلیوری ایونٹ کو اس کوڈ پاتھ سے جوڑا جا سکے جس نے اسے پیدا کیا۔
scheduledAt بمع batchId، ان مستقبل کے سینڈز کے لیے جنہیں آپ ایک گروپ کے طور پر منسوخ کرنا چاہ سکتے ہیں۔
headers، ٹائٹل کیس میں، کسٹم SMTP ہیڈرز کے لیے۔

ایک ریکویسٹ زیادہ سے زیادہ 2,000 وصول کنندگان قبول کرتی ہے۔ اس اینڈ پوائنٹ اور مہم بھیجنے کے فرق کے لیے، ٹرانزیکشنل ای میل گائیڈ میں پیغام رسانی کی حکمت عملی کا نقطہ نظر موجود ہے۔

ای میل مہمات

POST /v3/emailCampaigns کو name اور sender درکار ہیں، اور اس کے ساتھ بالکل ایک مواد کا ذریعہ: htmlContent (کم از کم 10 حروف، 1 MB سے کم)، htmlUrl یا templateId۔ آڈیئنس recipients میں listIds یا segmentIds کے طور پر جاتی ہے، اور scheduledAt ‏YYYY-MM-DDTHH:mm:ss.SSSZ UTC فارمیٹ استعمال کرتا ہے۔ ساتھی روٹس فوری بھیجنے، ٹیسٹ بھیجنے، اسٹیٹس اپ ڈیٹ کرنے اور مہم کی رپورٹ نکالنے کا احاطہ کرتے ہیں۔

کمپنیاں، ڈیلز اور آبجیکٹس

Brevo کے CRM میں دو باہم متداخل رائٹ پاتھ ہیں، اور درست انتخاب اہمیت رکھتا ہے۔

CRM روٹس یہ ہیں: POST /v3/companies، PATCH /v3/companies/{id}، DELETE /v3/companies/{id}، اور ڈیلز کے لیے اسی طرح کا سیٹ۔ یہ ہم وقتی ہیں۔ تبدیلی لاگو ہونے پر PATCH ‏204 واپس دیتا ہے۔

آبجیکٹس API بلک پاتھ ہے: POST /v3/objects/{object_type}/batch/upsert فی ریکویسٹ 1000 ریکارڈز اور 1 MB تک، فی ریکارڈ 500 ایٹریبیوٹس تک، اور فی آبجیکٹ ٹائپ فی ریکارڈ 10 ایسوسی ایشن ریکارڈز تک لیتا ہے۔ یہ processId کے ساتھ 202 واپس دیتا ہے، یعنی قبول کر لیا گیا، لاگو نہیں کیا گیا۔

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" }
      }
    ]
  }'

Brevo CRM گائیڈ آپریٹر کی طرف سے آبجیکٹ ماڈل کا احاطہ کرتی ہے۔

سرکاری SDKs

Brevo کلائنٹس کو getbrevo نامی GitHub تنظیم کے تحت برقرار رکھتا ہے:

زبان	ریپوزٹری
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`

Node کلائنٹ @getbrevo/brevo کے طور پر انسٹال ہوتا ہے:

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);

Python کلائنٹ pip install brevo-python سے انسٹال ہوتا ہے۔ اگر آپ دو اینڈ پوائنٹس کے لیے SDK کا انحصار نہیں اٹھانا چاہتے، تو خام HTTP سطح اتنی چھوٹی ہے کہ اسے براہ راست کال کیا جا سکے، جو آپ کو SDK ورژن کی مسلسل تبدیلیوں سے بھی محفوظ رکھتا ہے:

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

AI اسسٹنٹس کے لیے https://mcp.brevo.com/v1/brevo/mcp پر ایک MCP سرور بھی ہے، جس کی تصدیق اسی سیٹنگز اسکرین میں بننے والے bearer ٹوکن سے ہوتی ہے۔ یہ کھوج اور اکاؤنٹ سے متعلق سوالات کے لیے مفید ہے، پروڈکشن ڈیٹا پاتھس کے لیے نہیں۔

ویب ہکس

ویب ہکس وہ ذریعہ ہیں جن سے آپ کو معلوم ہوتا ہے کہ سینڈ کے بعد کیا ہوا۔ POST /v3/webhooks ایک ویب ہک بناتا ہے، جس میں url، events، type، اور اختیاری طور پر channel (email یا sms)، batched، کسٹم headers اور ایک auth آبجیکٹ ہوتے ہیں۔

تین ویب ہک ٹائپس ہیں جن کے ایونٹ الفاظ الگ ہیں:

ٹرانزیکشنل: sent، request، delivered، hardBounce، softBounce، blocked، spam، invalid، deferred، click، opened، uniqueOpened، unsubscribed۔
مارکیٹنگ: spam، opened، click، hardBounce، softBounce، unsubscribed، listAddition، delivered، contactUpdated، contactDeleted۔
ان باؤنڈ: inboundEmailProcessed اور reply، جن کے لیے اضافی طور پر ایک domain بھی درکار ہوتا ہے۔

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"
  }'

تین باتیں درست کرنا ضروری ہیں۔ پہلی، ایک اکاؤنٹ تمام ٹائپس ملا کر زیادہ سے زیادہ 40 ویب ہکس رکھ سکتا ہے، اس لیے ہر ایونٹ کے لیے الگ اینڈ پوائنٹ رجسٹر کرنے کے بجائے اپنے ہینڈلر کے اندر ایونٹ کے حساب سے روٹ کریں۔ دوسری، جب حجم کی توقع ہو تو batched فلیگ استعمال کریں، کیونکہ بہت سے ایونٹس اٹھانے والی ایک ریکویسٹ کو پروسیس کرنا کئی ریکویسٹس کے مقابلے میں کہیں سستا ہے۔ تیسری، وصول کنندہ کو محفوظ بنائیں: Brevo اپنی سینڈنگ IP رینجز شائع کرتا ہے، اور اپنے اینڈ پوائنٹ کو انہی رینجز تک محدود کرنا دستاویز شدہ طریقہ ہے۔ دوسری تہہ کے طور پر headers فیلڈ کے ذریعے اپنا شیئرڈ سیکرٹ بھی شامل کریں۔

ہینڈلرز کو آئیڈیم پوٹنٹ ہونا چاہیے۔ میسج آئی ڈی بمع ایونٹ ٹائپ بمع ٹائم اسٹیمپ کو ڈی ڈپلیکیشن کی کے طور پر لیں۔

ریٹ لمٹس اور خرابی کا انتظام

Brevo کی ریٹ لمٹس ہر اینڈ پوائنٹ اور ہر پلان ٹیئر کے حساب سے ہیں، اور اینڈ پوائنٹس کے درمیان فرق بہت بڑا ہے۔

اینڈ پوائنٹ	معیاری	Professional اور Enterprise
`POST /v3/smtp/email`	1,000 RPS	2,000 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 پر زیادہ
`GET /v3/smtp/emails`	2 RPS، 7,200 RPH	3 RPS، 10,800 RPH
باقی سب کچھ	100 RPH	200 RPH

آخری قطار ہی وہ ہے جو تکلیف دیتی ہے۔ بھیجنا عملاً بغیر پیمائش کے ہے، جبکہ مہم کا انتظام، CRM ریڈز اور زیادہ تر انتظامی کالز معیاری پلانز پر فی گھنٹہ 100 ریکویسٹس کا بجٹ آپس میں بانٹتی ہیں۔ ایسا سادہ لوح بیک فل جو ہر رائٹ سے پہلے کمپنی ریکارڈ پڑھتا ہے، دو منٹ سے بھی کم میں ایک گھنٹے کا کوٹہ ختم کر دے گا۔

ہر جواب x-sib-ratelimit-limit، x-sib-ratelimit-remaining اور x-sib-ratelimit-reset ساتھ لے کر آتا ہے۔ انہیں صرف ناکامی پر نہیں، کامیابی پر بھی پڑھیں۔ حد سے تجاوز پر 429 واپس آتا ہے، اور درست جواب یہ ہے کہ ریسیٹ ہیڈر میں دیے گئے وقفے کا انتظار کریں اور پھر جھٹکے کے ساتھ ایکسپونینشل بیک آف لگائیں۔

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;
}

429 اور 5xx کو دوبارہ آزمائیں۔ 400 یا 409 کو کبھی اندھا دھند دوبارہ نہ آزمائیں، کیونکہ دونوں کا مطلب عموماً یہ ہوتا ہے کہ ریکویسٹ وقت سے پہلے نہیں بلکہ غلط ہے، اور 409 کو خاص طور پر دہرانے کے بجائے کسی مختلف عمل کی ضرورت ہوتی ہے۔

میل بھیجے بغیر ٹیسٹنگ

ٹرانزیکشنل سینڈ میں X-Sib-Sandbox ہیڈر drop ویلیو کے ساتھ شامل کریں۔ Brevo ریکویسٹ کی توثیق کرتا ہے، messageId کے ساتھ 201 واپس دیتا ہے، کچھ ڈیلیور نہیں کرتا اور کوئی ای میل لاگ نہیں لکھتا۔

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>" }'

یہ سمجھ لیں کہ اس سے کیا ثابت ہوتا ہے اور کیا نہیں۔ سینڈ باکس موڈ صرف ریکویسٹ کے فارمیٹ کی توثیق کرتا ہے۔ یہ سینڈر کی تصدیق، ٹیمپلیٹ رینڈرنگ یا ڈیلیوریبلٹی کے بارے میں کچھ نہیں کہتا۔ رابطوں یا CRM ڈیٹا کو چھونے والی کسی بھی چیز کی انٹیگریشن ٹیسٹنگ کے لیے الگ Brevo اکاؤنٹ رکھیں، کیونکہ سینڈ باکس موڈ صرف بھیجنے کا احاطہ کرتا ہے، باقی API کا نہیں۔

وہ حدود جو آپ کے انٹیگریشن ڈیزائن کو شکل دیتی ہیں

یہ وہ پابندیاں ہیں جو صرف اس وقت ظاہر ہوتی ہیں جب کوئی انٹیگریشن حقیقی اکاؤنٹ پر حجم کے ساتھ چلے۔ ان میں سے کئی اس کے خلاف ہیں جو API خود اپنے بارے میں کہتا ہے۔ ان میں سے کوئی بھی قابل گفت و شنید نہیں، اس لیے واحد معقول ردعمل یہی ہے کہ ان کے گرد ڈیزائن بنایا جائے۔

کمپنیوں کو ڈومین درکار ہے، اور فی ڈومین صرف ایک کمپنی

GET /v3/crm/attributes/companies ہر ایٹریبیوٹ کو غیر لازمی بتاتا ہے، اور create-a-company ریفرنس صرف name کو لازمی قرار دیتا ہے۔ عملاً، غیر خالی domain ایٹریبیوٹ کے بغیر POST /v3/companies لازمی ڈیفالٹ ایٹریبیوٹس کے غائب ہونے کے پیغام کے ساتھ 400 واپس دیتا ہے۔ خالی اسٹرنگ بھی اسی طرح ناکام ہوتی ہے جیسے اسے چھوڑ دینا۔

اس سے بھی بدتر یہ کہ ڈومین کی انفرادیت نافذ ہے۔ پہلے سے استعمال ہونے والے ڈومین پر دوسری کمپنی 409 واپس دیتی ہے۔ B2B کامرس کے لیے یہ ساختی مسئلہ ہے: وہ ذیلی کمپنیاں جو ایک ہی خریدار ای میل ڈومین استعمال کرتی ہیں، Brevo میں الگ الگ کمپنیوں کے طور پر موجود نہیں رہ سکتیں۔ ایک رابطہ سنک کرنا بھی اس رابطے کے ای میل ڈومین پر کمپنی ظاہر کرنے کے لیے کافی ہے، اس لیے کریٹ اس کمپنی سے ٹکرا سکتا ہے جسے کسی نے واضح طور پر بنایا ہی نہ ہو۔ درست ہینڈلر 409 پر ناکام ہونے یا دوبارہ آزمانے کے بجائے موجودہ کمپنی کو اپنا لیتا ہے۔

غیر ڈیکلیئر شدہ ایٹریبیوٹس خاموشی سے رد ہو جاتی ہیں

یہ پلیٹ فارم کا سب سے خطرناک رویہ ہے، اور Brevo اسے صاف الفاظ میں دستاویز کرتا ہے: اگر کوئی ایٹریبیوٹ ریکویسٹ میں آئے مگر پہلے سے آبجیکٹ اسکیما میں متعین نہ ہو، تو کچھ نہیں ہوتا۔ نہ کوئی خرابی، نہ ایٹریبیوٹ کی تخلیق، نہ کوئی انتباہ۔

اس لیے 2xx جواب اس بات کا ثبوت نہیں کہ آپ کا ڈیٹا پہنچ گیا۔ لکھنے سے پہلے اسکیما پڑھیں، اپنے کلائنٹ میں ہر غیر ڈیکلیئر شدہ چیز چھوڑ دیں، اور ایسے سنک کو چلنے سے انکار کریں جس کی ایٹریبیوٹس موجود نہ ہوں، بجائے اس کے کہ ایک مہینے تک آدھا ریکارڈ لکھا جاتا رہے اور کسی کو خبر نہ ہو۔

ایٹریبیوٹ فلٹرز قبول ہوتے ہیں اور نظرانداز کر دیے جاتے ہیں

GET /v3/companies?filters[attributes.domain]=... ‏200 واپس دیتا ہے اور فلٹر کو نظرانداز کر دیتا ہے۔ دو بالکل مختلف فلٹرز وہی ریکارڈز واپس دیتے ہیں۔ اس روٹ سے کمپنی کو ایٹریبیوٹ کے ذریعے تلاش کرنے کا کوئی کارآمد طریقہ موجود نہیں۔

اس حقیقت کے ساتھ ملا کر کہ بغیر فلٹر والی فہرست بڑے اکاؤنٹس پر کسی بھی پیج سائز پر 504 کے ساتھ ٹائم آؤٹ ہو جاتی ہے، ایک موجودہ کمپنی دستاویز شدہ راستے سے واقعی ناقابل تلاش ہو سکتی ہے۔ اس کا حل یہ ہے کہ GET /v3/objects/company/records کو sort=desc کے ساتھ اسکین کیا جائے، جو تیز ہے، صفحہ بند ہے، ایٹریبیوٹس واپس دیتا ہے، اور معقول تعداد کے صفحات تک محدود رکھا جا سکتا ہے۔ جس کمپنی نے ابھی 409 پیدا کیا، وہ تقریباً ہمیشہ چند لمحے پہلے ہی بنی ہوتی ہے، اس لیے نئے سے پرانے کی ترتیب میں اسکین کرنا اسے جلد ڈھونڈ لیتا ہے۔

فی آبجیکٹ ٹائپ دس لاکھ ریکارڈز، اور کوئی بلک ڈیلیٹ نہیں

POST /v3/objects/{type}/batch/upsert اس وقت 400 واپس دینے لگتا ہے جب کوئی آبجیکٹ ٹائپ دس لاکھ ریکارڈز رکھ لے۔ یہ تخلیق کے ساتھ ساتھ اپ ڈیٹس کو بھی روکتا ہے: موجودہ ریکارڈ کو اس کی اپنی عددی آئی ڈی سے مخاطب کرنا بھی اسی طرح ناکام ہوتا ہے۔ آبجیکٹ رائٹ کا پورا راستہ ایک ساتھ بند ہو جاتا ہے۔

اس حد سے نیچے واپس آنا سست کام ہے، کیونکہ POST /v3/objects/{type}/batch/delete ‏company جیسے Brevo کے معیاری آبجیکٹ ٹائپس کے لیے 403 واپس دیتا ہے۔ واحد راستہ DELETE /v3/companies/{id} ہے، فی کال ایک ریکارڈ، تقریباً 156 ms میں۔ اس طریقے سے 124,000 ریکارڈز صاف کرنے میں 20 متوازی ورکرز کے ساتھ کئی گھنٹے لگے۔ ریکارڈ کی تعداد کو شیڈول پر مانیٹر کریں، بجائے اس کے کہ حد کا پتہ ناکام سنک سے چلے، اور زیادہ حجم والی اپ ڈیٹس کو PATCH /v3/companies/{id} سے گزاریں، جس پر ایسی کوئی حد نہیں۔

`ext_id` ‏Brevo کی آئی ڈی ہے، آپ کی نہیں

آبجیکٹ ریکارڈز پر، identifiers.ext_id میں Brevo کی اپنی CRM کمپنی آئی ڈی ہوتی ہے، ایک Mongo طرز کی اسٹرنگ۔ یہ کوئی آزاد بیرونی کی نہیں ہے۔ ext_id کو اپنے پلیٹ فارم کے شناخت کنندہ پر سیٹ کر کے اپسرٹ کرنا مماثلت کے بجائے نقلیں بناتا ہے۔ آپ کی بیرونی آئی ڈی کی جگہ اپنی ایک الگ ڈیکلیئر شدہ ایٹریبیوٹ ہے۔

آبجیکٹ اپسرٹس غیر ہم وقتی ہیں، CRM رائٹس نہیں

batch/upsert ‏202 اور ایک processId واپس دیتا ہے، پھر بعد میں لاگو کرتا ہے۔ غیر موجود آئی ڈی غیر ہم وقتی طور پر ناکام ہوتی ہے اور پھر بھی آپ کے کالر کو 202 ہی ملتا ہے۔ PATCH /v3/companies/{id} ‏204 واپس دیتا ہے اور ہم وقتی طور پر لاگو ہوتا ہے۔ اگر آپ کا سنک کامیابی کی اطلاع دیتا ہے تو فالو اپ ریڈ کے بغیر صرف ہم وقتی راستہ ہی اس لفظ کا حقدار ہے۔

ایک مختصر انٹیگریشن چیک لسٹ

ہر سروس اور ہر ماحول کے لیے الگ API کیز، جو عملے کی تبدیلی پر بدلی جائیں۔
تمام رائٹس ایک ہی کلائنٹ سے گزریں جو ریٹ لمٹ ہیڈرز پڑھے اور 429 پر بیک آف کرے۔
ایٹریبیوٹ اسکیما آغاز پر تصدیق ہو، اور ایٹریبیوٹس غائب ہونے کی صورت میں سنک چلنے سے انکار کرے۔
کمپنی کریٹ پر 409 کا مطلب ہے اپنانا، دوبارہ آزمانا نہیں۔
بلک راستے تھرو پٹ کے لیے آبجیکٹ API استعمال کریں اور جس چیز کی تصدیق ضروری ہو اس کے لیے CRM روٹس۔
ویب ہکس آئیڈیم پوٹنٹ، بیچڈ، IP کے لحاظ سے محدود ہوں اور شیئرڈ سیکرٹ ہیڈر رکھتے ہوں۔
بتدریج رابطہ سنک modifiedSince استعمال کریں، پوری فہرست چھاننے کے بجائے۔

اس تہہ کو بنانا اور برقرار رکھنا حقیقی انجینئرنگ کا کام ہے: اسکیما کی تصدیق، بیک آف، اپنانے کی منطق، مطابقت۔ Tajo اسی کو جذب کرنے کے لیے موجود ہے، جو Shopify اور کامرس ڈیٹا کو Brevo کے رابطوں، کمپنیوں اور ایونٹس کے ساتھ سنک میں رکھتا ہے بغیر اس کے کہ کوئی ہاتھ سے ری ٹرائی اور ڈی ڈوپ کی منطق لکھے۔ اگر آپ اسے خود جوڑ رہے ہیں تو Brevo انٹیگریشن گائیڈ ان ڈیٹا ماڈل کے فیصلوں کی وضاحت کرتی ہے جو کوڈ سے پہلے آتے ہیں۔

اہم نکات

API ایک ہی REST سطح ہے https://api.brevo.com/v3/ پر، جس کی تصدیق bearer ٹوکن کے بجائے api-key ہیڈر سے ہوتی ہے۔
ریٹ لمٹس شدید غیر ہموار ہیں: بھیجنا عملاً بغیر پیمائش کے ہے، جبکہ باقی زیادہ تر اینڈ پوائنٹس معیاری پلانز پر فی گھنٹہ 100 ریکویسٹس آپس میں بانٹتے ہیں۔
سات زبانوں کے لیے سرکاری SDKs موجود ہیں، لیکن HTTP سطح اتنی سادہ ہے کہ جب آپ کو صرف چند اینڈ پوائنٹس چاہئیں تو اسے براہ راست کال کیا جا سکتا ہے۔
سینڈ باکس موڈ صرف ریکویسٹ کے فارمیٹ کی توثیق کرتا ہے، اس لیے سینڈز سے آگے کسی بھی چیز کی ٹیسٹنگ کے لیے الگ اکاؤنٹ رکھیں۔
2xx جواب یہ ثابت نہیں کرتا کہ رائٹ لاگو ہو گئی۔ غیر ڈیکلیئر شدہ ایٹریبیوٹس خاموشی سے گرا دی جاتی ہیں، اور آبجیکٹ اپسرٹس غیر ہم وقتی ہیں۔
طے شدہ حدود کے گرد ڈیزائن بنائیں: فی ڈومین ایک کمپنی، فی آبجیکٹ ٹائپ دس لاکھ ریکارڈز، معیاری آبجیکٹس کے لیے کوئی بلک ڈیلیٹ نہیں، اور ایٹریبیوٹ فلٹرز جو خاموشی سے کچھ نہیں کرتے۔

اکثر پوچھے گئے سوالات

Brevo API کا بیس URL کیا ہے?

Brevo کی تمام REST کالز https://api.brevo.com/v3/ پر جاتی ہیں۔ ورژن پاتھ کا حصہ ہے اور v3 موجودہ نسل ہے، اس لیے ٹرانزیکشنل سینڈ جیسے اینڈ پوائنٹ کا مکمل پاتھ https://api.brevo.com/v3/smtp/email بنتا ہے۔

Brevo API کے ساتھ تصدیق کیسے کی جاتی ہے?

اپنی کی api-key نامی HTTP ہیڈر میں بھیجیں۔ Brevo معیاری API کیز کے لیے Authorization یا Bearer ہیڈر استعمال نہیں کرتا۔ کیز اکاؤنٹ سیٹنگز، پھر SMTP and API، پھر API keys میں بنتی ہیں اور ویلیو صرف ایک بار دکھائی جاتی ہے۔

Brevo API کی ریٹ لمٹس کیا ہیں?

حدود ہر اینڈ پوائنٹ اور ہر پلان ٹیئر کے حساب سے الگ ہیں۔ معیاری اکاؤنٹس پر ٹرانزیکشنل سینڈ اینڈ پوائنٹ فی سیکنڈ 1,000 ریکویسٹس کی اجازت دیتا ہے، رابطوں کے اینڈ پوائنٹس فی سیکنڈ 10، اور باقی ہر اینڈ پوائنٹ فی گھنٹہ 100 ریکویسٹس تک محدود ہے۔ Professional اور Enterprise پلانز کو زیادہ ٹیئر ملتے ہیں۔ حد سے تجاوز پر 429 واپس آتا ہے۔

کیا Brevo کے سرکاری SDKs موجود ہیں?

جی ہاں۔ Brevo، getbrevo نامی GitHub تنظیم کے تحت Node.js، Python، PHP، Java، C#، Go اور Ruby کے کلائنٹس شائع کرتا ہے۔ Node پیکج npm پر @getbrevo/brevo ہے اور Python پیکج PyPI پر brevo-python ہے۔

حقیقی ای میل بھیجے بغیر میں Brevo API کیسے ٹیسٹ کروں?

ٹرانزیکشنل سینڈ میں X-Sib-Sandbox ہیڈر drop ویلیو کے ساتھ شامل کریں۔ Brevo ریکویسٹ کی توثیق کرتا ہے، messageId کے ساتھ 201 واپس دیتا ہے، کچھ بھیجتا نہیں اور کوئی ای میل لاگ نہیں لکھتا۔ یہ صرف ریکویسٹ کے فارمیٹ کی جانچ کرتا ہے، ڈیلیوریبلٹی کی نہیں۔

Brevo کن ویب ہک ایونٹس کو سپورٹ کرتا ہے?

ٹرانزیکشنل ویب ہکس میں sent، request، delivered، hardBounce، softBounce، blocked، spam، invalid، deferred، click، opened، uniqueOpened اور unsubscribed شامل ہیں۔ مارکیٹنگ ویب ہکس میں listAddition، contactUpdated اور contactDeleted کا اضافہ ہوتا ہے۔ ان باؤنڈ ویب ہکس میں inboundEmailProcessed اور reply آتے ہیں۔ ایک اکاؤنٹ میں کل زیادہ سے زیادہ 40 ویب ہکس رکھے جا سکتے ہیں۔

کیا میں Brevo میں ایک ہی ڈومین کے ساتھ دو کمپنیاں بنا سکتا ہوں?

نہیں۔ Brevo کمپنی ریکارڈز پر ڈومین کی انفرادیت نافذ کرتا ہے اور کوشش کرنے پر ڈومین یونیک نیس کی خرابی کے ساتھ 409 واپس دیتا ہے۔ درست انٹیگریشن رویہ یہ ہے کہ کریٹ کو دوبارہ آزمانے کے بجائے موجودہ کمپنی کو اپنا لیا جائے۔

میری Brevo API رائٹ کامیاب کیوں دکھائی دی مگر کچھ تبدیل نہیں ہوا?

آبجیکٹ اور CRM رائٹس ایسی ایٹریبیوٹس کو خاموشی سے رد کر دیتی ہیں جو آبجیکٹ اسکیما میں ڈیکلیئر نہ ہوں۔ Brevo اس رویے کو واضح طور پر دستاویز کرتا ہے: نہ کوئی خرابی آتی ہے، نہ کوئی ایٹریبیوٹ بنتا ہے۔ پہلے اسکیما پڑھیں اور 2xx اسٹیٹس پر بھروسہ کرنے کے بجائے رائٹ کی تصدیق کریں۔

کیا Brevo API میں بلک ڈیلیٹ موجود ہے?

company جیسے Brevo کے معیاری آبجیکٹ ٹائپس کے لیے نہیں۔ بیچ ڈیلیٹ روٹ ان کے لیے 403 واپس دیتا ہے، اس لیے صفائی DELETE /v3/companies/{id} کے ذریعے فی کال ایک ریکارڈ کے حساب سے چلتی ہے۔ بلک صفائی کا منصوبہ منٹوں میں نہیں، گھنٹوں میں بنائیں۔

یہ مضمون شیئر کریں:

تمام مضامین پر واپس جائیں

business-tools

ویب پش نوٹیفکیشنز: یہ کیسے کام کرتی ہیں اور انہیں درست طریقے سے کیسے استعمال کریں

19 اگست، 2026