กำหนดค่า Webhooks

Published: 16 กรกฎาคม 2569 · Last updated: 21 กรกฎาคม 2569 · By Marcus Biel

Webhooks ช่วยให้ Maildroppa แจ้งเตือนแอปพลิเคชันอื่นเมื่อมีเหตุการณ์สำคัญเกิดขึ้นในบัญชีของคุณ

แทนที่จะส่งคำถามไปยัง Maildroppa ซ้ำ ๆ ว่ามีการสร้าง อัปเดต ยกเลิกการสมัคร หรือกำหนดแท็กให้ subscriber แล้วหรือไม่ แอปพลิเคชันของคุณสามารถรับคำขอ HTTPS ได้ไม่นานหลังจากเกิดเหตุการณ์

หน้า Webhooks คือศูนย์กลางสำหรับการผสานรวมระดับบัญชีนี้ คุณสามารถสร้างปลายทางได้หลายรายการ เลือกเหตุการณ์ที่แต่ละปลายทางจะได้รับ เพิ่มส่วนหัวการตรวจสอบสิทธิ์ ทดสอบการเชื่อมต่อ ตรวจสอบความพยายามในการส่ง และเล่นเหตุการณ์ production ซ้ำเมื่อจำเป็น

วิธีทำงานของ Account Webhooks

Account webhook ทำงานตามขั้นตอนต่อไปนี้:

1. เกิดเหตุการณ์ขึ้นใน Maildroppa เช่น มีการสร้าง subscriber
2. Maildroppa ค้นหาปลายทางที่เปิดใช้งานทั้งหมดซึ่งสมัครรับเหตุการณ์นั้น
3. Maildroppa สร้างการส่งหนึ่งรายการสำหรับแต่ละปลายทางที่ตรงกัน
4. เพย์โหลด JSON ถูกลงนามด้วย webhook Signing secret ของบัญชีคุณ
5. Maildroppa ส่งคำขอ HTTPS POST ไปยัง URL ปลายทางที่บันทึกไว้
6. ปลายทางของคุณตรวจสอบลายเซ็น จัดเก็บหรือประมวลผลเหตุการณ์ และส่งการตอบกลับ HTTP
7. Maildroppa บันทึกผลลัพธ์ไว้ในประวัติการส่ง และลองส่งใหม่โดยอัตโนมัติเมื่อเกิดข้อผิดพลาดชั่วคราว

หากมีหลายปลายทางสมัครรับเหตุการณ์เดียวกัน แต่ละปลายทางจะได้รับการส่งของตนเอง เหตุการณ์ทางธุรกิจจะมี Event ID เดียวกันสำหรับทุกปลายทาง ขณะที่การส่งแต่ละครั้งจะมี Delivery ID ของตนเอง

Account webhooks แตกต่างจากขั้นตอน “Send a webhook” ภายใน Automation โดย Account webhooks จะรับฟังเหตุการณ์ของบัญชีที่เลือกไว้ทั่วทั้ง Maildroppa ส่วน Automation webhook จะถูกส่งเฉพาะเมื่อ subscriber ไปถึงขั้นตอนนั้น ทั้งสองแบบใช้ webhook Signing secret ของบัญชี ดังนั้นการหมุนเวียน secret จะส่งผลต่อผู้รับ webhook ขาออกทุกตัวที่ตรวจสอบลายเซ็นของ Maildroppa

การเปิดหน้า Webhooks

เปิด “Settings” ขยาย “Developers” แล้วเลือก “Webhooks”

หน้านี้มีพื้นที่หลักสามส่วน:

• Signing secret
• Endpoints
• ประวัติการส่งของปลายทางที่เลือก

เมื่อมีปลายทางมากกว่าหนึ่งรายการ ให้เลือกแถวของปลายทางเพื่อแสดงประวัติการส่ง หากคุณยังไม่ได้เลือกอย่างชัดเจน Maildroppa จะแสดงประวัติของปลายทางรายการแรกในรายการ

ก่อนสร้างปลายทาง

เตรียมตัวรับข้อมูลบนเซิร์ฟเวอร์ของคุณก่อนกำหนดค่า Maildroppa ตัวรับควร:

• เข้าถึงได้ผ่าน URL HTTPS สาธารณะ
• รองรับคำขอ POST ที่มีเนื้อหา application/json
• เก็บ raw request body ไว้จนกว่าจะตรวจสอบลายเซ็นของ Maildroppa เสร็จ
• ส่งสถานะ 2xx เฉพาะหลังจากรับเหตุการณ์อย่างปลอดภัยแล้ว
• ประมวลผลการส่งซ้ำแบบ idempotent โดยใช้ Event ID
• ตอบกลับอย่างรวดเร็วแทนการทำงานที่ใช้เวลานานระหว่างคำขอ

แนวทางที่เชื่อถือได้คือ ตรวจสอบคำขอ จัดเก็บ Event ID และเพย์โหลดไว้ในคิวหรือฐานข้อมูลถาวร ส่ง 200 หรือ 204 แล้วจึงประมวลผลการทำงานทางธุรกิจภายหลัง

อย่าเปิดเผยคอมพิวเตอร์สำหรับพัฒนา ที่อยู่เครือข่ายภายใน หรือสคริปต์ที่ไม่มีการป้องกันให้เป็นตัวรับ webhook สำหรับ production Maildroppa ยอมรับเฉพาะเป้าหมาย HTTPS สาธารณะ และตรวจสอบปลายทางอีกครั้งเมื่อมีการส่งการส่ง

ขั้นตอนที่ 1: สร้าง Signing Secret

คำขอ webhook ทุกคำขอของ Maildroppa จะถูกลงนาม ตัวรับของคุณใช้ Signing secret เพื่อตรวจสอบว่าคำขอนั้นสร้างโดย Maildroppa และเนื้อหาไม่ได้ถูกเปลี่ยนแปลงระหว่างทาง

ด้านบนของหน้า แผง Signing secret จะแสดงสถานะใดสถานะหนึ่งต่อไปนี้:

• Missing — ยังไม่มี Signing secret
• Ready — กำหนดค่า Signing secret แล้ว
• Loading — Maildroppa กำลังเรียกดูสถานะปัจจุบัน

คลิก “Generate secret” เมื่อสถานะเป็น Missing

