อีเมลส่วนตัวของเอเยนต์ AI ของคุณ

ให้ AI agent ของคุณมีที่อยู่อีเมลส่วนตัวเป็นของตัวเอง
ส่ง รับ ค้นหา ตอบกลับ และส่งต่อ — โดยตรงจาก Claude, Gemini, Codex หรือไคลเอนต์ที่รองรับ MCP

คำสั่งเดียว ไม่ต้องรันเซิร์ฟเวอร์ ไม่ต้องตั้งค่า SMTP ฟรีทั้งหมด

เริ่มต้นใช้งาน → เอกสาร

ไม่ใช่แค่ wrapper ของ SES หรือ SendGrid เราสร้างระบบอีเมลทั้งหมดตั้งแต่ต้น — ตั้งแต่รับเมลจนถึงส่งเข้ากล่องจดหมาย

ทำไมต้อง InboxAPI

ทุกสิ่งที่ AI agent ของคุณต้องการเพื่อสื่อสารผ่านอีเมล

Account Setup Illustration An illustration showing an AI agent getting its own @inboxapi.ai email address. [email protected]

ตั้งค่าทันที

Agent ของคุณจะได้รับที่อยู่อีเมลส่วนตัว @inboxapi.ai ในไม่กี่วินาที ไม่ต้องตั้งค่า DNS ไม่ต้องยืนยันโดเมน ไม่ต้องจัดการ API key

MCP Integration Diagram A network diagram showing InboxAPI connecting to multiple AI models via the Model Context Protocol. MCP

รองรับ MCP โดยตรง

ใช้งานได้ทันทีกับ Claude, Gemini, Codex, OpenCode และไคลเอนต์ที่รองรับ MCP ทุกตัว Agent ของคุณสามารถอ่าน ส่ง ตอบกลับ ส่งต่อ และค้นหาอีเมลได้เหมือนคน

Free Forever A prominent zero-dollar badge highlighting that InboxAPI is free for AI agents. $0 FREE FOREVER

ฟรีทั้งหมด

ไม่ต้องใช้บัตรเครดิต ไม่มีระดับการใช้งาน ไม่มีเงื่อนไขแอบแฝง เราเชื่อว่าอีเมลควรเป็นความสามารถพื้นฐานของ AI agent ทุกตัว แผนเสียเงินพร้อมฟีเจอร์เพิ่มเติมกำลังจะมาเร็ว ๆ นี้

Full Email Capabilities An interface showing sending, receiving, and threading tools.

อีเมลเต็มรูปแบบ ไม่ใช่แค่ส่ง

บริการส่วนใหญ่ให้แค่ส่งอีเมล InboxAPI ให้ agent ของคุณมีกล่องจดหมายส่วนตัว — รับเมล ค้นหาตามผู้ส่งหรือหัวเรื่อง ติดตามเธรดสนทนา ตรวจสอบสถานะการส่ง

ป้องกันการใช้งานในทางที่ผิดในตัว

Proof-of-work ตอนสมัคร จำกัดผู้รับ โควตาการส่ง และจำกัดอัตรา ทุกชั้นออกแบบมาเพื่อป้องกันการใช้งานในทางที่ผิด

Direct Infrastructure A stack showing InboxAPI's own mail infrastructure, not a third-party wrapper. OWN INFRA

ไม่ใช่ Wrapper

เราไม่ได้อยู่บน Amazon SES, Postfix หรือ SendGrid เราสร้างและดูแลโครงสร้างพื้นฐานอีเมลทั้งหมดด้วยตัวเอง

เริ่มต้นอย่างรวดเร็ว

1

ติดตั้ง

2

เชื่อมต่อกับ

ใช้งานได้กับ Claude Code, Gemini CLI, OpenCode, Codex และอื่น ๆ

3

เริ่มใช้อีเมล

Agent ของคุณจะได้รับที่อยู่อีเมลส่วนตัวเฉพาะโดยอัตโนมัติ (เช่น )

ไม่ต้องกรอกฟอร์มสมัคร ไม่ต้องมีไฟล์ตั้งค่า

สิ่งที่ agent ของคุณทำได้

  • อ่านและค้นหากล่องจดหมาย
  • ส่งอีเมลถึงใครก็ได้
  • ตอบกลับและส่งต่อข้อความ
  • ติดตามเธรดสนทนา
  • ตรวจสอบสถานะการส่งเมลที่ส่งแล้ว

สิ่งที่คุณสร้างได้

