คู่มือ
API integration คืออะไร อธิบายสำหรับธุรกิจท่องเที่ยว
API integration คือการเชื่อมต่อที่ช่วยให้ระบบซอฟต์แวร์สองระบบแลกเปลี่ยนข้อมูลและสั่งการได้โดยไม่ต้องมีคนพิมพ์ซ้ำ คู่มือนี้อธิบายวิธีการทำงานผ่านการจองโรงแรมหนึ่งรายการที่เดินทางระหว่างนักเดินทาง แพลตฟอร์มการจอง API ของซัพพลายเออร์ และเกตเวย์ชำระเงิน
- หนึ่งคำขอ หนึ่งคำตอบ
- REST, XML, SOAP และ webhook
- ติดตามการจองหนึ่งรายการผ่านสี่ระบบ
- การทดสอบการเชื่อมต่อทำอย่างไร
คำจำกัดความ
API integration คืออะไร ในภาษาที่เข้าใจง่าย
API ย่อมาจาก application programming interface: ชุดกฎที่ระบบหนึ่งเผยแพร่เพื่อให้ซอฟต์แวร์อื่นสื่อสารกับมันได้ API integration คือการเชื่อมแพลตฟอร์มของคุณเข้ากับอินเทอร์เฟซเหล่านั้น เพื่อให้ข้อมูลไหลและการทำงานเกิดขึ้นโดยอัตโนมัติ
ในธุรกิจท่องเที่ยว แพลตฟอร์มนั้นมักเป็นระบบจองอย่าง ซอฟต์แวร์จองท่องเที่ยว และอินเทอร์เฟซเป็นของซัพพลายเออร์ เกตเวย์ชำระเงิน หรือเครื่องมือทางธุรกิจ หน้า การเชื่อมต่อ API ท่องเที่ยว ของเราอธิบายว่า PHPTRAVELS ส่งมอบการเชื่อมต่อเหล่านี้อย่างไร และ การเชื่อมต่อทั้งหมด แสดงรายชื่อซัพพลายเออร์ที่เชื่อมต่อแล้ว
แลกเปลี่ยนข้อมูล
ราคา ห้องว่าง ข้อมูลลูกค้า และการอัปเดตสถานะเคลื่อนย้ายระหว่างระบบในรูปแบบที่มีโครงสร้าง
ทำงานอัตโนมัติ
ค้นหา จอง ชำระเงิน ยกเลิก และกระทบยอดเกิดขึ้นเป็นคำขอ ไม่ใช่ขั้นตอนที่ใครสักคนต้องทำซ้ำด้วยมือ
ติดตามผลลัพธ์
ทุกการเรียกมีหมายเลขอ้างอิง ดังนั้นการจองที่ล้มเหลวจึงสืบย้อนกลับไปยังคำขอที่เป็นต้นเหตุได้
คำขอ
POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{ "city": "DXB", "check_in": "2026-11-12", "check_out": "2026-11-14", "guests": 2, "currency": "USD"}คำตอบ
HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{ "hotel": "Palm Marina Hotel", "room": "Deluxe, 2 adults", "rate": { "amount": 438.00, "currency": "USD" }, "refundable": true, "rate_key": "rk_19d2c7"}องค์ประกอบของการเรียก API หนึ่งครั้ง
- 1
Endpoint และ method
ที่อยู่ของการดำเนินการและคำกริยาที่ใช้กับมัน: POST ไปที่ availability หมายถึงค้นหาห้องพัก
- 2
การยืนยันตัวตน
คีย์ โทเค็น หรือลายเซ็นพิสูจน์ว่าใครเป็นผู้เรียก ซัพพลายเออร์ออกข้อมูลรับรองแยกกันสำหรับ sandbox และ production
- 3
Payload
ข้อมูลนำเข้าที่มีโครงสร้าง: เมือง วันที่ จำนวนผู้เข้าพัก และสกุลเงิน เอกสารของซัพพลายเออร์กำหนดทุกฟิลด์
- 4
รหัสสถานะ
ตัวเลขที่บอกว่าการเรียกเป็นอย่างไร: 200 คือสำเร็จ, 4xx คือปัญหาที่คำขอ, 5xx คือปัญหาฝั่งซัพพลายเออร์
- 5
รหัสคำขอ
ตัวระบุที่ทั้งสองฝ่ายเก็บไว้ เมื่อฝ่ายสนับสนุนถามว่าเกิดอะไรขึ้นกับการจอง นี่คือสิ่งที่พวกเขาค้นหา
- 6
เนื้อหาคำตอบ
คำตอบในรูปแบบของซัพพลายเออร์ ซึ่งแพลตฟอร์มของคุณจับคู่เข้ากับห้องพัก ราคา และนโยบายของตัวเอง
หนึ่งการจอง สี่ระบบ
API integration ทำอะไรระหว่างการจองโรงแรม
ติดตามการเข้าพักสองคืนตั้งแต่ค้นหาจนถึงวอชเชอร์ ลูกศรทุกเส้นคือการเรียก API หนึ่งครั้ง นักเดินทางเห็นเพียงขั้นแรกและขั้นสุดท้าย
- 01ค้นหาโรงแรมในดูไบ สองคืน ผู้เข้าพักสองคนจาก: นักเดินทาง, ถึง: แพลตฟอร์มการจอง
- 02คำขอห้องว่างพร้อมวันที่ ผู้เข้าพัก และสกุลเงินจาก: แพลตฟอร์มการจอง, ถึง: API ซัพพลายเออร์
- 03ห้องพัก ราคา นโยบาย และ rate keyจาก: API ซัพพลายเออร์, ถึง: แพลตฟอร์มการจอง
- 04แสดงผลลัพธ์พร้อมมาร์กอัปและสกุลเงินของคุณจาก: แพลตฟอร์มการจอง, ถึง: นักเดินทาง
- 05ตรวจสอบราคาซ้ำบน rate key ที่เลือกก่อนชำระเงินจาก: แพลตฟอร์มการจอง, ถึง: API ซัพพลายเออร์
- 06ขออนุมัติการชำระเงินสำหรับยอดรวมจาก: แพลตฟอร์มการจอง, ถึง: เกตเวย์ชำระเงิน
- 07อนุมัติแล้ว ได้รับ webhook ที่ลงนามจาก: เกตเวย์ชำระเงิน, ถึง: แพลตฟอร์มการจอง
- 08คำขอจองพร้อมข้อมูลผู้เข้าพักจาก: แพลตฟอร์มการจอง, ถึง: API ซัพพลายเออร์
- 09หมายเลขยืนยันและเงื่อนไขการยกเลิกจาก: API ซัพพลายเออร์, ถึง: แพลตฟอร์มการจอง
- 10วอชเชอร์ ใบแจ้งหนี้ และหมายเลขอ้างอิงการจองจาก: แพลตฟอร์มการจอง, ถึง: นักเดินทาง
- 01นักเดินทางแพลตฟอร์มการจองค้นหาโรงแรมในดูไบ สองคืน ผู้เข้าพักสองคน
- 02แพลตฟอร์มการจองAPI ซัพพลายเออร์คำขอห้องว่างพร้อมวันที่ ผู้เข้าพัก และสกุลเงิน
- 03API ซัพพลายเออร์แพลตฟอร์มการจองห้องพัก ราคา นโยบาย และ rate key
- 04แพลตฟอร์มการจองนักเดินทางแสดงผลลัพธ์พร้อมมาร์กอัปและสกุลเงินของคุณ
- 05แพลตฟอร์มการจองAPI ซัพพลายเออร์ตรวจสอบราคาซ้ำบน rate key ที่เลือกก่อนชำระเงิน
- 06แพลตฟอร์มการจองเกตเวย์ชำระเงินขออนุมัติการชำระเงินสำหรับยอดรวม
- 07เกตเวย์ชำระเงินแพลตฟอร์มการจองอนุมัติแล้ว ได้รับ webhook ที่ลงนาม
- 08แพลตฟอร์มการจองAPI ซัพพลายเออร์คำขอจองพร้อมข้อมูลผู้เข้าพัก
- 09API ซัพพลายเออร์แพลตฟอร์มการจองหมายเลขยืนยันและเงื่อนไขการยกเลิก
- 10แพลตฟอร์มการจองนักเดินทางวอชเชอร์ ใบแจ้งหนี้ และหมายเลขอ้างอิงการจอง
แพลตฟอร์มตรงกลางคือที่ที่ API integration อยู่: มันแปลระหว่างหน้าจอของนักเดินทางกับรูปแบบของซัพพลายเออร์แต่ละราย และเก็บหมายเลขอ้างอิงทุกรายการ
ลำดับเดียวกันนี้ใช้กับ ซอฟต์แวร์จองตั๋วเครื่องบิน ผ่าน GDS, ซอฟต์แวร์ผู้ประกอบการนำเที่ยว ผ่านซัพพลายเออร์กิจกรรม และ เชื่อมต่อเพย์เมนต์เกตเวย์ ผ่านเกตเวย์ใดก็ได้ เปลี่ยนเพียงชื่อฟิลด์เท่านั้น
รูปแบบการเชื่อมต่อ
REST, XML, SOAP, webhook และ GraphQL
ซัพพลายเออร์เผยแพร่อินเทอร์เฟซในรูปแบบที่ต่างกัน รูปแบบถูกกำหนดโดยเอกสารของซัพพลายเออร์ ไม่ใช่ความชอบ ดังนั้นแพลตฟอร์มท่องเที่ยวจึงต้องรองรับทุกแบบ
REST และ JSON
JSON- รูปแบบข้อมูล
- เอกสาร JSON
- การส่งผ่าน
- HTTP method: GET, POST, PUT, DELETE
- พบบ่อยในธุรกิจท่องเที่ยว
- API เที่ยวบิน โรงแรม กิจกรรม และการชำระเงินรุ่นใหม่
- จุดแข็ง
- Payload กะทัดรัดและมีเครื่องมือสำหรับนักพัฒนาอย่างกว้างขวาง
- ข้อควรระวัง
- ข้อกำหนดไม่เคร่งครัด ซัพพลายเออร์แต่ละรายตีความ REST ต่างกัน
XML และ SOAP
XML- รูปแบบข้อมูล
- เอกสาร XML มักมี schema ที่เข้มงวด
- การส่งผ่าน
- HTTP POST พร้อม SOAP envelope หรือ XML ธรรมดา
- พบบ่อยในธุรกิจท่องเที่ยว
- GDS, bedbank และระบบโรงแรมและทัวร์ที่ใช้มานาน
- จุดแข็ง
- สัญญาที่เป็นทางการ ลายเซ็น และนิยามบริการ
- ข้อควรระวัง
- ข้อความยืดยาวและการแยกวิเคราะห์หนักกว่า
Webhook
EVENT- รูปแบบข้อมูล
- JSON หรือ XML ที่อีกฝ่ายส่งมาให้
- การส่งผ่าน
- HTTP POST ไปยัง URL ที่คุณลงทะเบียน
- พบบ่อยในธุรกิจท่องเที่ยว
- ผลการชำระเงิน การเปลี่ยนสถานะการจอง การอัปเดตการออกตั๋ว
- จุดแข็ง
- ไม่ต้อง polling แพลตฟอร์มของคุณจะได้รับแจ้งเมื่อมีเหตุการณ์เกิดขึ้น
- ข้อควรระวัง
- ต้องตรวจสอบลายเซ็นและจัดการการส่งซ้ำ
GraphQL
QUERY- รูปแบบข้อมูล
- JSON ที่มีรูปร่างตาม query ที่คุณส่ง
- การส่งผ่าน
- HTTP endpoint เดียว
- พบบ่อยในธุรกิจท่องเที่ยว
- แพลตฟอร์มกระจายสินค้ารุ่นใหม่บางรายและ API ภายใน
- จุดแข็ง
- ขอเฉพาะฟิลด์ที่คุณต้องการ
- ข้อควรระวัง
- การรองรับจากซัพพลายเออร์ในธุรกิจท่องเที่ยวยังไม่แพร่หลาย
API integration เทียบกับ API development
เชื่อมผลิตภัณฑ์ของคุณเข้ากับอินเทอร์เฟซที่มีอยู่แล้ว ซัพพลายเออร์เป็นเจ้าของ API คุณสร้าง client การจับคู่ข้อมูล และกฎรอบ ๆ มัน
สร้างอินเทอร์เฟซที่ระบบอื่นใช้เชื่อมต่อกับผลิตภัณฑ์ของคุณ เช่น API B2B ที่เครื่องมือของตัวแทนของคุณเรียกใช้ได้ คุณเป็นเจ้าของสัญญาและเวอร์ชันของมัน
โครงการท่องเที่ยวจำนวนมากต้องการทั้งสองอย่าง: แพลตฟอร์มเชื่อมต่อซัพพลายเออร์ด้านหนึ่ง และเผยแพร่ API ของตัวเองให้ตัวแทนและพาร์ทเนอร์อีกด้านหนึ่ง
ก่อนและหลัง
อะไรเปลี่ยนไปเมื่อระบบถูกเชื่อมต่อกัน
ห้าขั้นตอนเดียวกันของการจอง ทำด้วยมือผ่านพอร์ทัลซัพพลายเออร์ และทำผ่าน API integration
ค้นหา
ตัวแทนเปิดพอร์ทัลซัพพลายเออร์ทีละราย แล้วคัดลอกราคาลงในใบเสนอราคา
การค้นหาครั้งเดียวกระจายไปยังซัพพลายเออร์ที่เชื่อมต่อทุกรายและส่งกลับเป็นรายการเดียว
ราคา
เพิ่มมาร์กอัปในสเปรดชีต ราคาอาจเปลี่ยนไปแล้วเมื่อส่งใบเสนอราคา
มาร์กอัป ภาษี และกฎสกุลเงินถูกใช้ตอนได้รับคำตอบ ราคาถูกตรวจสอบซ้ำก่อนชำระเงิน
จอง
ข้อมูลผู้เข้าพักถูกพิมพ์ซ้ำลงในพอร์ทัลซัพพลายเออร์ การพิมพ์ผิดกลายเป็นข้อผิดพลาดของการจอง
ข้อมูลถูกส่งครั้งเดียว ตรวจสอบความถูกต้อง และบันทึกพร้อมการยืนยันจากซัพพลายเออร์
ชำระเงิน
เก็บเงินแยกต่างหากแล้วค่อยจับคู่กับการจองในภายหลัง
การอนุมัติ การเรียกเก็บ และการคืนเงินผูกกับหมายเลขอ้างอิงการจอง
บริการหลังการขาย
การยกเลิกและการเปลี่ยนแปลงหมายถึงการเข้าสู่ระบบอีกครั้งและอีเมลอีกฉบับ
การเปลี่ยนแปลงและการยกเลิกทำผ่านการเชื่อมต่อเดียวกันและอัปเดตบันทึก
API integration ปรากฏตรงไหนในแพลตฟอร์มท่องเที่ยว
- ซอฟต์แวร์จองตั๋วเครื่องบินเช็กลิสต์สำหรับเอเจนซีและ OTA ที่ขายตั๋วเครื่องบิน
- ระบบจองโรงแรมการจองตรงบนเว็บไซต์โรงแรมของคุณเอง
- ซอฟต์แวร์ผู้ประกอบการนำเที่ยวการจอง โปรแกรมทัวร์ ตัวแทน B2B และปฏิบัติการ
- ระบบรถเช่าบริหารกองรถ สาขา และเงินมัดจำของคุณออนไลน์
- เชื่อมต่อเพย์เมนต์เกตเวย์ชำระเงิน, 3D Secure, คืนเงิน และ webhook
- CRM เอเจนซีท่องเที่ยวลีด ใบเสนอราคา การจอง และใบแจ้งหนี้ใน CRM เดียว
คำศัพท์
คำที่คุณจะพบในเอกสาร API
สิบสองคำที่ปรากฏในพอร์ทัลนักพัฒนาของซัพพลายเออร์เกือบทุกราย นิยามตามความหมายที่ใช้ในธุรกิจท่องเที่ยว
API
Application programming interface: กฎที่เผยแพร่สำหรับการสื่อสารกับระบบ
การยืนยันตัวตน
การพิสูจน์ว่าใครเป็นผู้เรียก ด้วยคีย์ API, bearer token, ลายเซ็น หรือที่อยู่ IP ที่ได้รับอนุมัติ
การรับรอง
การตรวจสอบการเชื่อมต่อของคุณโดยซัพพลายเออร์ก่อนออกข้อมูลรับรองสำหรับ production
Endpoint
ที่อยู่หนึ่งสำหรับการดำเนินการหนึ่ง เช่น ค้นหา จอง หรือยกเลิก
Idempotency
การส่งคำขอเดียวกันสองครั้งให้ผลลัพธ์เดียว ซึ่งป้องกันการจองและการเรียกเก็บเงินซ้ำ
การจับคู่ข้อมูล
การแปลฟิลด์ รหัส และชื่อของซัพพลายเออร์ให้เป็นโมเดลข้อมูลของแพลตฟอร์มคุณ
Payload
ข้อมูลที่บรรจุอยู่ในคำขอหรือคำตอบ โดยปกติเป็น JSON หรือ XML
Rate limit
จำนวนการเรียกที่ซัพพลายเออร์อนุญาตต่อวินาทีหรือต่อวันก่อนที่จะเริ่มปฏิเสธ
คำขอและคำตอบ
การเรียกหนึ่งครั้ง: แพลตฟอร์มของคุณถาม ซัพพลายเออร์ตอบ และทั้งสองฝ่ายบันทึกไว้
Sandbox
สภาพแวดล้อมทดสอบที่มีสินค้าคงคลังจำลองและบัตรทดสอบ ซึ่งไม่มีการจองหรือเรียกเก็บเงินจริง
รหัสสถานะ
ตัวเลข HTTP ที่สรุปผลลัพธ์: 200 สำเร็จ, 401 ไม่ได้รับอนุญาต, 429 เกิน rate limit, 500 ข้อผิดพลาดของซัพพลายเออร์
Webhook
การเรียกในทิศทางตรงกันข้าม: ซัพพลายเออร์หรือเกตเวย์แจ้งแพลตฟอร์มของคุณเมื่อมีเหตุการณ์เกิดขึ้น
การทดสอบและการกำหนดขอบเขต
การทดสอบ API integration ด้านท่องเที่ยวก่อนใช้งานจริงทำอย่างไร
การเชื่อมต่อจะเสร็จสมบูรณ์ก็ต่อเมื่อเส้นทางที่ผิดพลาดทำงานถูกต้อง การทดสอบกับ sandbox ของซัพพลายเออร์ครอบคลุมกรณีด้านล่างก่อนการรับรองและการเปลี่ยนไปใช้ข้อมูลรับรอง production
รันการทดสอบการเชื่อมต่อ
sandbox ซัพพลายเออร์ เก้ากรณี
- OK: การยืนยันตัวตนด้วยข้อมูลรับรองที่ถูกต้องและหมดอายุ
- OK: คำขอที่ไม่ถูกต้องถูกปฏิเสธพร้อมข้อผิดพลาดที่อ่านเข้าใจได้
- OK: จัดการ timeout ของซัพพลายเออร์โดยไม่มีการจองค้าง
- OK: เคารพ rate limit และลองใหม่หลังรอ
- OK: ตรวจพบการเปลี่ยนราคาตอนตรวจสอบซ้ำและแสดงก่อนชำระเงิน
- OK: การส่งซ้ำคืนค่าการจองแรก ไม่ใช่สร้างรายการที่สอง
- OK: ใช้การยกเลิกและคำนวณค่าธรรมเนียม
- OK: คืนเงินไปยังการชำระเงินเดิม
- OK: หมายเลขอ้างอิงการจอง การชำระเงิน และซัพพลายเออร์กระทบยอดตรงกัน
ผ่านทุกกรณี พร้อมสำหรับการรับรอง
การกำหนดขอบเขตต้องการอะไรจากคุณ
- 1ข้อตกลงกับซัพพลายเออร์ เอกสาร และข้อมูลรับรอง sandbox
- 2ตลาด สกุลเงิน ผลิตภัณฑ์ และบทบาทผู้ใช้
- 3ขอบเขตการค้นหา การจอง การเปลี่ยนแปลง การยกเลิก และการคืนเงิน
- 4ข้อกำหนดการรับรองและกระบวนการเข้าถึง production
คำถาม
คำถามเกี่ยวกับ API integration พร้อมคำตอบ
คำตอบสั้น ๆ สำหรับคำถามที่ผู้คนถามก่อนเริ่มโครงการเชื่อมต่อครั้งแรก
คุยกับฝ่ายขายAPI integration คือการเชื่อมต่อที่ช่วยให้ระบบซอฟต์แวร์สองระบบแลกเปลี่ยนข้อมูลและสั่งการได้โดยอัตโนมัติ ระบบหนึ่งส่งคำขอที่มีโครงสร้าง อีกระบบส่งคำตอบที่มีโครงสร้างกลับมา และทั้งสองฝ่ายปฏิบัติตามกฎที่ตกลงกันด้านความปลอดภัยและข้อมูล
ในธุรกิจท่องเที่ยว มันเชื่อมแพลตฟอร์มการจองเข้ากับซัพพลายเออร์เที่ยวบิน โรงแรม ทัวร์ หรือรถเช่า เกตเวย์ชำระเงิน และเครื่องมือทางธุรกิจ รองรับการค้นหา การตรวจสอบราคา การจอง การยกเลิก การคืนเงิน และการกระทบยอดโดยไม่ต้องพิมพ์ซ้ำ
REST เป็นรูปแบบสถาปัตยกรรมที่มักแลกเปลี่ยน JSON ผ่าน HTTP ส่วน XML เป็นรูปแบบข้อมูลที่ยังพบบ่อยในหมู่ซัพพลายเออร์ GDS และ bedbank มักห่อด้วย SOAP สัญญาและเอกสารของซัพพลายเออร์เป็นตัวกำหนดว่าจะใช้แบบใด
ขึ้นอยู่กับการเข้าถึงซัพพลายเออร์ endpoint ในขอบเขต การรับรอง กฎการจับคู่ข้อมูล และกรณีพิเศษของการจอง การประเมินที่เชื่อถือได้มาจากการตรวจสอบเอกสาร ข้อมูลรับรอง และขั้นตอนการทำงานที่คุณต้องการ
ทดสอบการยืนยันตัวตน คำขอที่ถูกต้องและไม่ถูกต้อง timeout, rate limit, การเปลี่ยนราคา การส่งซ้ำ การยกเลิก การคืนเงิน และการกระทบยอด ใน production ทุกคำขอควรสืบย้อนไปยังหมายเลขอ้างอิงการจองได้
ไม่เหมือน การเชื่อมต่อ (integration) เชื่อมผลิตภัณฑ์ของคุณเข้ากับ API ที่มีอยู่ ส่วนการพัฒนา (development) สร้างอินเทอร์เฟซให้ผู้อื่นมาเชื่อมต่อ แพลตฟอร์มท่องเที่ยวมักต้องการทั้งสองอย่าง: เชื่อมต่อซัพพลายเออร์ด้านหนึ่ง และเผยแพร่ API B2B ให้พาร์ทเนอร์อีกด้านหนึ่ง
สำรวจต่อ
เพิ่มเติมเกี่ยวกับแพลตฟอร์ม
- การเชื่อมต่อ API ท่องเที่ยวเชื่อมซัพพลายเออร์ XML และ JSON ด้วย PHP
- API ท่องเที่ยวAPI ของ GDS โรงแรม ทัวร์ รถเช่าและการชำระเงิน
- การเชื่อมต่อทั้งหมดรายการฉบับเต็ม อัปเดตล่าสุด
- เชื่อมต่อเพย์เมนต์เกตเวย์ชำระเงิน, 3D Secure, คืนเงิน และ webhook
- การเชื่อมต่อ API แบบกำหนดเองเชื่อม API ซัพพลายเออร์หรือพาร์ทเนอร์ใดก็ได้กับ PHPTRAVELS
- เทคโนโลยีสแต็กเบื้องหลังระบบ