Maildroppa จะแสดง secret ใหม่ทันที โดยขึ้นต้นด้วย whsec_ คลิก “Copy” แล้วจัดเก็บไว้ในตัวจัดการ secret หรือการกำหนดค่าสภาพแวดล้อมที่มีการป้องกันซึ่งตัวรับของคุณใช้

ค่าทั้งหมดจะแสดงเฉพาะทันทีหลังการสร้างหรือการหมุนเวียนเท่านั้น เมื่อโหลดหน้าซ้ำหรือออกจากหน้า Maildroppa จะแสดงเพียงว่ามี secret อยู่และอัปเดตล่าสุดเมื่อใด โดยจะไม่เปิดเผย secret ที่จัดเก็บไว้อีก

หากคุณทำ Secret หาย

หากตัวรับไม่มี secret ปัจจุบันแล้ว ให้คลิก “Rotate secret” และบันทึกค่าที่แสดงใหม่

การหมุนเวียนจะแทนที่ secret เดิมทันที Maildroppa จะไม่เก็บค่าทั้งสองไว้ในช่วงเปลี่ยนผ่าน อัปเดตตัวรับทุกตัวที่ใช้ secret ของบัญชีนี้ก่อนส่งการทดสอบเพิ่มเติมหรือพึ่งพาการส่งใน production

การส่งใหม่ การลองส่งซ้ำตามกำหนด การทดสอบ และการเล่นซ้ำ จะลงนามด้วย secret ปัจจุบัน ณ เวลาที่ส่งคำขอ HTTP ซึ่งหมายความว่าการส่งที่สร้างก่อนการหมุนเวียนยังอาจลงนามด้วย secret ใหม่เมื่อถูกลองส่งภายหลัง

ปฏิบัติต่อ Secret เหมือนรหัสผ่าน

อย่าวาง Signing secret ไว้ในโค้ดบนเบราว์เซอร์ รีโพสาธารณะ URL หน้าข้อผิดพลาด หรือบันทึกแอปพลิเคชันทั่วไป

เฉพาะตัวรับฝั่งเซิร์ฟเวอร์เท่านั้นที่จำเป็นต้องใช้ secret หากคุณเชื่อว่า secret ถูกเปิดเผย ให้หมุนเวียน secret และอัปเดตตัวรับทั้งหมดทันที

การตรวจสอบลายเซ็น Webhook

แต่ละคำขอมีส่วนหัวของ Maildroppa ดังต่อไปนี้:

• X-Maildroppa-Event-Id — ระบุเหตุการณ์ทางธุรกิจ
• X-Maildroppa-Delivery-Id — ระบุการส่งรายการนี้โดยเฉพาะ
• X-Maildroppa-Timestamp — เวลาที่ลงนามในรูปแบบวินาที Unix
• X-Maildroppa-Signature — ลายเซ็น HMAC แบบมีเวอร์ชัน

Maildroppa ยังส่ง:

• Content-Type: application/json
• User-Agent: Maildroppa-Webhooks/1.0

ลายเซ็นมีรูปแบบดังนี้:

v1=<lowercase hexadecimal HMAC>

Maildroppa สร้างลายเซ็นด้วย HMAC-SHA256 เนื้อหาที่ลงนามคือ timestamp ตามด้วยจุด ตามด้วยเนื้อหา JSON ดิบของคำขอที่ตรงกันทุกประการ:

<timestamp>.<raw request body>

ใช้ Signing secret เป็นคีย์ HMAC

ตัวอย่าง Node.js ต่อไปนี้แสดงขั้นตอนการตรวจสอบที่สำคัญ rawBody ต้องเป็นไบต์ดั้งเดิมของคำขอ ไม่ใช่ JSON ที่ถูกแยกวิเคราะห์และทำ serialization ใหม่แล้ว

import crypto from 'node:crypto';

export function verifyMaildroppaWebhook({ rawBody, timestamp, signature, signingSecret }) {
  const signedPayload = Buffer.concat([Buffer.from(`${timestamp}.`, 'utf8'), rawBody]);

  const expectedSignature = `v1=${crypto
    .createHmac('sha256', signingSecret)
    .update(signedPayload)
    .digest('hex')}`;

  const received = Buffer.from(signature, 'utf8');
  const expected = Buffer.from(expectedSignature, 'utf8');

  return received.length === expected.length && crypto.timingSafeEqual(received, expected);
}

หลังตรวจสอบลายเซ็นแล้ว ให้เปรียบเทียบ timestamp กับเวลาของเซิร์ฟเวอร์ด้วย ปฏิเสธคำขอที่อยู่นอกช่วงเวลาที่ยอมรับได้สั้น ๆ ซึ่งเลือกตามโครงสร้างพื้นฐานของคุณ เช่น ห้านาที วิธีนี้ช่วยลดความเสี่ยงที่คำขอที่ถูกต้องซึ่งถูกดักจับจะถูกเล่นซ้ำในภายหลังเป็นเวลานาน

ให้แยกวิเคราะห์และประมวลผล JSON หลังจากผ่านการตรวจสอบทั้งสองรายการแล้วเท่านั้น

สาเหตุทั่วไปของข้อผิดพลาดด้านลายเซ็น

ลายเซ็นมักล้มเหลวด้วยสาเหตุใดสาเหตุหนึ่งต่อไปนี้:

• ตัวรับใช้ secret เก่าหลังการหมุนเวียน
• Middleware แยกวิเคราะห์หรือเปลี่ยนแปลง JSON ก่อนคำนวณลายเซ็น
• ตัวรับลงนามเฉพาะ body และละเว้น <timestamp>.
• timestamp ถูกถือเป็นวันที่ที่จัดรูปแบบแล้ว แทนที่จะใช้ค่าจากส่วนหัวแบบตรงตัว
• ละเว้นคำนำหน้า v1= ในการเปรียบเทียบ
• HMAC ที่คำนวณได้ถูกเข้ารหัสด้วยรูปแบบอื่นแทนเลขฐานสิบหกตัวพิมพ์เล็ก

บันทึก Event ID และ Delivery ID เมื่อการตรวจสอบลายเซ็นล้มเหลว แต่อย่าบันทึก Signing secret หรือค่าของ custom header ที่มีข้อมูลละเอียดอ่อน

