API לשליחת SMS
ודיוור אלקטרוני

שלבו שליחת SMS ומייל ישירות מהמערכות שלכם REST JSON ו-SOAP API, תיעוד מלא בעברית.

שני ה-API שלנו, שרת ה-MCP ו-Zapier

תכונות ה-API

כותרת User-Agent בבקשות ל-API

הדומיינים שמשרתים את ה-API נמצאים מאחורי Cloudflare עם Browser Integrity Check פעיל. הבדיקה מסתכלת על כותרות ה-HTTP של הבקשה, וכותרת ה-User-Agent היא הפרמטר הקובע. שתי בקשות זהות לחלוטין באותו IP, host, path, query string ומתודה יכולות לקבל תשובות שונות אם ה-User-Agent שונה.

הנחסמות הן חתימות ברירת המחדל של ספריות HTTP שאינן מגדירות כותרת משלהן. בצד הלקוח התופעה נראית לסירוגין, כי בדרך כלל קיימים באותה מערכת שני נתיבי קוד לאותו endpoint, אחד שמגדיר User-Agent ואחד שלא. השגיאות שמתקבלות הן 403, error code 1010, או בפייתון urlopen error [WinError 10054] An existing connection was forcibly closed by the remote host.

הגדרת User-Agent מפורש בבקשה פותרת:

// Java
HttpURLConnection c = (HttpURLConnection) url.openConnection();
c.setRequestProperty("User-Agent", "myapp/1.0");

# Python (requests)
requests.post(url, json=payload, headers={"User-Agent": "myapp/1.0"})

# Python (urllib)
req = urllib.request.Request(url, data=body,
        headers={"User-Agent": "myapp/1.0", "ApiKey": key})

# curl
curl -H "User-Agent: myapp/1.0" -H "ApiKey: ..." ...

הערך עצמו אינו חשוב. כל מחרוזת שאינה חתימת ברירת מחדל של ספריית HTTP מתקבלת.

פורמט תאריך ושעה בתשובות ה-API

כל שדות התאריך והשעה שה-API מחזיר, בשני ה-API כאחד, הם בפורמט ISO 8601 ללא ציון אזור זמן. לדוגמה: 2026-09-19T16:47:00. הערך הוא תמיד שעון ישראל, כולל המעבר לשעון קיץ ובחזרה.

זה נכון לכל שדה תאריך בתשובות, ובכלל זה send_date, window_from ו-window_to.

המשמעות המעשית: מערכת שמפענחת את הערך בסביבה שאזור הזמן שלה אינו ישראל תקבל שעה מוזזת, בלי הודעת שגיאה. הבקשה תצליח והנתון יהיה שגוי. לכן יש לפרש את הערך מפורשות כ-Asia/Jerusalem ולהמיר משם.

# Python
from datetime import datetime
from zoneinfo import ZoneInfo
dt = datetime.fromisoformat("2026-09-19T16:47:00").replace(
        tzinfo=ZoneInfo("Asia/Jerusalem"))
utc = dt.astimezone(ZoneInfo("UTC"))

// C#
var tz  = TimeZoneInfo.FindSystemTimeZoneById("Israel Standard Time");
var loc = DateTime.Parse("2026-09-19T16:47:00");
var utc = TimeZoneInfo.ConvertTimeToUtc(
            DateTime.SpecifyKind(loc, DateTimeKind.Unspecified), tz);

// JavaScript (Luxon)
DateTime.fromISO("2026-09-19T16:47:00", { zone: "Asia/Jerusalem" }).toUTC();

פורמט הזמן בתשובות ה-API נשאר ללא שינוי כדי לשמור על תאימות לאחור עם מערכות שכבר מפענחות אותו. באינטגרציות המנוהלות שלנו הנרמול נעשה בצד האינטגרציה, כך שהלקוח מקבל ערך עם אזור זמן מפורש בלי שנדרש שינוי ב-API.

אימות שם שולח לפני שליחת SMS

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

כל עוד שם השולח אינו מאומת, קריאת שליחת SMS נכשלת ומחזירה:

{ "ErrorCode": 4,
  "Message": "The SMS sender identity is not verified" }

שימו לב ל-ErrorCode 4. אותו ערך מוחזר גם במצב אחר לגמרי: בקריאת CreateContact הוא מציין שרשימת התפוצה המבוקשת אינה קיימת. ה-API אינו יוצר רשימות. לכן אין להסתמך על הקוד בלבד כדי להחליט מה קרה, אלא לבדוק גם את שדה ההודעה:

# ErrorCode 4 by call
SendSMS-family   -> sender identity is not verified
CreateContact    -> the requested contact list does not exist

כדי לאמת שם שולח נדרשת הזדהות חזקה מול משרד התקשורת: שיחת וידאו ושתי תעודות מזהות. הפירוט המלא, ומה בדיוק להכין, נמצא בעמוד אימות שם שולח טקסטואלי. האישור ניתן באותו יום. השימוש הנפוץ ביותר בשם שולח מאושר הוא שליחת קוד אימות, ולזה יש עמוד משלו: OTP: קוד אימות ב-SMS.

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

FromName
  length    up to 11 characters
  charset   A-Z  a-z  0-9  space
  required  at least one letter
  rejected  Hebrew text, digits only

שם ארוך מ-11 תווים אינו נחתך, הקריאה פשוט נדחית. ערך כמו MESER10 תקין, ערך כמו Meser10 Israel אינו תקין.

האימות הוא ברמת החשבון ולא ברמת המפתח. לאחר שהשם אושר, אותה קריאה בדיוק תעבוד בלי שינוי בקוד.