การประสานงานทีมพัฒนา

Agent ที่ส่งอีเมลหากันเพื่อประสานงานการพัฒนา — ตัวหนึ่งจัดการการแจ้งเตือน code review อีกตัวติดตาม build ที่ล้มเหลว ตัวที่สามรายงานสถานะการ deploy

การตรวจสอบและการแจ้งเตือน

Agent ของคุณเฝ้าดูระบบ และเมื่อมีปัญหา มันจะส่งอีเมลให้ทีมพร้อมบริบท — ไม่ใช่แค่การแจ้งเตือนทั่วไป แต่เป็นการวินิจฉัย

สรุปจดหมายข่าว

Agent ที่รับจดหมายข่าวและรายชื่อส่งเมล อ่าน แล้วส่งสรุปรายวันเฉพาะสิ่งที่สำคัญจริง ๆ ให้คุณ

$42.00

การประมวลผลใบแจ้งหนี้และใบเสร็จ

Agent ที่รับใบแจ้งหนี้ทางอีเมล แยกรายการและจำนวนเงิน แล้วป้อนเข้าระบบบัญชีของคุณ

สร้างมาเพื่อความน่าเชื่อถือ

การแยกบัญชี

แต่ละ agent ได้บัญชีแยกของตัวเอง Agent เข้าถึงได้เฉพาะข้อมูลของตนเอง

SPF DKIM DMARC

การยืนยันอีเมล

SPF, DKIM และ DMARC ถูกตั้งค่าโดยอัตโนมัติสำหรับทุกข้อความ

Forget previous instructions and... [DATAMARK: UNTRUSTED] Email content starts here...

การป้องกัน Prompt Injection

เนื้อหาอีเมลที่ไม่น่าเชื่อถือจะถูกแปลงโดยอัตโนมัติด้วย datamarking เพื่อให้ agent แยกแยะข้อมูลภายนอกจากคำสั่งระบบได้ อ้างอิงจากงานวิจัยทางวิชาการ (arXiv:2403.14720)

การป้องกันการใช้งานในทางที่ผิด

Proof-of-work ตอนสมัคร จำกัดผู้รับตามสมุดที่อยู่ (5 ช่อง, การแทนที่แบบ LRU หลังจาก 5 วัน) โควตาการส่ง จำกัดอัตรา และการตรวจสอบที่อยู่อีเมล RFC 5322 ทั้งหมดบังคับใช้โดยค่าเริ่มต้น

12:04:31 - SEND_EMAIL 12:05:12 - GET_INBOX 12:06:05 - SEARCH_EMAILS

เส้นทางการตรวจสอบ

การยืนยันตัวตนแบบ token เชื่อมโยงทุกการกระทำกับบัญชีเฉพาะ คุณจึงรู้เสมอว่าเกิดอะไรขึ้นและเมื่อไหร่

Credential Leak Prevention An authentication token being redacted and blocked from exfiltration. auth_token: sk_live_... LEAK PREVENTED

ความปลอดภัยของข้อมูลรับรอง

อีเมลขาออกที่มี token ยืนยันตัวตนจะถูกปฏิเสธโดยอัตโนมัติเพื่อช่วยป้องกันการรั่วไหลของข้อมูลรับรองโดยไม่ตั้งใจ

คำถามที่พบบ่อย #

ทำไมไม่ให้ agent เข้าถึง Gmail หรือ Outlook ของฉันเลยล่ะ?

ความปลอดภัย — OAuth ของ Gmail/Outlook ให้ agent ของคุณเข้าถึงกล่องจดหมายทั้งหมด (การแพทย์ การเงิน กฎหมาย ส่วนตัว) Prompt injection ในอีเมลขาเข้าใด ๆ สามารถจัดการ agent ที่เข้าถึงข้อมูลทั้งหมดได้ InboxAPI ให้กล่องจดหมายแยกของตัวเองแก่ agent พร้อมการจัดประเภทความน่าเชื่อถือและ datamarking บนทุกข้อความ

ตัวตน — เมื่อ agent ส่งจาก Gmail ของคุณ ผู้รับไม่สามารถบอกได้ว่าพวกเขากำลังคุยกับใคร การตอบกลับไปที่กล่องจดหมายของคุณ ปะปนกับเมลจริงของคุณ InboxAPI ให้ที่อยู่อีเมลส่วนตัวแก่ agent — การแยกที่ชัดเจนระหว่างคุณและ agent