ขั้นตอนที่ 2: เพิ่มปลายทาง

คลิก “Add endpoint” ในส่วน Endpoints

ตัวแก้ไขมีสี่ส่วน:

• Endpoint URL
• Events
• Custom headers
• สถานะ Active

ปลายทางใหม่จะเริ่มต้นเป็น Active และเหตุการณ์ทั้งหมดที่แสดงในตัวแก้ไขจะถูกเลือกไว้ตั้งแต่แรก ตรวจสอบรายการที่เลือกก่อนบันทึก เพื่อให้ตัวรับได้รับเฉพาะการแจ้งเตือนที่จำเป็นจริง ๆ

การกำหนดค่า Endpoint URL

ป้อน URL สาธารณะที่สมบูรณ์ซึ่งควรรับคำขอจาก Maildroppa ตัวอย่างเช่น:

https://integrations.example.com/webhooks/maildroppa

URL ต้องเป็นไปตามข้อกำหนดต่อไปนี้:

• ต้องใช้ https://
• ต้องมี hostname สาธารณะที่ถูกต้อง
• มีความยาวได้สูงสุด 2,048 อักขระ
• ห้ามมีตัวแปรเทมเพลตที่มี { หรือ }
• ห้ามมีชื่อผู้ใช้หรือรหัสผ่านก่อน hostname
• ห้ามมี URL fragment ที่ขึ้นต้นด้วย #
• ต้องใช้พอร์ต HTTPS มาตรฐาน 443
• ห้ามใช้ localhost ที่อยู่ IP โดยตรง หรือ hostname ที่แก้ไขไปเป็นเครือข่ายส่วนตัวหรือเครือข่ายสงวนที่ถูกบล็อก

รองรับ query parameters แต่อย่าใส่ API key หรือ secret อื่น ๆ ไว้ใน URL URL จะแสดงในรายการปลายทางและข้อมูลการส่ง ให้ใช้ Custom header สำหรับข้อมูลรับรองแทน

Maildroppa จะไม่ติดตามการเปลี่ยนเส้นทาง ให้บันทึกปลายทาง HTTPS สุดท้ายแทน URL ที่ส่งผลลัพธ์เป็น 301, 302, 307 หรือ 308

ระบบจะแก้ไข hostname ของปลายทางอีกครั้งก่อนส่ง หาก hostname ภายหลังแก้ไขไปเป็นที่อยู่ส่วนตัวหรือที่อยู่ที่ถูกบล็อก จะถูกปฏิเสธแม้จะถูกต้องในขณะที่บันทึกปลายทาง

การเลือก Events

เลือกอย่างน้อยหนึ่งเหตุการณ์ ปลายทางจะได้รับเฉพาะประเภทเหตุการณ์ที่เลือกในตัวแก้ไข

หน้าดังกล่าวมีตัวเลือกเหตุการณ์ต่อไปนี้:

Subscriber Created — subscriber.created

ส่งเมื่อมีการสร้าง subscriber ในบัญชี Maildroppa

ใช้เหตุการณ์นี้เพื่อสร้าง contact ที่สอดคล้องกันใน CRM แพลตฟอร์มข้อมูลลูกค้า ฐานข้อมูลภายใน หรือระบบอื่นที่คำนึงถึงสิทธิ์

อย่าตีความเหตุการณ์นี้ว่าเป็นหลักฐานว่าการสมัครทุกครั้งเสร็จสิ้น Double Opt-in แล้ว สถานะ subscriber ในเพย์โหลดจะอธิบายสถานะปัจจุบัน

Subscriber Updated — subscriber.updated

ส่งเมื่อข้อมูล subscriber ในตัวหรือค่าฟิลด์ที่กำหนดเองมีการเปลี่ยนแปลง

ใช้ subscriber object ทั้งหมดในเพย์โหลดเป็นตัวแทนปัจจุบันของ Maildroppa หลีกเลี่ยงการสมมติว่ามีการเปลี่ยนแปลงเพียงพร็อพเพอร์ตีใดพร็อพเพอร์ตีหนึ่ง

การกำหนดและนำแท็กออกมีประเภทเหตุการณ์ของตนเอง เพื่อให้จัดการแยกกันได้

Subscriber Unsubscribed — subscriber.unsubscribed

ส่งเมื่อ subscriber เปลี่ยนเป็นสถานะ unsubscribed ผ่านการยกเลิกการสมัคร

ใช้เหตุการณ์นี้เพื่อระงับ contact ในระบบที่เชื่อมต่อ อย่าสมัครบุคคลนั้นกลับโดยอัตโนมัติเพียงเพราะระบบอื่นยังระบุว่า contact มีสถานะ active

Tag Added — subscriber.tag_added

ส่งเมื่อกำหนดแท็กให้ subscriber

เพย์โหลดประกอบด้วย subscriber และแท็กที่เกี่ยวข้องกับการเปลี่ยนแปลงครั้งนี้

Tag Removed — subscriber.tag_removed

ส่งเมื่อมีการนำแท็กออกจาก subscriber

เพย์โหลดประกอบด้วย subscriber ที่อัปเดตแล้วและแท็กที่นำออก แท็กที่นำออกจะถูกให้มาแยกต่างหาก แม้จะไม่มีอยู่ในอาร์เรย์ tags ปัจจุบันของ subscriber แล้ว

Form Submitted — form.submitted

ส่งเมื่อผู้เยี่ยมชมส่งแบบฟอร์มสมัครสมาชิกของ Maildroppa

ให้ถือว่านี่เป็นสัญญาณการส่งแบบฟอร์ม ไม่ใช่การยืนยันว่า Double Opt-in เสร็จสมบูรณ์แล้ว เวิร์กโฟลว์ใด ๆ ที่ต้องการการสมัครที่ยืนยันแล้วต้องยังคงเคารพสถานะปัจจุบันของ subscriber และกระบวนการยืนยัน

ใช้ปลายทางแยกกันเมื่อความรับผิดชอบแตกต่างกัน

คุณสามารถส่งเหตุการณ์ต่าง ๆ ไปยังระบบต่าง ๆ ได้ ตัวอย่างเช่น:

