תיעוד ה-API של בול

כתובת בסיס ואימות

כתובת הבסיס: https://bul.friman.app/v1. כל בקשה צריכה כותרת Authorization: Bearer <API key>. את המפתח יוצרים בדשבורד, והוא מוצג פעם אחת בלבד.

סוגי מפתחות: read קריאה בלבד · send שליחה וקריאה · full הכול, כולל ניהול דומיינים ו-webhooks.

Idempotency-Key (חובה ב-POST /v1/emails, /batch, /campaigns): מחרוזת ייחודית לכל בקשה, למשל UUID. בקשה חוזרת עם אותו מפתח מחזירה את התשובה המקורית ולא שולחת שוב. מפתח תקף 30 יום; אחרי זה הוא נמחק, ובקשה עם אותו ערך תיחשב בקשה חדשה ותישלח.

שמות שדות: הצורה הראשית היא snake_case — בבקשות, בתשובות ובאירועים (message_id, reply_to, created_at). בכמה תשובות ישנות מוחזר גם השם הקודם ב-camelCase, לתאימות לאחור בלבד.

נקודות קצה

בדיקת בריאות: GET /v1/status

עובד עם כל סוג מפתח, ונספר במכסת הקצב כמו כל בקשה.

GET /v1/status
{
  "key": { "name": "שרת הייצור", "scope": "send" },
  "sending": { "status": "open", "reason": null,     // open | blocked, ו-reason בעברית כשיש סיבה
               "reputation_warning": false },        // true = עבר סף אזהרה, השליחה עדיין פתוחה
  "rate_limit": { "limit": 120, "remaining": 117, "reset_seconds": 42 },
  "domains": [ { "domain": "yourdomain.co.il", "status": "verified" } ],  // verified | pending | failed
  "queue_processing": true,  // false = הודעות מתקבלות אבל השליחה או עדכוני הסטטוס מתעכבים אצלנו
  "compliance": { "unsubscribe": null }  // או { "level": "warning" | "strong", "reason": "...", "detected_at": "..." }
}

שליחה: שדות

POST /v1/emails
{
  "from": "Acme <news@yourdomain.co.il>",   // חובה. מדומיין מאומת בחשבון (או תת-דומיין שלו)
  "to": ["dana@example.com"],               // חובה. מערך. /emails: 1, /batch: עד 100, /campaigns: עד 10,000
  "subject": "שלום",                         // חובה
  "html": "<p>...</p>",                      // html או text (או שניהם) — חובה לפחות אחד
  "text": "גרסת טקסט רגיל",                   // אופציונלי
  "track_clicks": true,                     // אופציונלי, ברירת מחדל true. false = קישורים ישירים, בלי עטיפת מעקב
  "kind": "transactional",                  // transactional | marketing. ברירת מחדל: transactional (בקמפיין: marketing)
  "reply_to": ["support@yourdomain.co.il"], // אופציונלי. מחרוזת או מערך, עד 5 כתובות
  "headers": { "X-Order-Id": "1234" },      // אופציונלי. רק כותרות X-*, עד 20
  "tags": { "order_id": "1234" },           // אופציונלי. חוזרים בכל webhook, ב-GET וב-/v1/events
  "attachments": [ ... ]                    // אופציונלי. ראו למטה
}

202 Accepted
{ "id": "uuid", "recipient": "dana@example.com" }

tags: עד 10 זוגות של מפתח וערך. מפתח: אותיות באנגלית, ספרות, _ ו--, עד 64 תווים. ערך: מחרוזת עד 256 תווים. הם לא משפיעים על השליחה — רק חוזרים אליכם עם כל אירוע של ההודעה.

track_clicks: כש-false, הקישורים במייל נשלחים כמו שהם — בלי עטיפה בדומיין המעקב (ולכן גם בלי אירועי clicked להודעה הזו). track_opens עוד לא נתמך — שליחתו מחזירה 422 not_supported.

שמות שדות: מתקבלים גם ב-snake_case וגם ב-camelCase: reply_to / replyTo, track_clicks / trackClicks, content_type / contentType, content_id / contentId. שדה לא מוכר (למשל cc, bcc, שעוד לא נתמכים) מחזיר 422 unknown_fields עם רשימת השדות — הוא לא מתעלם בשקט.

marketing: כל מייל שיווקי מקבל אוטומטית את הכותרות List-Unsubscribe ו-List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058). ביטול הרשמה מכניס את הנמען לרשימת החסימה ושולח webhook בשם unsubscribed.