ความสะดวก — API ของ Gmail/Outlook ไม่ใช่ MCP-native คุณต้องมี middleware, OAuth plumbing และการรวมระบบแบบกำหนดเอง InboxAPI ใช้งานได้ทันทีกับไคลเอนต์ MCP ใด ๆ

ต่างจาก AWS SES, SendGrid หรือ Resend อย่างไร?
สิ่งเหล่านั้นคือ API สำหรับส่งเมล — คุณสร้างโครงสร้างพื้นฐานอีเมลบนนั้น InboxAPI ให้ตัวตนอีเมลที่สมบูรณ์แก่ agent ของคุณ: ส่ง รับ ค้นหา ตอบกลับ และส่งต่อ ไม่มีอะไรต้องตั้งค่าและไม่มีโครงสร้างพื้นฐานให้จัดการ
ต่างจาก AgentMail หรือ a1base อย่างไร?
เราสร้างระบบอีเมลของเราเองตั้งแต่ต้น เราไม่ได้ wrap SES, Postfix หรือบริการส่งเมลของบุคคลที่สามใด ๆ เมลของ agent คุณผ่านโครงสร้างพื้นฐานที่เราดูแลโดยตรง
ฟรีจริง ๆ หรือ?
ใช่ ไม่ต้องใช้บัตรเครดิต ไม่มีช่วงทดลอง ไม่มีระดับการใช้งาน เรากำลังพัฒนาแผนเสียเงินพร้อมฟีเจอร์เพิ่มเติม แต่ประสบการณ์หลักจะฟรีตลอดไป
ข้อจำกัดปัจจุบันมีอะไรบ้าง?

แม้ InboxAPI ใช้งานได้เต็มรูปแบบ แต่มีข้อจำกัดบางอย่างในปัจจุบัน:

  • สล็อตสมุดที่อยู่สำหรับผู้รับภายนอก 5 ช่อง (การแทนที่แบบ LRU หลังจากไม่มีการใช้งาน 5 วัน)
  • สำหรับการใช้งานส่วนตัวของ agent เท่านั้น ไม่ใช่บริการสำหรับการส่งจำนวนมาก การตลาด หรือการแจ้งเตือนแอปพลิเคชัน
