מעבר מ-Resend לבול בחמש דקות

1. דומיין

מוסיפים את הדומיין בבול (דשבורד ← דומיינים, או POST /domains) ומעתיקים את הרשומות ל-DNS. הרשומות שונות מאלה של Resend — אפשר להשאיר את הישנות עד שהמעבר נגמר.

2. שני משתני סביבה — בלי לגעת בקוד

Node (resend):

RESEND_API_KEY=bul_live_xxxxxxxx
RESEND_BASE_URL=https://bulapi.friman.app

או בקוד: new Resend(process.env.BUL_API_KEY, { baseUrl: "https://bulapi.friman.app" }).

Python (resend):

RESEND_API_KEY=bul_live_xxxxxxxx
RESEND_API_URL=https://bulapi.friman.app

HTTP ישיר: אותם נתיבים (POST /emails, POST /emails/batch …), רק הכתובת https://bulapi.friman.app.

3. Webhooks

יוצרים webhook בבול (resend.webhooks.create({ endpoint, events })) ומחליפים את הסוד (whsec_…) בקוד שמאמת. הגוף והחתימה באותו פורמט (svix-id / svix-timestamp / svix-signature) — resend.webhooks.verify והספרייה של Svix עובדות כמו שהן.

4. מה עובד כמו ב-Resend

• to (עד 50), cc, bcc — מזהה אחד לאימייל. בפנים בול שולחת עותק לכל נמען (מעקב, הסרה ומוניטין לכל נמען); bcc לא נחשף לאף אחד. כל נמען נספר כהודעה אחת במכסה.
• נמען ברשימת החסימה — הבקשה מצליחה, לא נשלח אליו כלום, ואירוע email.suppressed.
• In-Reply-To / References ב-headers; שאר הכותרות המותאמות — X-*.
• message_id ב-GET וב-webhooks — ה-Message-ID האמיתי שהנמען רואה.
• Idempotency-Key — 24 שעות. קבצים — עד 40MB להודעה אחרי base64 (בחבילה החינמית — בלי קבצים מצורפים).
• שגיאות ו-429 במבנה של Resend, כותרות ratelimit-* ו-retry-after. עד 10 בקשות בשנייה לחשבון.

5. מה שונה בבול

• חסימות: כתובת שלא קיימת, תלונה או הסרה של הנמען — לא נמחקות. אפשר למחוק רק חסימה שהוספת בעצמך.
• קצב בקשות — לכל חשבון (ratelimit-limit בכל תשובה). כמה הודעות יוצאות בפועל נקבע לפי החבילה, המכסה היומית והחודשית ושלב החשבון.
• עוד לא נתמך (תשובה 422 ברורה, לא כישלון שקט): scheduled_at, תבניות, topic_id, אנשי קשר ו-Broadcasts.
• הגנות בול — מכסות לפי שלב החשבון, מפסק מוניטין, הקפאה — חלות גם כאן.