• ส่งเหตุการณ์ subscriber และแท็กไปยัง CRM
• ส่งเหตุการณ์ยกเลิกการสมัครไปยังบริการระงับการติดต่อ
• ส่งเหตุการณ์การส่งแบบฟอร์มไปยังไปป์ไลน์การวิเคราะห์ข้อมูล

ปลายทางแยกกันช่วยลดทราฟฟิกที่ไม่จำเป็นและทำให้วินิจฉัยข้อผิดพลาดได้ง่ายขึ้น แต่ละปลายทางมีการเลือกเหตุการณ์ URL custom headers สถานะ active การทดสอบ และประวัติการส่งของตนเอง

การเพิ่ม Custom Headers

Custom headers เป็นตัวเลือกเสริม ใช้เมื่อผู้รับต้องการ API key, bearer token, tenant identifier หรือส่วนหัวแบบคงที่อื่น ๆ

คลิก “Add header” แล้วป้อน Header name และ Header value ตัวอย่างที่เหมาะสม ได้แก่:

Authorization: Bearer your-token

X-Integration-Key: your-secret-key

คุณสามารถเพิ่ม custom headers ได้สูงสุด 20 รายการ

ชื่อส่วนหัว:

• จำเป็นต้องระบุ
• มีความยาวได้สูงสุด 128 อักขระ
• ต้องใช้อักขระชื่อส่วนหัว HTTP ที่ถูกต้อง
• ต้องไม่ซ้ำกันโดยไม่คำนึงถึงตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก

ค่าของส่วนหัว:

• จำเป็นต้องระบุ
• มีความยาวได้สูงสุด 2,000 อักขระ
• ห้ามมีการขึ้นบรรทัดใหม่

ชื่อดังต่อไปนี้เป็นชื่อสงวนและไม่สามารถแทนที่ด้วย custom header ได้:

• Content-Type
• Content-Length
• Host
• User-Agent
• ชื่อใด ๆ ที่ขึ้นต้นด้วย X-Maildroppa-

วิธีนี้ช่วยป้องกันไม่ให้ค่าที่กำหนดเองแทนที่ส่วนหัวการส่งและลายเซ็นของ Maildroppa

วิธีจัดเก็บ Secret ใน Header

Maildroppa เข้ารหัสค่าของ custom header ก่อนจัดเก็บ ค่าที่บันทึกไว้จะไม่ถูกส่งกลับไปยังเบราว์เซอร์ในรูปแบบที่อ่านได้

เมื่อแก้ไขปลายทางในภายหลัง ช่องค่าจะแสดง “Stored value kept” เว้นว่างไว้เมื่อควรเก็บ secret เดิมไว้ ป้อนค่าใหม่เพื่อแทนที่ค่าเดิม

หากเปลี่ยนชื่อส่วนหัว ให้ป้อนค่าอีกครั้ง Maildroppa จะเก็บ secret ไว้เฉพาะเมื่อชื่อส่วนหัวเดิมยังไม่เปลี่ยนแปลง

การลบแถวส่วนหัวจะนำส่วนหัวนั้นออกจากการส่งในอนาคตหลังจากบันทึกปลายทางแล้ว

ค่าของ custom header จะถือเป็นข้อมูลละเอียดอ่อนในข้อมูลคำขอที่จัดเก็บไว้ โดยจะถูกปิดบังแทนการแสดงในประวัติการส่ง

การตั้งค่าปลายทางเป็น Active หรือ Inactive

ปล่อยให้เลือก “Active” เมื่อปลายทางพร้อมรับเหตุการณ์ทันที

ยกเลิกการเลือกเมื่อคุณต้องการบันทึกการกำหนดค่าโดยยังไม่เริ่มการส่ง คุณสามารถเปิดใช้งานปลายทางภายหลังจากรายการปลายทาง

ปลายทางที่ inactive:

• จะไม่รับเหตุการณ์ใหม่ที่เกิดขึ้น
• ไม่สามารถส่ง Test webhook ได้
• ยังคงแสดงและแก้ไขได้
• ยังคงมีประวัติการส่งเดิมให้ดู

การเปิดใช้งานปลายทางจะไม่เติมเหตุการณ์ย้อนหลังที่เกิดขึ้นขณะที่ปลายทาง inactive

คลิก “Save” เมื่อ URL การเลือกเหตุการณ์ headers และสถานะถูกต้อง

ทำความเข้าใจรายการปลายทาง

แต่ละแถวของปลายทางจะแสดง:

• URL ปลายทาง
• ป้าย Active หรือ Inactive
• ประเภทเหตุการณ์ที่สมัครรับ
• จำนวน custom headers
• เวลาที่อัปเดตปลายทางล่าสุด

การดำเนินการที่มีให้เลือก ได้แก่:

• On/Off — เปิดใช้งานหรือปิดใช้งานปลายทาง
• Test — ส่งคำขอทดสอบทันทีหนึ่งรายการไปยังปลายทางที่ active
• Edit — เปลี่ยน URL เหตุการณ์ headers หรือสถานะ active
• Delete — ลบการกำหนดค่าปลายทางอย่างถาวรหลังการยืนยัน

เลือกส่วนหลักของแถวเพื่อเปิดประวัติการส่งของปลายทางนั้นด้านล่างรายการ

การเปลี่ยนแปลงที่บันทึกไว้ส่งผลต่อการส่งที่มีอยู่แล้วอย่างไร

เหตุการณ์ของบัญชีจะสร้างการส่งพร้อม snapshot ของ URL ปลายทาง เพย์โหลด และ custom headers ณ เวลานั้น

การแก้ไข URL หรือ custom headers จะมีผลต่อการส่งที่สร้างใหม่ การส่งที่อยู่ในคิวแล้วจะคงปลายทางและการกำหนดค่า header ที่จัดเก็บไว้เดิม

การเปลี่ยนเหตุการณ์ที่เลือกก็มีผลเฉพาะเหตุการณ์ที่เกิดขึ้นภายหลัง Maildroppa จะไม่สร้างการส่งย้อนหลังสำหรับประเภทเหตุการณ์ที่ไม่ได้เลือกในขณะที่เกิดเหตุการณ์

Signing secret แตกต่างออกไป: ระบบจะอ่าน secret เมื่อเตรียมคำขอ HTTP ดังนั้นการส่งที่รอดำเนินการหรือการเล่นซ้ำอาจใช้ Signing secret ที่หมุนเวียนใหม่ แม้ snapshot ของเพย์โหลดและปลายทางจะถูกสร้างไว้ก่อนหน้านี้