headers: שם הכותרת חייב להתחיל ב-X- (אותיות, ספרות ומקף, עד 64 תווים). כותרות סטנדרטיות (From, To, Subject, Reply-To, List-Unsubscribe וכו') נקבעות על ידינו ואי אפשר לדרוס אותן. כמה קידומות X- שמורות למערכת — שם כזה יוחזר עם 400 invalid_headers והסבר. ערך: מחרוזת עד 998 תווים, בלי ירידות שורה.

מקבץ: POST /v1/emails/batch

צורה 1 — אותו מייל לכמה נמענים (אובייקט): כמו /v1/emails, עם to של עד 100 כתובות. התשובה: { "queued": [{ "id", "recipient" }], "suppressed": [...], "invalid": [...] } — כתובות לא תקינות (למשל בלי @ או בלי דומיין) לא נשלחות ומוחזרות ב-invalid, והשאר נשלחים. אותו דבר בקמפיין.

צורה 2 — עד 100 הודעות שונות (מערך): כל פריט הוא הודעה מלאה עם נמען אחד — from, to, subject, html/text, reply_to, headers, attachments, kind, track_clicks, tags, ו-idempotency_key אופציונלי לכל הודעה.

POST /v1/emails/batch                    // ברירת מחדל: mode=partial
Idempotency-Key: 6f1c...                 // אחד לכל הבקשה (חובה)
[
  { "from": "Acme <hi@yourdomain.co.il>", "to": "dana@example.com",
    "subject": "החשבונית שלך", "html": "<p>שלום דנה</p>",
    "idempotency_key": "invoice-1001",     // אופציונלי — מונע שליחה כפולה של ההודעה הזו גם בבקשה אחרת
    "tags": { "invoice": "1001" },
    "attachments": [{ "filename": "terms.pdf", "url": "https://files.example.com/terms.pdf" }] },
  { "from": "Acme <hi@yourdomain.co.il>", "to": "yossi@example.com",
    "subject": "החשבונית שלך", "text": "שלום יוסי", "idempotency_key": "invoice-1002" },
  { "from": "Acme <hi@unknown-domain.com>", "to": "rina@example.com",
    "subject": "החשבונית שלך", "text": "שלום רינה" }
]

202 Accepted
{ "data": [
    { "index": 0, "id": "uuid", "recipient": "dana@example.com" },
    { "index": 1, "id": "uuid", "recipient": "yossi@example.com", "deduplicated": true },
    { "index": 2, "recipient": "rina@example.com",
      "error": { "code": "unverified_from_domain", "message": "..." } } ],
  "summary": { "queued": 1, "deduplicated": 1, "failed": 1 } }

• mode=partial (ברירת המחדל): תוצאה נפרדת לכל הודעה. פריט פסול, נמען ברשימת החסימה או כפילות של idempotency_key באותה בקשה — מקבלים error, וכל השאר נשלחים. 202 אם התקבלה לפחות הודעה אחת; 422 no_items_accepted (עם data) אם אף אחת.
• mode=atomic (?mode=atomic): הכל או כלום — פריט פסול אחד דוחה את כל הבקשה ושום הודעה לא נשמרת: 422 { "error": { "code": "invalid_batch_item", "index": 3, "item_error": { "code", "message" } } }. נמען ברשימת החסימה אינו "פסול" גם כאן — הוא מסומן ב-error.code: "suppressed" והשאר נשלחים.
• idempotency_key לכל הודעה (עד 256 תווים, תקף 30 יום): הודעה שכבר התקבלה עם אותו מפתח — גם בבקשה קודמת עם Idempotency-Key אחר — מוחזרת עם ה-id המקורי ו-deduplicated: true, ולא נשלחת שוב. כך אפשר לשלוח מחדש מקבץ שנכשל חלקית בלי לשלוח פעמיים את מה שכבר יצא.
• Idempotency-Key של הבקשה: בקשה חוזרת עם אותו מפתח מחזירה את אותה תשובה בדיוק (כולל השגיאות).
• קובץ זהה שמופיע בכמה פריטים נשמר אצלנו פעם אחת.
• המקבץ נספר כבקשה אחת במכסת הקצב; השליחה בפועל יוצאת מהתור בקצב של המערכת.

רשימת החסימה: /v1/suppressions

GET /v1/suppressions?limit=100&offset=0
200 { "data": [{ "id": "uuid", "recipient": "dana@example.com", "reason": "unsubscribe",
                 "source": "...", "created_at": "2026-10-04T12:00:00.000Z" }],
      "total": 1, "limit": 100, "offset": 0 }

POST /v1/suppressions
{ "recipient": "dana@example.com", "reason": "manual" }   // reason אופציונלי, ברירת מחדל manual
201 { "id": "uuid", "recipient": "dana@example.com", "reason": "manual", ... }
200 { "recipient": "dana@example.com", "already_suppressed": true }   // כבר ברשימה

POST /v1/suppressions/import                            // ייבוא מרוכז, עד 10,000 כתובות
{ "recipients": ["a@example.com", "b@example.com"], "reason": "manual" }
200 { "added": 2, "already_suppressed": 0, "invalid": [] }   // לא תקינות לא עוצרות את הייבוא

DELETE /v1/suppressions/{id או כתובת}   // מפתח full בלבד
204 (נמחק) | 404 not_found

כתובות נכנסות לרשימה גם אוטומטית: החזרה קבועה (hard_bounce), תלונת ספאם (complaint) וביטול הרשמה (unsubscribe).

סטטיסטיקה: GET /v1/stats

200 { "sent": 120, "delivered": 118, "bounced": 1, "complained": 0,
      "opened": 95, "clicked": 30,
      "unique_opens": 61, "unique_clicks": 22,
      "human_opens": 52, "unique_human_opens": 34 }

opened ו-clicked סופרים אירועים, לא נמענים: נמען שפתח מייל שלוש פעמים נספר שלוש פעמים. unique_opens ו-unique_clicks סופרים הודעות שנפתחו / שנלחץ בהן לפחות פעם אחת.

המונים כוללים גם אירועים מעל 90 יום, שנשמרים כסיכום יומי (ראו שמירת נתונים). בחלק המסוכם, הודעה שנפתחה בשני ימים שונים נספרת ב-unique_opens פעמיים.

human_opens / unique_human_opens — אותו דבר בלי פתיחות שסומנו אוטומטיות (ראו פתיחות אוטומטיות). זו הערכה; opened נשאר הסך הכולל.

פתיחות אוטומטיות: machine_open

חלק מאירועי opened הם לא אדם שפתח את המייל, אלא מכונה שטענה את התמונות. בול מסמן כל פתיחה כזו — ב-webhook וב-GET /v1/events:

{ "event": "opened", ..., "machine_open": true, "machine_open_reason": "apple_mpp" }

בעלי ה-IP: ב-fast_open וב-scanner נוסף אחרי נקודתיים מי מחזיק בכתובת ה-IP שטענה את הפיקסל, כשהוא מזוהה (לפי ASN): fast_open:google, fast_open:netfree, fast_open:israeli_filter, fast_open:israeli_isp, scanner:security_vendor, fast_open:cloud, ‏microsoft, ‏yahoo. החלק שלפני הנקודתיים הוא תמיד הכלל. הזיהוי לפי ASN (נשלחת רק כתובת ה-IP — ראו מדיניות הפרטיות).

מגבלות: זו הערכה, לא עובדה. (1) כל משתמשי Apple Mail עם ההגנה נראים "אוטומטיים" — גם אם בנוסף פתחו בפועל; הפתיחה האמיתית שלהם עוברת דרך אותו פרוקסי ולא ניתנת להבחנה. (2) Gmail שומר את התמונה אחרי הטעינה הראשונה, כך שפתיחות חוזרות ב-Gmail לא נספרות בכלל. (3) סורק שמתחזה לדפדפן רגיל ומחכה יותר מ-10 שניות ייחשב אנושי. (4) זמן המסירה נלקח מאירוע delivered; כשהוא עוד לא הגיע, כללי הזמן לא חלים. (5) פתיחות מלפני 2026-10-06 סווגו בדיעבד לפי User-Agent וזמן בלבד. האירוע עצמו נשלח תמיד — machine_open רק מסמן אותו. לקהל עם הרבה משתמשי iPhone/Mac, clicked הוא מדד אמין יותר.

קמפיין גדול: יותר מ-10,000 נמענים

POST /v1/campaigns מקבל עד 10,000 נמענים. לקמפיין גדול יותר — יוצרים אותו עם הקבוצה הראשונה, ומוסיפים את השאר בבקשות של עד 10,000:

POST /v1/campaigns/{id}/recipients
Idempotency-Key: <מפתח ייחודי לכל בקשה>
{ "to": ["dana@example.com", "..."] }

202 { "id": "...", "status": "sending", "added": 9998, "duplicates": ["avi@example.com"],
      "suppressed": ["x@example.com"], "invalid": [], "total": 19999 }

התוכן (שולח, נושא, HTML, טקסט, קבצים, Reply-To, כותרות, tags) — של הקמפיין; בבקשה הזו רק to. בלי כפילויות: נמען שכבר בקמפיין (מבקשה קודמת או פעמיים באותה בקשה) לא מקבל שוב ומופיע ב-duplicates — גם כששתי בקשות רצות במקביל. Idempotency-Key לכל בקשה: ניסיון חוזר עם אותו מפתח מחזיר את אותה תשובה ולא מוסיף שוב. קמפיין שסיים לשלוח חוזר ל-sending; halted → ‏409 campaign_halted; תוכן שנמחק (30 יום) → ‏409 campaign_content_unavailable.

קמפיינים: תור הוגן וזמן משוער לסיום (ETA)

התור של בול מחלק את הקיבולת בין לקוחות ובין קמפיינים לסירוגין, לא לפי סדר ההגעה — קמפיין גדול של לקוח אחד לא מעכב אחרים. החלוקה לפי היקף העבודה: גם הגודל של כל הודעה, לא רק מספר ההודעות. הודעות בודדות (POST /v1/emails, טרנזקציוני) לא מחכות לקמפיינים.

priority ב-POST /v1/campaigns: "normal" (ברירת מחדל) או "low" — קמפיין בעדיפות נמוכה מקבל חלק קטן יותר מהקיבולת של החשבון, אבל תמיד מתקדם. GET /v1/campaigns מחזיר את הקמפיינים האחרונים (?limit= עד 100, ?status=).

"eta": {
  "state": "sending",                       // sending | paused | done
  "remaining_messages": 8400, "remaining_bytes": 512000000,
  "rate_per_minute": 410,
  "estimated_completion_at": "2026-10-08T09:40:00Z",
  "earliest_completion_at": "2026-10-08T09:31:00Z",
  "latest_completion_at": "2026-10-08T09:55:00Z",
  "confidence": "medium",                   // high | medium | low
  "basis": "observed",                      // observed (קצב בפועל) | fair_share (תחילת קמפיין)
  "reason": null,                           // campaign_paused | campaign_halted | account_paused | recipient_provider_slowdown | waiting_for_capacity
  "updated_at": "2026-10-08T09:12:03Z"
}

ETA הוא הערכה שמתעדכנת, לא הבטחת זמן: זמן השליחה מבול, לא זמן ההגעה לתיבה. הוא מחושב מהכמות שנשארה, מהגודל שלה, מהקצב בפועל ומהאטות אצל ספקי הדואר של הנמענים. כשאין מספיק נתונים — הטווח רחב יותר.

אזהרות בתשובה: קבצים כבדים (attachment_delivery_risk)

קבצים מצורפים גדלים בכשליש בקידוד (base64): קובץ של 25MB הוא כ-36MB בהודעה. כשההודעה מעל כ-25MB אחרי הקידוד, התשובה ל-/v1/emails, ‏/v1/emails/batch, ‏/v1/campaigns ו-/v1/campaigns/{id}/recipients כוללת אזהרה. Gmail ו-Outlook.com קיבלו עד כ-36MB אחרי קידוד בבדיקות שלנו; שאר הספקים (Yahoo, ארגונים ב-Microsoft 365, ספקים ישראליים ושרתים אחרים) — כ-25MB לפי מה שהם מפרסמים. לא חוסם — ההודעה נשלחת כרגיל.

"warnings": [ { "code": "attachment_delivery_risk", "message": "...",
  "encoded_bytes": 29360128, "recipients_at_risk": 120, "recipients_total": 4000,
  "limits": { "measured_providers_bytes": 37748736, "other_providers_bytes": 26214400 } } ]

recipients_at_risk — כמה נמענים בבקשה אצל ספקים שעלולים לדחות הודעה בגודל הזה (מעל כ-36MB — כולם). לקבצים כבדים לרשימה גדולה — עדיף קישור להורדה.

אזהרות בתשובה: warnings (קטיעה ב-Gmail)

Gmail קוטע הודעה שה-HTML שלה מעל כ-102KB: מציג "[ההודעה נקטעה]", ומה שבסוף — בדרך כלל הפוטר וקישור ההסרה — לא מוצג בלי לחיצה. כשה-HTML מעל 102,000 בייט (אחרי עטיפת הקישורים למעקב), התשובה ל-POST /v1/emails, ל-/v1/emails/batch (לכל פריט) ול-/v1/campaigns כוללת אזהרה. ההודעה נשלחת כרגיל — זו לא חסימה.

202 { "id": "...", "recipient": "dana@example.com",
      "warnings": [ { "code": "gmail_clipping", "message": "...", "html_bytes": 118342, "limit_bytes": 102000 } ] }

פיקסל הפתיחה של בול ממוקם בתחילת ה-<body>, כך שגם הודעה שנקטעה נספרת כשהיא נפתחת. הוא מוגש בלי מטמון (Cache-Control: no-store, no-cache, max-age=0, ‏Expires: 0), כך שפתיחה אמיתית אחרי טעינה מוקדמת נספרת שוב. כדי לקצר: להסיר CSS ותגובות שלא בשימוש, ולהקטין טבלאות מקוננות. עברית היא 2 בייט לאות.

קבצים מצורפים

"attachments": [
  { "filename": "invoice.pdf", "content_type": "application/pdf",
    "content": "<base64>" },                                   // תוכן ב-base64
  { "filename": "report.pdf",
    "url": "https://files.example.com/report.pdf" },           // או: נוריד אותו בעצמנו (https בלבד)
  { "filename": "logo.png", "content_type": "image/png",
    "content": "<base64>", "content_id": "logo@acme" }        // תמונה בגוף ההודעה: <img src="cid:logo@acme">
]

עד 10 קבצים ועד 25MB יחד להודעה (קבצים אמיתיים, לא קישורים). בכל קובץ: content או url, לא שניהם. content_type חובה עם content. ב-url הוא נלקח מהשרת אם לא נשלח. בקמפיין הקבצים נשמרים אצלנו פעם אחת ומשותפים לכל הנמענים. הצורה הישנה "attachment": { ... } (קובץ אחד) עדיין נתמכת.

שגיאות

כל שגיאה מוחזרת באותו מבנה: { "error": { "code": "...", "message": "..." } }. ההודעה בעברית; הקוד קבוע — כדאי להסתמך עליו.

Webhooks

אירועים: delivered, opened, clicked, bounced (החזרה קבועה), deferred (החזרה זמנית), complained, unsubscribed, failed, withdrawn (הודעה שהוחזרה אליכם לפני ניסיון מסירה — ראו עצירת מסלול), stuck (הודעה שנתקעה בשליחה). queued ו-sent מתקבלים בהרשמה, אבל כרגע לא נשלחים.

אירועי חשבון (לא של הודעה בודדת, ולכן בלי message_id): reputation.warning — שיעור ההחזרות או התלונות עבר את סף האזהרה, השליחה ממשיכה; reputation.paused — השליחה נעצרה אוטומטית; compliance.unsubscribe_missing — נראה שנשלח דיוור בלי אפשרות הסרה. צריך להירשם אליהם במפורש. פרטים במוניטין ועצירה אוטומטית ובדיוור בלי הסרה.

ניהול endpoints (יצירה ומחיקה — מפתח full; רשימה ושליפה — כל מפתח). אותם שדות בכל התשובות; signing_secret מוחזר רק ביצירה, פעם אחת.

POST /v1/webhooks
{ "url": "https://example.com/bul-webhook", "events": ["delivered", "bounced"] }
201 { "id": "uuid", "url": "...", "events": ["delivered", "bounced"], "active": true,
      "created_at": "...", "signing_secret": "whsec_..." }
      // לתאימות לאחור מוחזרים גם subscribedEvents, signingSecret, createdAt — אותו ערך, שם ישן

GET /v1/webhooks          200 { "data": [{ "id", "url", "events", "active", "created_at" }] }
GET /v1/webhooks/{id}     200 { "id", "url", "events", "active", "created_at" }
DELETE /v1/webhooks/{id}  204

POST <your-url>
Content-Type: application/json
Bul-Event: bounced
Bul-Event-Id: 6167e99d-...        // קבוע בין ניסיונות חוזרים — לזיהוי כפילויות
Bul-Timestamp: 1790000000         // שניות מאז 1970
Bul-Signature: <hex>

{ "event": "bounced", "event_id": "uuid", "message_id": "...", "recipient": "dana@example.com",
  "campaign_id": null, "timestamp": "2026-10-04T12:00:00.000Z", "tags": { "invoice": "1001" },
  "bounce_type": "hard", "bounce_sub_type": "General",
  "smtp_status": "5.1.1", "smtp_diagnostic": "smtp; 550 5.1.1 user unknown" }

מבנה האירוע לכל סוג: כל אירוע של הודעה כולל תמיד את השדות המשותפים, ועוד שדות לפי הסוג.

timestamp הוא זמן האירוע. tags הוא תמיד אובייקט ({} כשלא נשלחו).

סינון כפילויות — לפי event_id. יש שני מזהים:

• event_id (בגוף) — מזהה האירוע. זהה בכל מסירה של אותו אירוע, וזהה ל-id שמחזיר GET /v1/events. קיים בכל סוגי האירועים: לאירוע stuck הוא נגזר באופן יציב מההודעה (ולא מופיע ב-/v1/events, כי זה אירוע תפעולי שלנו); לאירועי reputation.* ולאירוע בדיקה — מזהה חדש לכל התראה.
• Bul-Event-Id (בכותרת) — מזהה המסירה. קבוע בין הניסיונות החוזרים, וגם ב"שלח שוב" מהדשבורד (זו אותה מסירה). אבל אם אותו אירוע נמסר בדרך אחרת (למשל שחזור שלנו אחרי תקלה) — הוא יגיע עם Bul-Event-Id אחר ואותו event_id.

ההמלצה: לשמור event_id שכבר טופל ולהתעלם מכפילות. כך מכוסים גם ניסיונות חוזרים, גם "שלח שוב", וגם אירוע שמגיע פעם ב-webhook ופעם דרך /v1/events.

אירוע בדיקה: POST /v1/webhooks/{id}/test (מפתח full), או הכפתור "שלח אירוע בדיקה" בדשבורד. נשלח מיד, חתום וכותרות כמו אירוע אמיתי, עם Bul-Event: test ובגוף "test": true. בלי ניסיונות חוזרים — התשובה מחזירה את התוצאה:

POST /v1/webhooks/{id}/test
200 { "delivery_id": "uuid", "event_id": "uuid", "delivered": true,
      "response_code": 200, "duration_ms": 184, "error": null }

// מה שהשרת שלכם מקבל:
Bul-Event: test
{ "event": "test", "test": true, "event_id": "uuid", "message_id": null, "recipient": null,
  "campaign_id": null, "timestamp": "2026-10-05T12:00:00.000Z", "tags": {}, "message": "אירוע בדיקה מבול — אפשר להתעלם..." }

אירוע בדיקה לבחירה (2026-10-06): גוף אופציונלי — סוג אירוע ותוכן, כדי לבדוק את הכללים שלכם (חסימה, שליחה חוזרת) בלי החזרות אמיתיות. ה-payload באותו מבנה כמו אירוע אמיתי, עם "test": true, והכותרת Bul-Event היא הסוג שבחרתם. שדות: event (test, delivered, opened, clicked, bounced, deferred, complained, unsubscribed, failed, withdrawn, stuck, reputation.warning, reputation.paused, compliance.unsubscribe_missing), smtp_status, smtp_diagnostic, bounce_sub_type, reason_code (ל-failed/withdrawn), attempted (ל-withdrawn), recipient, message_id, tags.

POST /v1/webhooks/{id}/test   { "event": "bounced", "smtp_status": "5.1.1" }
POST /v1/webhooks/{id}/test   { "event": "bounced", "smtp_status": "5.7.1" }   // לבדיקת כללים; אצלנו בפועל 5.7.x מגיע כ-failed
POST /v1/webhooks/{id}/test   { "event": "failed", "reason_code": "rejected_policy" }
POST /v1/webhooks/{id}/test   { "event": "withdrawn", "attempted": false }

חתימה: Bul-Signature = HMAC-SHA256 (hex) של `${Bul-Timestamp}.${body}`, עם הסוד שקיבלתם ביצירת ה-webhook. לאמת על הגוף הגולמי (לפני JSON.parse), להשוות בזמן קבוע, ולדחות timestamp ישן מ-5 דקות.

import { createHmac, timingSafeEqual } from "node:crypto";

function verify(rawBody, headers, secret) {
  const ts = headers["bul-timestamp"];
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
  const expected = createHmac("sha256", secret).update(`${ts}.${rawBody}`).digest("hex");
  const got = headers["bul-signature"] ?? "";
  return got.length === expected.length && timingSafeEqual(Buffer.from(got), Buffer.from(expected));
}

ניסיונות חוזרים: תשובה שאינה 2xx (או זמן תגובה מעל 5 שניות) — עד 8 ניסיונות לאורך כ-22.5 שעות: מיד, ואחר כך אחרי דקה, 5 דקות, 30 דקות, שעה, 3 שעות, 6 שעות ו-12 שעות (כל מרווח נמדד מהניסיון הקודם). שרת שנפל לכמה שעות יקבל את האירועים כשיחזור. Bul-Event-Id זהה בכל הניסיונות — השתמשו בו לסינון כפילויות; Bul-Timestamp והחתימה מחושבים מחדש בכל ניסיון.

קצב: עד 10 בקשות בו-זמנית לכל כתובת יעד. תשובת 429 משהה את המסירה לכתובת הזו לפי Retry-After (שניות או תאריך; בלעדיו — 30 שניות), בלי לספור את הניסיון. גם ב-503 עם Retry-After הניסיון הבא נקבע לפיו.

אירועים שהוחמצו: GET /v1/events

אם השרת שלכם היה למטה מעבר ללוח הניסיונות, או שאתם רוצים לוודא שלא פספסתם כלום — שולפים את האירועים לפי סדר קבלתם אצלנו. כל אירוע באותו מבנה כמו ב-webhook, ו-id שלו = event_id שב-webhook.

GET /v1/events?since=2026-10-04T00:00:00Z&limit=100      // since: ברירת מחדל 24 שעות אחורה
GET /v1/events?cursor=<next_cursor>                      // העמוד הבא
GET /v1/events?type=bounced,complained                   // סינון לפי סוג

200 { "data": [
        { "id": "uuid", "event": "clicked", "message_id": "uuid", "recipient": "dana@example.com",
          "campaign_id": null, "timestamp": "2026-10-04T12:00:00.000Z",
          "received_at": "2026-10-04T12:00:00.642Z", "clicked_url": "https://...", "tags": {} } ],
      "has_more": true, "next_cursor": "eyJ..." }

limit עד 500 (ברירת מחדל 100). ממשיכים עם next_cursor כל עוד has_more. שמרו את ה-next_cursor האחרון — בפעם הבאה אפשר להמשיך ממנו, בלי חפיפה ובלי לפספס.

הודעה בודדת: GET /v1/emails/{id}

GET /v1/emails/{id}                 // ?include=html — גם html ו-text
200 { "id": "uuid", "recipient": "dana@example.com", "from": "Acme <hi@yourdomain.co.il>",
      "subject": "...", "status": "delivered", "attempts": 1, "campaign_id": null,
      "last_error": null, "created_at": "2026-10-04T12:00:00.000Z",
      "reply_to": [], "headers": {}, "track_clicks": true, "tags": { "invoice": "1001" },
      "attachments": [{ "filename": "terms.pdf", "content_type": "application/pdf", "size": 52311 }],
      "content_purged_at": null,
      "bounce": { "event": "bounced", "bounce_type": "hard", "bounce_sub_type": "NoEmail",
                  "smtp_status": "5.1.1", "smtp_diagnostic": "550 The email account ... does not exist", "timestamp": "..." } }

bounce — ההחזרה/הדחייה האחרונה עם פרטי SMTP (null כשאין).

content_purged_at — מתי נמחק התוכן לפי מדיניות השמירה (null = התוכן עדיין שמור). אחרי המחיקה html ו-text חוזרים null, ושאר השדות נשארים.

שמות ישנים (deprecated): לתאימות לאחור מוחזרים גם fromAddress, campaignId, lastError, createdAt, replyTo, trackClicks, ובקבצים contentType/contentId — אותו ערך, שם ישן. הכותרת Bul-Deprecated-Fields מפרטת אותם. הם יוסרו בעתיד — השתמשו בשמות ה-snake_case. אותו כלל ב-GET /v1/campaigns/{id} (sender, haltReason, createdAt), ב-GET /v1/domains/{id} (row, verification) וב-POST /v1/webhooks.

דומיינים: Cloudflare, הוספה אוטומטית ודומיין מעקב ממותג

חיבור Cloudflare. בדשבורד ← דומיינים ← "התחבר לקלאודפלייר". בול מבקשת רק קריאת zones וקריאה ועריכה של רשומות DNS (zone.read dns.read dns.write) — בלי גישה להגדרות אחרות, לחיוב או למשתמשים. בול מוסיפה רק את הרשומות שבכרטיס הדומיין, תמיד DNS only, ולא דורסת רשומות קיימות. אפשר לחבר כמה חשבונות, ולבחור לכל דומיין חשבון ו-zone. ניתוק בדשבורד מבטל את ההרשאה גם אצל Cloudflare.

הוספה אוטומטית (Domain Connect). אם ספק ה-DNS שלכם תומך בתקן Domain Connect ומכיר את התבנית של בול, הכפתור בכרטיס הדומיין שולח אתכם לאישור אצל הספק, והרשומות נוספות בלי העתקה. אחרת — העתקה ידנית או חיבור Cloudflare.

דומיין מעקב ממותג (אופציונלי). ברירת המחדל לכל החשבונות היא bulclick.friman.app, ולא צריך לעשות כלום. אפשר להעביר את הקישורים דרך שם משלכם, למשל click.example.co.il: בוחרים שם בכרטיס הדומיין (בול מציעה שם פנוי ולא נוגעת בשם תפוס, למשל links של ספק אחר), ומוסיפים CNAME אל bulclick.friman.app (DNS only). כשהסטטוס "פעיל" — הקישורים והפיקסל עוברים דרכו. כרגע חל על מיילים שיוצאים דרך Bul Delivery Network. מומלץ לקהל מסונן (למשל לקוחות NetFree): דומיין משלכם שאושר בסינון לא תלוי באישור של דומיין משותף. את הבקשה לאשר את הדומיין הממותג מגישים בעצמכם; bulclick.friman.app, ‏bultrack.friman.app ו-bul.friman.app — בול מבקשת לאשר.

עצירת מסלול: withdrawn ו-route_paused

חלק מהדואר יוצא דרך Bul Delivery Network. אם ספק דואר (למשל Gmail) מאט או חוסם אותו, השליחה דרכו נעצרת לחשבון שלכם אוטומטית, עד שבול מאשרים חידוש. מה שקורה בזמן העצירה (לפי הגדרת החשבון; ברירת המחדל — החזרה אליכם):

• הודעה שהתקבלה ולא נמסרה — חוזרת אליכם כאירוע withdrawn, ובטוח לשלוח אותה שוב (גם דרך ספק אחר). attempted: false — לא נוסתה בכלל; attempted: true — נוסתה וכל ניסיון נדחה במפורש (למשל 421). בלי פקיעה ובלי מעבר שקט לספק אחר.
• בקשה חדשה שהייתה יוצאת דרך Bul Delivery Network — נדחית מיד ב-409 route_paused, וכל הבקשה לא נקלטה (גם מקבץ וקמפיין). הודעות שיוצאות ממילא דרך ספק אחר — לא נחסמות.
• הודעה שתוצאתה לא ברורה (ייתכן שנמסרה — למשל החיבור נפל בסיום שליחת התוכן) — לא חוזרת: failed עם ambiguous_delivery ו-safe_to_resend: false.

// webhook
{ "event": "withdrawn", "event_id": "uuid", "message_id": "uuid", "recipient": "dana@gmail.com",
  "campaign_id": null, "timestamp": "2026-10-06T12:00:00.000Z", "tags": {},
  "reason": { "code": "route_paused", "description": "השליחה דרך Bul Delivery Network נעצרה..." },
  "attempted": false, "safe_to_resend": true }   // attempted: true — נוסתה ונדחתה במפורש

// POST /v1/emails בזמן עצירה
409 { "error": { "code": "route_paused", "message": "...", "safe_to_resend": true } }

נמען חדש (recipient_not_proven): המסירות הראשונות לנמען שעוד לא קיבל מכם דואר דרך Bul Delivery Network עוברות במסלול בדיקה. אם בחשבון שלכם המסלול הוא החזרה אליכם — ההודעה חוזרת כ-withdrawn עם reason.code: recipient_not_proven ו-safe_to_resend: true, ובקשה שכל הנמענים בה (עד 50) חדשים נדחית ב-409 route_paused עם reason_code: recipient_not_proven ורשימת recipients. שלחו אותה בספק שלכם. אחרי כמה מסירות נקיות הנמען מוכח וכבר לא חוזר.

חשבון בלי ספק חלופי (direct_unavailable): בחשבון שמוגדר כך, כל הודעה שלא יכולה לצאת דרך Bul Delivery Network (למשל נמען שאינו אצל ספק ישיר, או מעבר לתקרה היומית) חוזרת כ-withdrawn עם safe_to_resend: true והסיבה ב-detail; בקשה שכל ההודעות בה כאלה — 409 route_paused עם reason_code: direct_unavailable.

מעבר מ-Resend לבול

רוב הקוד נשאר: JSON דומה, Authorization: Bearer, ו-202 עם id. ההבדלים:

• כתובת: https://bul.friman.app/v1/emails במקום https://api.resend.com/emails.
• Idempotency-Key — חובה ב-POST ‏/v1/emails, ‏/batch, ‏/campaigns (ב-Resend אופציונלי).
• tags — אובייקט { name: value } במקום מערך [{ name, value }]. reply_to — מערך, עד 5.
• cc, ‏bcc, ‏scheduled_at — עוד לא נתמכים (422 unknown_fields); נמען נפרד לכל אחד ב-/v1/emails/batch.
• מקבץ: אותו מערך ב-POST /v1/emails/batch, עם idempotency_key לכל הודעה.
• webhooks: delivered, ‏bounced... במקום email.delivered, ‏email.bounced; חתימה ב-Bul-Signature (ראו Webhooks). שגיאה: { "error": { "code", "message" } }.

לפני:

import { Resend } from "resend";
const resend = new Resend(process.env.RESEND_API_KEY);
const { data, error } = await resend.emails.send({
  from: "Acme <hi@acme.co.il>", to: ["dana@example.com"], subject: "שלום", html: "<p>ההזמנה התקבלה</p>",
  tags: [{ name: "order_id", value: "1234" }],
});

אחרי:

const res = await fetch("https://bul.friman.app/v1/emails", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.BUL_API_KEY}`, "Content-Type": "application/json", "Idempotency-Key": "order-1234" },
  body: JSON.stringify({
    from: "Acme <hi@acme.co.il>", to: ["dana@example.com"], subject: "שלום", html: "<p>ההזמנה התקבלה</p>",
    tags: { order_id: "1234" },
  }),
});
const body = await res.json();
if (!res.ok) throw new Error(`${body.error.code}: ${body.error.message}`);
const { id } = body;

הרבה נמענים: עד 100 בבקשה ב-/v1/emails/batch, עד 10,000 ב-/v1/campaigns (ועוד 10,000 בכל בקשה ב-/v1/campaigns/{id}/recipients). לפני המעבר: הוסיפו את הדומיין בדשבורד ואמתו את רשומות ה-DNS.

ספריית JavaScript / TypeScript

ספרייה רשמית (TypeScript, Node 18+ / Bun / Deno / edge): כל נקודות הקצה, טיפוס לכל אירוע, אימות חתימת webhook, וניסיונות חוזרים בטוחים — שליחה מקבלת Idempotency-Key אחד לכל קריאה, שנשמר בכל ניסיון חוזר, כך שניסיון חוזר לא שולח פעמיים. 429 (לפי Retry-After), 5xx ושגיאות רשת — ניסיון חוזר; 409 route_paused — לא, אלא RoutePausedError עם returns.הספרייה עוד לא פורסמה ב-npm — זמינה לפי בקשה; השם הצפוי בפרסום: bul-email (בדוגמאות למטה).

import { Bul, RoutePausedError } from "bul-email";

const bul = new Bul({ apiKey: process.env.BUL_API_KEY! });

try {
  const { id } = await bul.emails.send({
    from: "Acme <hi@acme.co.il>", to: ["dana@example.com"],
    subject: "שלום", html: "<p>ההזמנה התקבלה</p>", tags: { order_id: "1234" },
  }, { idempotencyKey: "order-1234" });          // אופציונלי; בלי — UUID חדש לכל קריאה
} catch (e) {
  if (e instanceof RoutePausedError) {
    // שום הודעה לא נשלחה — שלחו בספק שלכם, ודווחו את התוצאה:
    for (const r of e.returns) {
      // ...send with your provider...
      await bul.recipients.proof({ return_ref: r.return_ref, recipient: r.recipient, provider: "resend",
        outcome: "delivered", occurred_at: new Date().toISOString() });
    }
  } else throw e;
}

// אירועים שהוחמצו
for await (const ev of bul.events.iterate({ since: "2026-10-01T00:00:00Z" })) {
  if (ev.event === "failed" && !ev.safe_to_resend) continue;   // ambiguous_delivery
}

// webhook (Express / Next.js / Bun) — על הגוף הגולמי
import { constructWebhookEvent, WebhookVerificationError } from "bul-email";

const raw = await request.text();
try {
  const event = await constructWebhookEvent({ rawBody: raw, headers: request.headers, secret: process.env.BUL_WEBHOOK_SECRET! });
  switch (event.event) {
    case "bounced":   /* event.smtp_status */ break;
    case "withdrawn": /* event.reason.code, event.return_ref */ break;
  }
} catch (e) {
  if (e instanceof WebhookVerificationError) return new Response("bad signature", { status: 400 });
  throw e;
}

שגיאות: BulError (‏status, ‏code, ‏details), ומתוכה AuthenticationError (401), PermissionError (403), RoutePausedError (409), AccountBlockedError (423), RateLimitError (429); ConnectionError — רשת / timeout אחרי כל הניסיונות.

החזרה ודיווח: return_ref ו-POST /v1/recipients/proof

כל הודעה שבול מחזירה אליכם — בתשובת 409 route_paused (גם כל פריט במקבץ) ובאירוע withdrawn — כוללת return_ref: מזהה ייחודי שבול שומרת יחד עם הנמען. ב-409 הוא ב-returns, פריט לכל נמען: { index, recipient, return_ref } (index — מיקום הפריט במקבץ, או הנמען בבקשה). ב-withdrawn — שדה return_ref באירוע. אחרי ששלחתם את ההודעה בספק שלכם — דווחו את התוצאה, וכך נמען חדש נהיה מוכח (אחרי 2 מסירות נקיות) ויוצא בהמשך דרך Bul Delivery Network.

POST /v1/recipients/proof        // מפתח send או full; החשבון צריך אישור לייבוא היסטוריה
{ "return_ref": "rr_…", "recipient": "dana@gmail.com", "provider": "resend",
  "outcome": "delivered",          // delivered | bounced | complained
  "occurred_at": "2026-10-06T12:00:00Z", "provider_message_id": "re_…" }

202 { "accepted": true, "return_ref": "rr_…", "outcome": "delivered", "duplicate": false }

• תוצאה אחת לכל return_ref. אותה תוצאה שוב — 202 עם duplicate: true. bounced / complained אחרי delivered — גוברים (202 עם superseded: "delivered"; ה-delivered כבר לא נספר). delivered אחרי bounced / complained, או bounced מול complained — סותר: נרשם אצלנו ונדחה ב-409 conflicting_outcome (עם current_outcome).
• delivered — נספר כמסירה נקייה. bounced / complained — מבטל את ההוכחה של הנמען וחוסם אותו מהשרת של בול (ההודעות אליו ימשיכו לחזור אליכם).
• 403 forbidden — מפתח read, או חשבון בלי אישור לייבוא היסטוריה. 422 invalid_return_ref — המזהה לא קיים בחשבון, או שאינו של הנמען הזה. 422 validation_error — שדה חסר או לא תקין (field).

סיבות כישלון (failed)

לכל אירוע failed (webhook ו-GET /v1/events) יש reason: { code, description } ו-safe_to_resend. הקודים:

קוד שלא מופיע כאן — unknown. אחרי ambiguous_delivery ייתכן שיגיע מאוחר יותר גם delivered.

שמירת נתונים

• תוכן ההודעה (html, text, ותוכן קבצים שנשלחו מוטבעים) — נמחק 30 יום אחרי השליחה. ההודעה עצמה נשארת: נמען, נושא, סטטוס, זמנים, תגיות ורשימת הקבצים (שם וגודל). ב-GET /v1/emails/{id} מופיע content_purged_at. אותו כלל ל-HTML של קמפיין, כשאין בו הודעות שעוד ממתינות.
• אירועים (GET /v1/events, ציר הזמן של הודעה) — נמחקים אחרי 90 יום. לפני המחיקה נשמר סיכום יומי לפי סוג אירוע, ו-GET /v1/stats ממשיך לספור אותם.
• רשימת החסימה — לא נמחקת, כדי לא לשלוח שוב למי שביקש להפסיק.
• קבצים מצורפים ששמורים אצלנו ומפתחות Idempotency-Key — 30 יום, כמו קודם.

צריכים את התוכן או את האירועים לאורך זמן? שמרו אותם אצלכם — דרך webhooks או GET /v1/events. המחיקה רצה אוטומטית פעם ביום. פרטים: מדיניות הפרטיות.

רשימת הודעות: GET /v1/emails

GET /v1/emails?recipient=dana@example.com
GET /v1/emails?status=bounced,failed&since=2026-10-01T00:00:00Z&until=2026-10-05T00:00:00Z
GET /v1/emails?campaign_id=uuid&limit=100&cursor=<next_cursor>

200 { "data": [
        { "id": "uuid", "recipient": "dana@example.com", "from": "Acme <hi@yourdomain.co.il>",
          "subject": "...", "status": "delivered", "attempts": 1, "campaign_id": null,
          "created_at": "2026-10-04T12:00:00.000Z", "last_error": null, "tags": {} } ],
      "has_more": false, "next_cursor": null }

מהחדשה לישנה. status: queued, sending, sent, delivered, opened, clicked, bounced, complained, unsubscribed, failed, deferred, withdrawn (אפשר כמה, מופרדים בפסיק). since/until — זמן יצירת ההודעה. limit עד 100 (ברירת מחדל 50).

שימוש ועלות: GET /v1/usage

GET /v1/usage
200 [ { "period_start": "2026-10-01T00:00:00.000Z", "period_end": "2026-11-01T00:00:00.000Z",
        "messages": 9614, "cost_usd": 24.31, "estimated": true,
        "tracked_messages": 9614, "untracked_messages": 0,
        "message_bytes": 199412345678, "attachment_bytes": 145000000000 } ]

GET /v1/usage?group=campaign
200 [ { "campaign_id": "uuid", "name": "...", "messages": 9614, "message_bytes": ..., "attachment_bytes": ...,
        "cost_usd": 24.31, "estimated": true } ]

עלות משוערת (לא חשבונית): לכל הודעה, ועוד לפי נפח ההודעה כפי שנשלחה — כולל קבצים בקידוד base64. הודעות מלפני תחילת מעקב העלויות (untracked_messages) מוערכות לפי הודעה בלבד.

מכסת קצב ומגבלות

120 בקשות בדקה לכל מפתח. בכל תשובה: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset (שניות עד איפוס). בחריגה: 429 עם Retry-After.

מגבלות נוספות: batch עד 100 נמענים · קמפיין עד 10,000 נמענים (יותר — לפצל) · קבצים: 10 / 25MB להודעה · tags: 10 · reply_to: 5 · headers: 20.

קצב היציאה בפועל: הבקשה חוזרת מיד (202), וההודעות יוצאות מהתור בקצב של כ-12 הודעות בשנייה לכל המערכת. קמפיין של 1,000 נמענים יוצא תוך כדקה וחצי, ושל 7,700 נמענים תוך כ-10 דקות. מיילים טרנזקציוניים (kind: "transactional", ברירת המחדל ב-/v1/emails) מקבלים עדיפות, ויוצאים מיד גם כשקמפיין גדול באמצע שליחה.

מוניטין ועצירה אוטומטית

בול מודדת על חלון נע של 24 שעות את שיעור ההחזרות הקבועות (hard bounce) ואת שיעור התלונות (סימון כספאם), מתוך ההודעות שנמסרו או חזרו. הבדיקה רצה עם כל החזרה או תלונה, וגם כל 10 דקות, כך שאזהרה נוצרת ונעלמת גם בלי אירוע חדש.

מדד החזרות ועצירה מופעלים רק מ-100 הודעות בחלון; מתחת לזה שיעור הוא רעש סטטיסטי. תלונה בודדת מזהירה גם בנפח קטן, אבל אף פעם לא עוצרת לבד.

באזהרה השליחה ממשיכה, ונשלחים: webhook reputation.warning, באנר בדשבורד, ומייל לבעל החשבון. גם GET /v1/status מחזיר sending.reputation_warning: true. התראה חוזרת נשלחת לכל היותר פעם ב-6 שעות. בעצירה נשלח webhook reputation.paused ומייל; בקשות שליחה חדשות מקבלות 423 sending_blocked, והודעות שכבר בתור נשארות בתור ולא יוצאות. חידוש השליחה ידני, אחרי בדיקה.

POST <your-url>
Bul-Event: reputation.warning

{ "event": "reputation.warning", "timestamp": "2026-10-04T12:00:00.000Z",
  "tenant_id": "...", "reasons": ["bounce_rate"],      // bounce_rate | complaint_rate
  "sending_status": "active",                          // active (warning) | paused (reputation.paused)
  "window_hours": 24, "volume": 1200, "bounced": 26, "complained": 0,
  "bounce_rate": 0.021667, "complaint_rate": 0,
  "thresholds": { "bounce_warning": 0.02, "bounce_pause": 0.03,
                  "complaint_warning": 0.0004, "complaint_pause": 0.0008,
                  "complaint_pause_min_count": 2 } }

דיוור בלי אפשרות הסרה

Gmail ו-Yahoo דורשים מדיוור כותרת ביטול הרשמה בלחיצה אחת, ומעל 5,000 הודעות ביום ל-Gmail זו חובה. בול מוסיפה את הכותרת להודעות שיווקיות בלבד (kind: "marketing" וקמפיינים). הודעה שנשלחת כטרנזקציונית (ברירת המחדל ב-/v1/emails) יוצאת בלי הכותרת, וזה נכון לאיפוס סיסמה או קבלה — לא לדיוור.

מתי מתריעים: מקבץ או קמפיין של 20 נמענים ומעלה עם אותו תוכן, כטרנזקציוני ובלי קישור הסרה בגוף; אותה הודעה ל-200 נמענים ומעלה ב-24 שעות כטרנזקציונית ובלי קישור הסרה (אזהרה). מעל 5,000 הודעות ל-Gmail ב-24 שעות בלי כותרת הסרה — התראה חזקה. ההתראה מופיעה כבאנר בדשבורד, ב-GET /v1/status תחת compliance.unsubscribe, וב-webhook compliance.unsubscribe_missing (לכל היותר פעם ב-24 שעות לכל רמה). היא יורדת לבד אחרי 24 שעות בלי זיהוי חדש. השליחה עצמה לא נחסמת.

מה לעשות: לשלוח דיוור עם kind: "marketing", או להוסיף קישור הסרה לגוף. בהגדרות החשבון אפשר להפעיל "שיווקי כברירת מחדל" (הודעה בלי kind תיחשב דיוור, חוץ ממה שמסומן "transactional"), ו"שורת הסרה אוטומטית" (שורה קטנה עם קישור הסרה בתחתית הודעה שיווקית שאין בה קישור כזה). שתיהן כבויות כברירת מחדל.

POST <your-url>
Bul-Event: compliance.unsubscribe_missing

{ "event": "compliance.unsubscribe_missing", "event_id": "uuid", "timestamp": "2026-10-05T12:00:00.000Z",
  "level": "warning",                                   // warning | strong
  "reason": "מקבץ של 300 נמענים עם אותו תוכן נשלח כטרנזקציוני, בלי קישור הסרה...",
  "source": "batch", "recipients": 300, "subject": "מבצע סוף העונה" }