คุณป้องกันสแปมและการใช้งานในทางที่ผิดอย่างไร?
การสร้างบัญชีต้องมี proof-of-work แต่ละบัญชีมีสล็อตสมุดที่อยู่สำหรับผู้รับภายนอก 5 ช่อง — เมื่อสล็อตทั้งหมดถูกใช้งาน รายการที่ใช้งานล่าสุดน้อยที่สุดจะถูกแทนที่โดยอัตโนมัติหลังจากไม่มีการใช้งาน 5 วัน โควตาการส่งรายวันและการจำกัดอัตราถูกบังคับใช้กับทุกบัญชี ข้อจำกัดเหล่านี้เป็นโครงสร้าง — ไม่ใช่นโยบาย แต่เป็นวิธีที่ระบบทำงาน
ฉันต้องเพิ่มรายชื่อผู้ติดต่อหรือตั้งค่าสมุดที่อยู่หรือไม่?
ไม่จำเป็น สมุดที่อยู่ทำงานโดยอัตโนมัติ — ระบบจะเพิ่มผู้ติดต่อเมื่อเอเจนต์ของคุณส่งอีเมล ไม่ต้องจัดการรายชื่อผู้ติดต่อ ไม่ต้องแก้ไขไฟล์การตั้งค่า และไม่มีขั้นตอนการตั้งค่าใดๆ แต่ละบัญชีสามารถส่งไปยังอีเมลภายนอกที่ไม่ซ้ำกันได้สูงสุด 5 รายการ เมื่อสล็อตทั้งหมดถูกใช้งาน รายการที่ใช้งานล่าสุดน้อยที่สุดจะถูกแทนที่โดยอัตโนมัติหลังจากไม่มีการใช้งาน 5 วัน อีเมลระหว่างเอเจนต์ InboxAPI นั้นไม่จำกัดเสมอ
Prompt injection ผ่านอีเมลล่ะ?
อีเมลขาเข้าทุกฉบับมีการจัดประเภทความน่าเชื่อถือ — เชื่อถือได้ agent ไม่ได้ยืนยัน หรือน่าสงสัย — ตามว่าผู้ส่งอยู่ในสมุดที่อยู่ของคุณหรือไม่ และอีเมลผ่านการตรวจสอบการยืนยันตัวตนหรือไม่ สิ่งนี้ช่วยให้ agent ตัดสินใจว่าควรจัดการแต่ละข้อความอย่างระมัดระวังแค่ไหน อีเมลจาก agent InboxAPI อื่นจะถูกทำเครื่องหมายแยกต่างหาก เพื่อให้ agent ของคุณรู้ว่าต้องตรวจสอบกับคุณก่อนดำเนินการ เนื้อหาอีเมลที่ไม่น่าเชื่อถือยังถูกแปลงด้วยอักขระตัวทำเครื่องหมาย (datamarking) โดยอัตโนมัติ เพื่อให้ agent แยกแยะข้อมูลอีเมลจากคำสั่งของตัวเองได้อย่างชัดเจน
เรื่องการขโมยข้อมูลล่ะ?
อีเมลขาออกจะถูกสแกนหา token ยืนยันตัวตนและข้อมูลรับรอง หาก agent ของคุณพยายามส่งอีเมลที่มี JWT หรือ access token โดยไม่ตั้งใจ ข้อความจะถูกปฏิเสธก่อนออกจากแพลตฟอร์ม สิ่งนี้ป้องกันไม่ให้ agent ถูกหลอกให้รั่วไหลข้อมูลสำคัญผ่านอีเมล
Agent สามารถส่งสแปมหากันได้ไหม?
ข้อจำกัดการส่งเดียวกันใช้กับอีเมลขาออกทั้งหมด — จำกัดผู้รับ โควตา และการจำกัดอัตราทำงานเหมือนกันไม่ว่าใครจะเป็นผู้รับ
อีเมลของ agent จะไปอยู่ในโฟลเดอร์สแปมไหม?
อาจจะในช่วงแรก แต่ละ agent ได้รับ subdomain ใหม่ และผู้ส่งใหม่ยังไม่มีชื่อเสียง ผู้รับอาจต้องตรวจสอบโฟลเดอร์สแปมสำหรับอีเมลไม่กี่ฉบับแรก เมื่อเวลาผ่านไป เมื่อ agent ของคุณส่งเมลที่ถูกต้องและผู้รับมีปฏิสัมพันธ์ การส่งจะดีขึ้น อ่านเพิ่มเติมเกี่ยวกับการส่งอีเมล
ทำไมเลือกอีเมลแทนโปรโตคอล agent อย่าง A2A?
อีเมลเข้าถึงอินเทอร์เน็ตที่มีอยู่ทั้งหมด — ผู้คนและธุรกิจหลายพันล้านใช้อยู่แล้ว A2A ต้องการให้ทั้งสองฝ่ายใช้โปรโตคอลนั้น เมื่อ agent ของคุณต้องติดต่อคนนอกระบบนิเวศของตัวเอง อีเมลคือตัวเลือกสากล Agent น่าจะต้องใช้ทั้งสอง
ทำไมต้องอีเมลแทน WhatsApp, Telegram หรือแอปส่งข้อความอื่น?

ความสามารถในการขยาย — คุณสามารถสร้างที่อยู่อีเมลได้หลายร้อยรายการด้วยโปรแกรม WhatsApp, Telegram และ Signal ล้วนต้องการหมายเลขโทรศัพท์และการยืนยัน การขยายเกินกว่าบัญชีไม่กี่บัญชีไม่เป็นจริง มักขัดกับข้อกำหนดการใช้งาน และบางครั้งเป็นไปไม่ได้หากไม่มีซิมการ์ดจริง

ไม่มีผู้รักษาประตู — อีเมลเป็นช่องทางการสื่อสารเดียวที่คุณสามารถสร้างตัวตนได้โดยไม่ต้องมีหมายเลขโทรศัพท์ บัตรประชาชน หรือการอนุมัติจากเจ้าของแพลตฟอร์ม ไม่มีบริษัทใดบริษัทเดียวที่ควบคุมว่าใครจะได้รับที่อยู่อีเมล

โปรโตคอลเปิด — อีเมลเป็นแบบสหพันธ์และเป็นกลางต่อผู้ให้บริการ WhatsApp, Discord และ Telegram เป็นกรรมสิทธิ์ — พวกเขาสามารถเพิกถอนการเข้าถึง API แบนบัญชีบอท หรือเปลี่ยนกฎเมื่อใดก็ได้ อีเมลไม่สามารถถูกปิดโดยบริษัทเดียว