การทดสอบปลายทาง

คลิก “Test” บนปลายทางที่ active หลังจากตัวรับและ Signing secret พร้อมแล้ว

Maildroppa จะส่งคำขอที่ลงนามแล้วหนึ่งรายการทันที โดยใช้ URL ปลายทางและ custom headers ที่บันทึกไว้ การเปลี่ยนแปลงที่ยังไม่ได้บันทึกในตัวแก้ไขที่เปิดอยู่จะไม่รวมอยู่ในการทดสอบ

เพย์โหลดการทดสอบใช้ประเภทเหตุการณ์ webhook.test และกำหนด livemode เป็น false:

{
  "id": "evt_test_example",
  "type": "webhook.test",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": false,
  "data": {
    "message": "This is a test webhook from Maildroppa."
  }
}

ID และ timestamp ที่สร้างขึ้นจะแตกต่างกันในการทดสอบจริงแต่ละครั้ง

การทดสอบจะพยายามส่ง HTTP เพียงครั้งเดียว การส่งทดสอบจะไม่ถูกจัดไว้ในกำหนดการลองส่งซ้ำสำหรับ production และไม่สามารถเล่นซ้ำได้

หลังคำขอเสร็จสิ้น แผงผลลัพธ์จะแสดง:

• Test success หรือ Test failed
• Event ID
• สถานะ HTTP เมื่อได้รับการตอบกลับ
• ระยะเวลา
• Delivery ID
• ข้อมูลข้อผิดพลาดเมื่อมี
• ส่วนตัดทอนของการตอบกลับเมื่อผู้รับส่ง body กลับมา

การทดสอบจะแสดงในประวัติการส่งพร้อมป้าย Test ด้วย ใช้ตัวกรอง “Test” เพื่อแสดงเฉพาะคำขอทดสอบ

ทำความเข้าใจ Production Payload

เหตุการณ์ของบัญชีใน production ใช้ซอง JSON มาตรฐาน:

{
  "id": "evt_example",
  "type": "subscriber.created",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {}
}

พร็อพเพอร์ตีระดับบนสุดมีความหมายดังนี้:

• id — Event ID ตรงกับ X-Maildroppa-Event-Id
• type — คีย์เหตุการณ์ที่เลือกในตัวแก้ไขปลายทาง
• schema_version — เวอร์ชันสคีมาของเพย์โหลด ใช้เมื่อตัดสินใจว่าจะแยกวิเคราะห์เหตุการณ์อย่างไร
• created_at — เวลาที่สร้างเพย์โหลดเหตุการณ์ใน UTC
• livemode — true สำหรับเหตุการณ์ production และ false สำหรับเหตุการณ์ทดสอบ
• data — เนื้อหาเฉพาะของเหตุการณ์

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

เพย์โหลดเหตุการณ์ Subscriber

เหตุการณ์ subscriber จะมีตัวแทน subscriber ปัจจุบันอยู่ภายใน data.subscriber:

{
  "id": "evt_example",
  "type": "subscriber.updated",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {
    "subscriber": {
      "id": "7f49d0e9-77d6-4c24-8b90-12c9d53d82cc",
      "email": "alex@example.com",
      "first_name": "Alex",
      "status": "active",
      "registered_at": "2026-07-15T08:15:00Z",
      "fields": [
        {
          "id": "b6594e58-0c4b-4138-9ad8-fc4747e076eb",
          "personalization_tag_name": "company",
          "value": "Example Ltd."
        }
      ],
      "tags": [
        {
          "id": "c69af5de-39d3-42a4-8f55-ddf86d10a51c",
          "name": "Customers"
        }
      ]
    }
  }
}

fields และ tags เป็นอาร์เรย์และอาจว่างเปล่า พร็อพเพอร์ตีของ subscriber อาจเป็น null เมื่อไม่มีค่า ดังนั้นตัวรับของคุณควรปฏิบัติตามสคีมาของเพย์โหลด แทนที่จะสมมติว่าค่าโปรไฟล์ที่เป็นตัวเลือกทุกค่าจะมีอยู่

เพย์โหลดเหตุการณ์ Tag

เหตุการณ์แท็กจะมีทั้ง subscriber และแท็กที่ทำให้เกิดเหตุการณ์:

{
  "id": "evt_example",
  "type": "subscriber.tag_added",
  "schema_version": "1",
  "created_at": "2026-07-16T10:30:00Z",
  "livemode": true,
  "data": {
    "subscriber": {
      "id": "7f49d0e9-77d6-4c24-8b90-12c9d53d82cc",
      "email": "alex@example.com",
      "first_name": "Alex",
      "status": "active",
      "registered_at": "2026-07-15T08:15:00Z",
      "fields": [],
      "tags": []
    },
    "tag": {
      "id": "c69af5de-39d3-42a4-8f55-ddf86d10a51c",
      "name": "Customers"
    }
  }
}

สำหรับ subscriber.tag_removed, data.tag ยังคงระบุแท็กที่นำออก แม้ว่าอาร์เรย์ tags ปัจจุบันของ subscriber จะไม่มีแท็กนั้นแล้ว

Event IDs, Delivery IDs และ Idempotency

Event ID และ Delivery ID มีวัตถุประสงค์แตกต่างกัน

Event ID

Event ID ระบุเหตุการณ์ทางธุรกิจ โดยปรากฏใน:

• พร็อพเพอร์ตี id ระดับบนสุดของเพย์โหลด
• ส่วนหัวคำขอ X-Maildroppa-Event-Id
• ประวัติการส่ง

เหตุการณ์เดียวกันสามารถส่งไปยังปลายทางที่สมัครรับหลายรายการ การส่งเหล่านั้นจะใช้ Event ID ร่วมกัน

การลองส่งซ้ำและการเล่นซ้ำด้วยตนเองยังคงใช้ Event ID เดิม จัดเก็บ Event ID ที่ประมวลผลแล้วและทำให้การทำงานทางธุรกิจเป็น idempotent เพื่อไม่ให้คำขอซ้ำสร้าง contact ซ้ำ ทำการดำเนินการที่ย้อนกลับไม่ได้ซ้ำ หรือใช้การเปลี่ยนแปลงเดิมสองครั้ง

