ภาพรวม Webhook
Webhook คือวิธีที่เร็วที่สุดในการเชื่อมต่อ Ocriva เข้ากับระบบของคุณ แทนที่จะต้องถามซ้ำ ๆ ว่า "เสร็จแล้วหรือยัง?" Ocriva จะส่งการแจ้งเตือนไปยัง Server ของคุณโดยตรงทันทีที่มีเหตุการณ์เกิดขึ้น ไม่ว่าจะเป็นเอกสารที่ประมวลผลเสร็จ Batch ที่เสร็จสิ้น หรือ Template ที่ถูกอัปเดต
Webhook คืออะไร?
Webhook คือ HTTP POST Request ที่ Ocriva ส่งไปยัง URL ที่คุณกำหนดทุกครั้งที่เกิดเหตุการณ์เฉพาะขึ้น Server ของคุณจะได้รับ JSON Payload พร้อมรายละเอียดทั้งหมดของเหตุการณ์นั้น และสามารถดำเนินการได้ทันที ไม่ว่าจะเป็นการบันทึกข้อมูลลงฐานข้อมูล ส่งแจ้งเตือนใน Slack เรียกใช้ Workflow หรืออะไรก็ตามที่ระบบของคุณต้องการ
Webhook ทำงานตามโมเดล Publish/Subscribe ที่เรียบง่าย:
- คุณลงทะเบียน URL ของ Endpoint ใน Ocriva และเลือก Event ที่ต้องการรับ
- เมื่อ Event นั้นเกิดขึ้น Ocriva จะส่ง HTTP POST ไปยัง URL ของคุณพร้อม Payload ของ Event
- Server ของคุณประมวลผล Payload และส่งคืน Status Code
2xxเพื่อยืนยันการรับ
TIP
ใช้ Webhook แทนการ Poll API เพื่อตรวจสอบสถานะ การ Poll สิ้นเปลือง API Credit และเพิ่ม Latency โดยไม่จำเป็น Webhook ส่งข้อมูลถึงคุณทันทีที่พร้อม — โดยปกติภายในไม่กี่วินาที
Webhook ในกระบวนการ DAT Pipeline
กระบวนการหลักของ Ocriva — Document → AI → Transform — แปลงไฟล์ดิบให้กลายเป็นข้อมูลที่มีโครงสร้าง Webhook คือสะพานที่นำข้อมูลเหล่านั้นจาก Ocriva เข้าสู่ระบบของคุณโดยอัตโนมัติ
แอปของคุณ Ocriva ระบบของคุณ
| | |
|-- Upload ---->| |
| |-- AI Extraction |
| |-- Transform / Format |
| |-- Webhook POST ----------------->|
| | ประมวลผลข้อมูล|
| | บันทึกผลลัพธ์ |
| | แจ้งผู้ใช้งาน |Webhook จะทำงานหลังจาก Ocriva ประมวลผลเสร็จสมบูรณ์แล้ว ดังนั้น Endpoint ของคุณจะได้รับผลลัพธ์สุดท้ายที่มีโครงสร้างแล้วเสมอ
Webhook เทียบกับ Polling
| Webhooks | Polling | |
|---|---|---|
| Latency | Near Real-time (ไม่กี่วินาที) | ขึ้นอยู่กับช่วงเวลาที่ Poll |
| การใช้ API | 1 ครั้งต่อ Event | หลายครั้ง ส่วนใหญ่ได้ผลว่า "ยังประมวลผลอยู่" |
| ความซับซ้อน | ต้องมี Public Endpoint | Loop ฝั่ง Client ง่ายกว่า |
| Scalability | รองรับปริมาณ Event สูง | ประสิทธิภาพลดลงเมื่อปริมาณสูง |
| Event ที่พลาด | มีระบบ Retry อัตโนมัติ | เสี่ยงพลาด Event ระหว่างรอบ Poll |
สำหรับ Integration ที่ใช้งานจริงที่มีปริมาณงานพอสมควร Webhook เป็นตัวเลือกที่ดีกว่าอย่างชัดเจน
ตัวอย่างการทำงาน: ประมวลผลใบแจ้งหนี้
นี่คือสิ่งที่เกิดขึ้นตั้งแต่ต้นจนจบเมื่อคุณประมวลผลใบแจ้งหนี้และรับผลลัพธ์ผ่าน Webhook:
- Upload — แอปของคุณ Upload
invoice_march.pdfผ่าน Ocriva API - Processing — AI ของ Ocriva ดึงข้อมูล (ผู้ขาย ยอดเงิน รายการสินค้า วันครบกำหนด) โดยใช้ Template ที่คุณตั้งค่า
- Webhook ทำงาน — Ocriva ส่ง Event
document.processedไปยัง Endpoint ที่ลงทะเบียนไว้ - Server ของคุณรับ — Endpoint ได้รับ JSON Payload พร้อมข้อมูลทุกฟิลด์ที่ดึงออกมาแล้ว
- ระบบของคุณดำเนินการ — คุณบันทึกใบแจ้งหนี้ลงใน ERP เรียกใช้ Workflow อนุมัติ หรือแจ้ง Finance Team
{
"eventType": "document.processed",
"eventId": "evt_1743418800000_inv9x2",
"timestamp": "2026-03-31T12:00:00.000Z",
"organizationId": "org_abc123",
"projectId": "proj_xyz789",
"payload": {
"id": "doc_march_inv",
"fileName": "invoice_march.pdf",
"status": "completed",
"extractedData": {
"invoiceNumber": "INV-2026-0331",
"vendor": "Acme Supplies Co.",
"totalAmount": 15420.00,
"currency": "THB",
"dueDate": "2026-04-30"
},
"confidence": 0.97,
"processingTime": 3241,
"processedAt": "2026-03-31T12:00:00.000Z"
}
}Server ของคุณได้รับ Payload นี้และสามารถดำเนินการได้ทันที โดยไม่ต้อง Poll และไม่ต้องรอ
ภาพรวมความปลอดภัย
ทุก Webhook Delivery สามารถมีลายเซ็นการเข้ารหัสเพื่อให้คุณยืนยันได้ว่า Request นั้นมาจาก Ocriva จริง ๆ และไม่ถูกแก้ไขระหว่างทาง
เมื่อคุณกำหนด Secret บน Webhook Endpoint Ocriva จะเซ็นชื่อทุก Delivery ด้วย HMAC-SHA256 และใส่ลายเซ็นใน Header X-Webhook-Signature Server ของคุณคำนวณลายเซ็นซ้ำโดยใช้ Secret เดียวกันแล้วเปรียบเทียบ ถ้าตรงกัน Request นั้นถูกต้อง
IMPORTANT
ใช้ HTTPS Endpoint เสมอในสภาพแวดล้อม Production HTTP Endpoint ส่ง Webhook Payload — รวมถึงข้อมูลเอกสารที่ดึงออกมา — ในรูปแบบ Plain Text ผ่านเครือข่าย HTTPS เข้ารหัสการเชื่อมต่อตั้งแต่ต้นจนปลาย
Header ที่มาพร้อมกับ Webhook
ทุก Webhook Request จะมี Header มาตรฐาน 2 ตัว:
| Header | ตัวอย่างค่า | คำอธิบาย |
|---|---|---|
X-Webhook-Event | document.processed | ประเภท Event ที่ทำให้เกิด Delivery นี้ |
X-Webhook-Signature | sha256=a1b2c3... | ลายเซ็น HMAC-SHA256 ของ Request Body (เฉพาะเมื่อตั้งค่า Secret) |
Content-Type | application/json | Payload เป็น JSON เสมอ |
นโยบาย Retry
ถ้า Endpoint ของคุณไม่ส่งคืน Status Code 2xx — หรือ Timeout — Ocriva จะ Retry อัตโนมัติ:
- 3 ครั้งทั้งหมด (1 ครั้งแรก + Retry อีก 2 ครั้ง)
- Exponential Backoff ระหว่างการ Retry
- ทุก Attempt ถูกบันทึกพร้อม Status Code เวลาตอบสนอง และข้อความ Error
ซึ่งหมายความว่าแม้ Server ของคุณจะมีปัญหาชั่วคราว (Restart สั้น ๆ หรือ Cold Start ช้า) คุณก็จะไม่พลาด Event อย่างถาวร
ขั้นตอนถัดไป
- ประเภท Event และ Payload — Reference ครบถ้วนสำหรับทุก Event Type พร้อมตัวอย่าง Payload
- การตั้งค่าและทดสอบ — สร้าง Endpoint แรก ยืนยันลายเซ็น และทดสอบแบบ Local