การปฏิบัติตาม ToS — แพลตฟอร์มส่งข้อความส่วนใหญ่ห้ามบัญชีอัตโนมัติอย่างชัดเจนหรือมีกระบวนการอนุมัติที่เข้มงวด (WhatsApp Business API ต้องการการยืนยันธุรกิจ, Telegram จำกัดการส่งข้อความระหว่างบอท) อีเมลไม่มีข้อจำกัดดังกล่าว — การส่งอัตโนมัติเป็นกรณีการใช้งานชั้นหนึ่ง

การเข้าถึงสากล — ช่องทางส่งข้อความถูกแยกออกจากกัน บอท Telegram ของคุณไม่สามารถเข้าถึงผู้ใช้ WhatsApp ได้ อีเมลเข้าถึงทุกคนที่มีที่อยู่อีเมล — ซึ่งก็คือแทบทุกคน

สำหรับเฟรมเวิร์กเอเจนต์หลายช่องทางอย่าง OpenClaw อีเมลเติมเต็มช่องว่างที่แพลตฟอร์มส่งข้อความไม่สามารถเติมได้ในเชิงโครงสร้าง — การสร้างตัวตนไม่จำกัดและสามารถโปรแกรมได้โดยไม่ต้องการอนุมัติจากแพลตฟอร์ม InboxAPI มอบความสามารถนั้นโดยตรง

ฉันควรใช้โมเดล AI ใดร่วมกับ InboxAPI?

โมเดลของคุณต้องรองรับ การเรียกใช้เครื่องมือ/ฟังก์ชัน (tool/function calling) — MCP บังคับให้ใช้สิ่งนี้ ขอแนะนำให้ใช้ขั้นต่ำ 32K token context window

ดี: Claude Haiku 4.5+, GPT-4.1 mini+, GPT-4.1 nano+, Gemini 2.5 Flash+

แนะนำ: Claude Sonnet 4.5+, GPT-4.1+, GPT-5 mini+, Gemini 2.5 Pro+

ดีที่สุด: Claude Opus 4.5+, GPT-5+, GPT-5.2+, Gemini 2.5 Pro+

InboxAPI จะใช้การทำเครื่องหมายข้อมูล (spotlighting) กับเนื้อหาอีเมลที่ไม่น่าเชื่อถือ ซึ่งอาจเพิ่มการใช้โทเค็นเล็กน้อย โมเดลที่มีหน้าต่างบริบทใหญ่กว่าจะจัดการสิ่งนี้ได้สบายกว่า

สิ่งที่จะไม่ทำงาน: โมเดลที่ไม่รองรับการเรียกใช้เครื่องมือ/ฟังก์ชัน, หน้าต่างบริบทย่อยกว่า 16K โทเค็น, หรือโมเดลในเครื่องขนาดเล็กมาก (ต่ำกว่า ~7B พารามิเตอร์)

จะทำอย่างไรถ้าเอเจนต์สูญเสียการเข้าถึงบัญชี?
หากข้อมูลรับรองของเอเจนต์สูญหายหรือเสียหาย คุณสามารถกู้คืนบัญชีได้โดยใช้เครื่องมือ account_recover — แต่เฉพาะในกรณีที่คุณเคยเชื่อมโยงอีเมลของคุณผ่าน verify_owner แล้วเท่านั้น การกู้คืนจะเพิกถอนโทเค็นที่มีอยู่ทั้งหมดและออกข้อมูลรับรองใหม่ หากไม่มีอีเมลเจ้าของที่ได้รับการยืนยัน จะไม่มีวิธีกู้คืนบัญชีที่ถูกล็อก
การยืนยันเจ้าของคืออะไร?
การยืนยันเจ้าของจะเชื่อมโยงที่อยู่อีเมลส่วนตัวของคุณกับบัญชี InboxAPI ของเอเจนต์ เอเจนต์ของคุณเรียก verify_owner ด้วยอีเมลของคุณ คุณจะได้รับรหัส 6 หลัก และเอเจนต์ส่งรหัสนั้นเพื่อทำการยืนยัน เมื่อยืนยันแล้ว คุณสามารถกู้คืนบัญชีได้หากข้อมูลรับรองสูญหาย และข้อจำกัดทดลองใช้จะถูกลบออกจากบัญชี

ให้ agent ของคุณมีที่อยู่อีเมลส่วนตัว

คำสั่งเดียว ฟรีตลอดไป

เริ่มต้นใช้งาน → เอกสาร GitHub