Delivery ID

Delivery ID ระบุระเบียนการส่งหนึ่งรายการ โดยปรากฏใน:

• ส่วนหัวคำขอ X-Maildroppa-Delivery-Id
• ประวัติการส่ง

การส่งไปยังแต่ละปลายทางจะมี Delivery ID ของตนเอง การเล่นซ้ำด้วยตนเองจะสร้าง Delivery ID ใหม่ แต่ยังคง Event ID เดิม

ใช้ Delivery ID สำหรับการติดตามทางเทคนิคและการสนับสนุน ใช้ Event ID สำหรับการป้องกันการประมวลผลซ้ำในระดับธุรกิจ

การส่งการตอบกลับ HTTP ที่ถูกต้อง

Maildroppa จัดประเภทการตอบกลับดังนี้:

• การตอบกลับ 2xx ใด ๆ จะทำให้การส่งสำเร็จ
• การตอบกลับ 408 Request Timeout, 429 Too Many Requests และ 5xx เป็นข้อผิดพลาดชั่วคราวและอาจลองส่งซ้ำได้
• ความล้มเหลวของเครือข่ายที่อาจเกิดขึ้นชั่วคราวจะถูกลองส่งซ้ำ
• จะไม่ติดตามการเปลี่ยนเส้นทางและการตอบกลับ 3xx อื่น ๆ และถือเป็นข้อผิดพลาดถาวร
• การตอบกลับ 4xx อื่น ๆ ถือเป็นข้อผิดพลาดถาวรและจะไม่ลองส่งซ้ำ

ส่ง 200, 202 หรือ 204 เฉพาะเมื่อรับเหตุการณ์อย่างปลอดภัยแล้ว หากการประมวลผลใช้เวลา ให้จัดเก็บเหตุการณ์ก่อน แล้วส่งการตอบกลับสำเร็จก่อนทำงานที่ช้ากว่าแบบอะซิงโครนัส

อย่าส่งการเปลี่ยนเส้นทางไปยัง URL webhook อื่น ให้กำหนด URL สุดท้ายใน Maildroppa แทน

กำหนดการลองส่งซ้ำอัตโนมัติ

การส่งใน production สามารถพยายามส่ง HTTP ได้สูงสุดเจ็ดครั้ง

หลังเกิดข้อผิดพลาดที่ลองส่งซ้ำได้ Maildroppa จะกำหนดเวลาส่งครั้งถัดไปด้วยช่วงเวลาดังนี้:

1. หลังความพยายามครั้งที่ 1: 1 นาที
2. หลังความพยายามครั้งที่ 2: 5 นาที
3. หลังความพยายามครั้งที่ 3: 30 นาที
4. หลังความพยายามครั้งที่ 4: 2 ชั่วโมง
5. หลังความพยายามครั้งที่ 5: 12 ชั่วโมง
6. หลังความพยายามครั้งที่ 6: 24 ชั่วโมง

หากความพยายามครั้งที่ 7 ยังคงได้รับข้อผิดพลาดที่ลองส่งซ้ำได้ การส่งจะกลายเป็น Dead และจะไม่มีการกำหนดความพยายามอัตโนมัติเพิ่มเติม

กำหนดการนี้วัดจากความพยายามที่ล้มเหลวแต่ละครั้ง เวลาส่งจริงอาจช้ากว่าเล็กน้อยเนื่องจากการส่งถูกประมวลผลแบบอะซิงโครนัสและยังอยู่ภายใต้ขีดจำกัดการป้องกันระบบ

แก้ไขปัญหาชั่วคราวของตัวรับก่อนเวลา “Next retry” ที่แสดงเมื่อเป็นไปได้ หากความพยายามอัตโนมัติสิ้นสุดแล้ว ให้ใช้ Replay หลังจากตัวรับกลับมาพร้อมใช้งาน

ทำความเข้าใจประวัติการส่ง

ประวัติการส่งเป็นของปลายทางที่เลือกอยู่ในปัจจุบัน URL ปลายทางจะแสดงในส่วนหัวเพื่อให้คุณยืนยันได้ว่ากำลังดูประวัติของรายการใด

ใช้ตัวกรองต่อไปนี้:

• All — แสดงการส่งทั้ง production และการทดสอบ
• Production — แสดงเฉพาะการส่งเหตุการณ์จริง
• Test — แสดงเฉพาะการทดสอบด้วยตนเอง

คลิก “Refresh” เพื่อเรียกดูสถานะล่าสุด ไม่จำเป็นต้องเปิดประวัติไว้ขณะที่ Maildroppa ส่งหรือลองส่งการส่งซ้ำ

หน้าเว็บจะแสดงการส่งล่าสุด 50 รายการที่ตรงกับตัวกรองที่เลือก

คอลัมน์การส่ง

แต่ละแถวประกอบด้วย:

• Created — เวลาที่สร้างระเบียนการส่ง
• State — Pending, Success, Failed หรือ Dead
• HTTP — สถานะการตอบกลับ จำนวนความพยายาม ระยะเวลา และเวลาลองส่งครั้งถัดไปเมื่อเกี่ยวข้อง
• Subscriber — อีเมล subscriber เมื่อเหตุการณ์เชื่อมโยงกับ subscriber
• Delivery — ประเภทเหตุการณ์ Event ID และ Delivery ID
• Actions — Replay เมื่อการส่งมีสิทธิ์เล่นซ้ำ

หากไม่มีการส่งคำขอ HTTP คอลัมน์ HTTP จะแสดง “No HTTP attempt” ซึ่งอาจเกิดขึ้นเมื่อ Maildroppa ปฏิเสธคำขอก่อนส่ง เช่น Signing secret หายไปหรือไม่สามารถใช้ปลายทางที่บันทึกไว้อย่างปลอดภัยได้อีกต่อไป

เมื่อมีข้อมูล แถวจะแสดง Error และ Response excerpt ที่ตัวรับส่งกลับมาด้วย อย่าส่ง secret หรือข้อมูลส่วนบุคคลที่ละเอียดอ่อนใน body การตอบกลับ webhook เพราะส่วนหนึ่งของการตอบกลับนั้นอาจปรากฏในบันทึกการส่งของบัญชี

