API וגם MCP
כל פעולה שיש במסך קיימת גם כ-endpoint וגם ככלי שסוכן קורא לו. אוטומציה של onboarding היא סקריפט, לא נוהל.
חברות טכנולוגיה
דואר שמתנהג כמו תשתית, לא כמו כלי משרדי
כתובות שנוצרות ונסגרות עם הצוותים, אימות שנבדק ומתוקן בעצמו, API לכל פעולה שיש במסך, ושרת MCP שסוכני AI יכולים לעבוד מולו עם הרשאות מדויקות. בלי טיקט לספק ובלי להמתין ליום עסקים. הדואר של האנשים והדואר של המערכת יוצאים מאותו דומיין, עם אותן שלוש רשומות ואותו יומן.
API מלא, 28 כלי MCP, ורשומות DNS שמתוחזקות אוטומטית
למפתחים
מה שיש כאן ואין במערכת דואר רגילה
מפתחות שהם מדיניות
לכל מפתח בוחרים הרשאות, תקרת שליחה יומית, הגבלת שולחים ונמענים ותפוגה. מפתח שדלף תחום מראש.
כתובת לצוות, לא לאדם
devops@ שייכת לצוות. כניסה ועזיבה של אנשים היא שינוי ניתוב, לא פתיחת תיבה.
שקיפות תפעולית
מה רואים כשמשהו לא עובד
מסירה היא לא קופסה שחורה: יומן אירועים לכל הודעה, אבחון אימות בפקודה אחת, ורשימת אל-תשלח שמנוהלת ולא מנחשים אותה.
- אירועי מסירה, החזרות ותלונות, לכל הודעה, גם ב-API וגם במסך
- diagnose אחד עונה על מצב DNS, אימות, חימום ומוניטין, במשפטים
- יומן ביקורת מלא: איזה מפתח עשה מה ומתי, כולל פעולות של סוכנים
30 בדקהקצב השליחה שמגן על הדומיין מבאג בלולאה
14 יוםחימום אוטומטי בשלוש מדרגות: 20, 50 ו-100 הודעות ביום
מפתח לכל סביבהפיתוח וייצור נפרדים. מפתח שדלף מבוטל בלחיצה
שני סוגי דואר
איפה הדואר של האנשים והדואר של המערכת נפגשים
אנשיםכתובות על הדומיין, לתיבות שכבר יש להם
מערכתאימות, איפוס סיסמה, קוד, חשבונית: API עם מפתח אידמפוטנטיות
אותו דומייןאותן שלוש רשומות, אותו מוניטין, אותו יומן
אותם כלים לסוכןMCP עם ההרשאות של המשתמש שחיבר אותו
מה מפתחים מקבלים
מה חברת טכנולוגיה מקבלת כאן שהיא לא מקבלת מספק דואר רגיל
לצוות פיתוח יש שתי בעיות דואר שנראות דומות ואינן: הדואר של האנשים, והדואר של המערכת. הראשון הוא כתובות לעובדים על הדומיין, שמגיעות לתיבות שכבר יש להם ומשתנות בשורה אחת כשמישהו מצטרף או עוזב. השני הוא מיילים שהקוד שולח: אימות כתובת, איפוס סיסמה, קוד חד פעמי, חשבונית. שניהם יוצאים מאותו דומיין מאומת, אבל השני צריך API ולא תיבה, ומזהה לכל הודעה ולא תיקיית נשלח.
ה-API שולח בקריאת HTTP אחת ודורש מפתח אידמפוטנטיות בגוף הבקשה, כי שרת שאיבד תשובה ינסה שוב, ובלי המפתח זה מייל כפול לאדם אמיתי. אותו מפתח פעמיים מחזיר את אותה תשובה ולא שולח שוב. השגיאות מבדילות בין כתובת שלא קיימת, שאין טעם לנסות שוב, לבין תקלה זמנית שכדאי. וכתובת שחזרה נכנסת לרשימת חסימה, כך שניסיון נוסף אליה נענה בשגיאה במקום לשרוף מוניטין. קצב של שלושים הודעות בדקה וחימום אוטומטי של 14 יום מגנים על הדומיין מבאג בלולאה.
המערכת מחוברת גם לעוזרי AI דרך MCP, עם אותם כלים ואותן הרשאות, ולכן סוכן פנימי יכול לבדוק מצב דומיין ולהכין כתובת בלי שמישהו כתב לו אינטגרציה. וכתובת נכנסת יכולה לדחוף כל הודעה שהתקבלה ל-webhook שלכם, עם השולח, הנושא, הגוף והקבצים, כך שמערכת שלכם מגיבה למייל בלי לקרוא תיבה. השרתים בפרנקפורט, והמסלול הטכני מתחיל בסריקה לקריאה בלבד של הדומיין.
סביבת בדיקות היא מפתח API נפרד לפיתוח, שמבוטל בלחיצה בלי לגעת במפתח הייצור, וכתובת שולח על תת דומיין של בדיקות. כך ריטריי בסביבת פיתוח לא שולח ללקוח אמיתי, וכתובת שחזרה בבדיקה לא נכנסת לרשימת החסימה של הייצור. הכלל שחוסך את רוב התקלות: מפתח לכל סביבה, וכתובת שולח לכל סוג הודעה.
שאלות של צוותי פיתוח
יש סביבת בדיקות או כתובת בדיקה
כן. שולחים לכתובת בדיקה ייעודית ומקבלים את ההודעה בחזרה דרך הכלי, כך שבדיקת אינטגרציה לא תלויה בתיבה אמיתית של מישהו.
איך שולחים מייל מהקוד
endpoint אחד עם אימות מפתח, או כלי MCP אם השולח הוא סוכן. המכסות והמדיניות של המפתח נאכפות בשרת לפני שההודעה יוצאת.
מה קורה כשרשומת DNS משתנה בטעות
המערכת מנטרת את הרשומות, מזהה שינוי ומתקנת או מתריעה, במקום שתגלו את זה כשמיילים מפסיקים להגיע.
אפשר לנהל כמה דומיינים בחשבון אחד
כן, כולל דומיין שיושב בחשבון Cloudflare שלכם: מחברים בטוקן מוגבל, וההקמה רצה עד הסוף בלי להעביר בעלות.
להמשיך מכאן
להמשיך מכאן
להתחיל עם הדומיין שלכם
סריקה ראשונה לקריאה בלבד, ואז אתם מחליטים אם דרך המסך, ה-API או הסוכן.
לפתוח חשבון