สถานะการส่ง

Pending หมายถึงการส่งกำลังรอความพยายามครั้งแรกหรือการลองส่งซ้ำตามกำหนด “Next retry” จะแสดงเมื่อมีการกำหนดความพยายามครั้งถัดไปแล้ว

Success หมายถึงตัวรับส่งการตอบกลับ 2xx ไม่จำเป็นต้องมีความพยายามอัตโนมัติเพิ่มเติม

Failed หมายถึงการส่งสิ้นสุดลงด้วยปัญหาที่ลองส่งซ้ำไม่ได้ ถูกปฏิเสธก่อนความพยายาม HTTP หรือถูกหยุดก่อนส่ง

Dead หมายถึงใช้ความพยายามอัตโนมัติทั้งหมดสำหรับปัญหาที่ลองส่งซ้ำได้แล้ว โดยยังไม่ได้รับการตอบกลับที่สำเร็จ

ระยะเวลาการเก็บประวัติ

ระเบียนการส่งจะถูกเก็บไว้ในระยะเวลาจำกัด:

• การส่ง production ที่สำเร็จ: 30 วัน
• การส่ง production ที่ล้มเหลว: 90 วัน
• การส่ง production ที่ Dead: 90 วัน
• การส่งทดสอบ: 30 วัน

เก็บบันทึกการผสานรวมของคุณเองเมื่อต้องการประวัติการตรวจสอบที่นานกว่านี้ จัดเก็บ Event ID และ Delivery ID แต่อย่าจัดเก็บ secret โดยไม่จำเป็น

การเล่นซ้ำการส่ง

คลิก “Replay” เมื่อควรลองส่งการส่ง production ที่เสร็จสมบูรณ์อีกครั้ง

Replay ใช้ได้กับการส่ง production ที่มีสถานะ Success, Failed หรือ Dead ไม่สามารถใช้ขณะที่การส่งเป็น Pending และการส่งทดสอบไม่สามารถเล่นซ้ำได้

การเล่นซ้ำจะ:

• สร้างการส่ง Pending ใหม่
• สร้าง Delivery ID ใหม่
• คง Event ID เดิมไว้
• คงประเภทเหตุการณ์และเพย์โหลด JSON เดิมไว้
• ใช้ URL เป้าหมายและ snapshot ของ custom header ที่บันทึกไว้เดิม
• ใช้ Signing secret ปัจจุบันเมื่อเตรียมคำขอใหม่

Replay จะไม่สร้างเพย์โหลดใหม่จากข้อมูลปัจจุบันของ subscriber แต่จะส่ง snapshot ของเหตุการณ์เดิมอีกครั้ง วิธีนี้ทำให้ตรวจสอบย้อนหลังได้และป้องกันไม่ให้เหตุการณ์ในอดีตเปลี่ยนความหมายโดยไม่แจ้งให้ทราบ

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

ตรวจสอบให้แน่ใจว่าปลายทางเป็น Active ก่อนเล่นซ้ำ หากปลายทาง inactive การเล่นซ้ำที่อยู่ในคิวจะไม่สามารถส่งสำเร็จ

เนื่องจากตัวรับอาจดำเนินการทางธุรกิจเสร็จแล้ว แม้ Maildroppa จะไม่ได้รับการตอบกลับสำเร็จ การเล่นซ้ำจึงอาจทำให้เกิดคำขอซ้ำ การป้องกันซ้ำด้วย Event ID จะช่วยป้องกันไม่ให้ระบบที่เชื่อมต่อดำเนินการนั้นซ้ำ

การแก้ไขปลายทาง

คลิก “Edit” เพื่อเปลี่ยน URL การเลือกเหตุการณ์ custom headers หรือสถานะ active

ก่อนบันทึก:

1. ยืนยันว่า URL ใหม่พร้อมใช้งานแล้ว
2. เว้นค่าของ header ที่จัดเก็บไว้ให้ว่างเมื่อควรคงค่าเดิม
3. ป้อนค่าใหม่สำหรับ header ที่เปลี่ยนชื่อทุกตัว
4. ตรวจสอบการเลือกเหตุการณ์เพื่อไม่ให้ลบการแจ้งเตือนที่จำเป็นโดยไม่ตั้งใจ
5. บันทึกและส่ง Test webhook ใหม่

โปรดจำไว้ว่าการส่งที่อยู่ในคิวจะคง URL และ snapshot ของ custom header เดิมไว้ ทดสอบการกำหนดค่าใหม่สำหรับการส่งในอนาคต แทนการสมมติว่าจะเปลี่ยนคำขอเก่าที่อยู่ในคิว

การปิดใช้งานปลายทาง

ใช้สวิตช์ On/Off เมื่อต้องการหยุดการผสานรวมชั่วคราวโดยไม่ลบการกำหนดค่าและประวัติ

เมื่อปิดปลายทาง:

• เหตุการณ์ใหม่จะไม่ถูกเข้าคิวสำหรับปลายทางนั้นอีก
• การส่ง Pending ที่ยังไม่ได้ถูกจับไปส่งจะถูกทำเครื่องหมาย Failed
• Test จะถูกปิดใช้งาน
• ปลายทางยังคงพร้อมสำหรับการแก้ไขและเปิดใช้งานภายหลัง

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

เหตุการณ์ที่พลาดไปขณะที่ปลายทาง inactive จะไม่ถูกเติมย้อนหลังเมื่อเปิดใช้งานอีกครั้ง

การลบปลายทาง

คลิก “Delete” และยืนยันคำเตือนเมื่อไม่ต้องการให้ปลายทางนี้มีอยู่อีกต่อไป

การลบจะนำปลายทางออกจากหน้า หยุดการส่งเหตุการณ์ในอนาคต และทำให้การส่ง Pending ที่ยังไม่ได้ถูกจับไปส่งล้มเหลว

Delete ไม่ใช่วิธีหยุดชั่วคราว หากอาจต้องใช้การกำหนดค่าหรือประวัติที่แสดงอีก ให้ใช้สวิตช์ On/Off

ก่อนลบ ให้บันทึก Event ID หรือ Delivery ID ที่ยังจำเป็นต่อการตรวจสอบการผสานรวมของคุณ

การแก้ไขปัญหา

ไม่สามารถบันทึกปลายทางได้

ตรวจสอบว่า:

• URL ขึ้นต้นด้วย https://
• URL ใช้ hostname สาธารณะและพอร์ต 443
• URL ไม่มีตัวแปร ข้อมูลเข้าสู่ระบบ หรือ fragment
• เลือกเหตุการณ์อย่างน้อยหนึ่งรายการ
• Custom header ทุกตัวมีชื่อและค่าที่ไม่ซ้ำกัน
• ไม่ได้ใช้ส่วนหัว Maildroppa และ HTTP ที่สงวนไว้เป็นชื่อที่กำหนดเอง

Test ถูกปิดใช้งาน

Test ใช้ได้เฉพาะกับปลายทางที่ Active เปิดปลายทางหรือแก้ไขแล้วเลือก “Active” จากนั้นบันทึกก่อนทดสอบ

Test แสดงว่าไม่มีความพยายาม HTTP

สร้าง Signing secret หากสถานะเป็น Missing ตรวจสอบด้วยว่า hostname ปลายทางเป็นสาธารณะและยังแก้ไขได้อย่างถูกต้อง

คำขออาจถูกปฏิเสธก่อนส่งเมื่อ secret, URL, custom headers หรือการตรวจสอบความปลอดภัยของปลายทางไม่ถูกต้อง

ตัวรับส่ง 401 หรือ 403

ตรวจสอบชื่อ Custom header และข้อมูลรับรองที่บันทึกไว้ แก้ไขปลายทางและป้อนค่าอีกครั้งหากมีการเปลี่ยนแปลง

ตรวจสอบด้วยว่าตัวรับไม่ได้สับสนระหว่างข้อมูลรับรอง API ของตนเองกับลายเซ็น Maildroppa ส่วนหัว authorization ที่กำหนดเองและ X-Maildroppa-Signature มีวัตถุประสงค์ต่างกันและสามารถตรวจสอบแยกกันได้

ตัวรับส่งการเปลี่ยนเส้นทาง

Maildroppa ไม่ติดตามการเปลี่ยนเส้นทาง เปลี่ยน URL ปลายทางเป็น URL HTTPS สาธารณะสุดท้ายแล้วทดสอบอีกครั้ง

ลายเซ็นไม่ตรงกัน

ยืนยันว่าตัวรับ:

• ใช้ Signing secret ปัจจุบัน
• ใช้ค่า X-Maildroppa-Timestamp ที่ตรงกันทุกประการ
• ลงนาม <timestamp>.<raw request body>
• ใช้ HMAC-SHA256 และผลลัพธ์เลขฐานสิบหกตัวพิมพ์เล็ก
• เปรียบเทียบค่าทั้งหมดรวม v1=
• เปรียบเทียบก่อนที่การแยกวิเคราะห์ JSON จะเปลี่ยนแปลง body

เหตุการณ์เดียวกันมาถึงมากกว่าหนึ่งครั้ง

อาจเกิดขึ้นหลังการหยุดชะงักของเครือข่าย การลองส่งซ้ำ หรือการเล่นซ้ำด้วยตนเอง เป็นเรื่องปกติที่ระบบส่ง webhook จะรับประกันการส่งอย่างน้อยหนึ่งครั้ง แทนการส่งเพียงครั้งเดียวเท่านั้น

ใช้ Event ID เป็นคีย์ idempotency ส่งการตอบกลับ 2xx เมื่อได้รับ Event ID ที่ประมวลผลแล้วอีกครั้งและไม่จำเป็นต้องดำเนินการเพิ่มเติม

การส่งอยู่ในสถานะ Pending

ดู “Next retry” ในคอลัมน์ HTTP การตอบกลับ 408, 429, 5xx ที่ลองส่งซ้ำได้ หรือความล้มเหลวของเครือข่ายชั่วคราว จะทำให้การส่งคงสถานะ Pending จนกว่าจะถึงความพยายามถัดไปตามกำหนด

คลิก “Refresh” หลังเวลาลองส่งซ้ำเพื่อโหลดสถานะล่าสุด

การส่งอยู่ในสถานะ Dead

ใช้ความพยายามอัตโนมัติทั้งหมดแล้ว แก้ไขตัวรับก่อน ตรวจสอบว่าปลายทางเป็น Active ส่ง Test webhook แล้วใช้ Replay กับการส่ง production

รายการตรวจสอบ Production ที่แนะนำ

ก่อนพึ่งพาปลายทางใน production ให้ยืนยันสิ่งต่อไปนี้ทั้งหมด:

1. ตัวรับใช้ URL HTTPS สาธารณะที่เสถียรพร้อมใบรับรองที่ถูกต้อง
2. จัดเก็บ Signing secret ไว้นอกซอร์สโค้ด
3. ตรวจสอบลายเซ็นกับ raw body ที่ไม่มีการเปลี่ยนแปลง
4. ปฏิเสธ timestamp เก่าตามช่วงเวลาที่ยอมรับได้ซึ่งมีการบันทึกไว้
5. ตัวรับจัดเก็บและป้องกันการประมวลผล Event ID ซ้ำ
6. ตัวรับบันทึก Event ID และ Delivery ID เพื่อการติดตาม
7. การประมวลผลที่ใช้เวลานานเกิดขึ้นหลังรับเหตุการณ์ไว้อย่างถาวรแล้ว
8. ส่งการตอบกลับ 2xx เฉพาะสำหรับเหตุการณ์ที่รับแล้ว
9. จัดเก็บข้อมูลรับรองที่กำหนดเองไว้ใน headers แทน URL
10. เลือกเฉพาะประเภทเหตุการณ์ที่จำเป็น
11. Test webhook สำเร็จและแสดงอย่างถูกต้องในประวัติการส่ง
12. ระบบตรวจสอบแจ้งเตือนเมื่อการส่ง production เริ่มส่งข้อผิดพลาด

เมื่อมีมาตรการป้องกันเหล่านี้ หน้า Webhooks จะมอบทั้งสองด้านของการผสานรวมที่เชื่อถือได้: การส่งเหตุการณ์ไปยังแอปพลิเคชันของคุณอย่างปลอดภัย และประวัติการดำเนินงานที่ชัดเจนภายใน Maildroppa