คู่มือ

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"}
ตัวอย่างการเรียกไปยังซัพพลายเออร์โรงแรมสมมติ ชื่อฟิลด์ endpoint และจำนวนเงินแตกต่างกันไปตามซัพพลายเออร์

องค์ประกอบของการเรียก API หนึ่งครั้ง

  1. 1

    Endpoint และ method

    ที่อยู่ของการดำเนินการและคำกริยาที่ใช้กับมัน: POST ไปที่ availability หมายถึงค้นหาห้องพัก

  2. 2

    การยืนยันตัวตน

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

  3. 3

    Payload

    ข้อมูลนำเข้าที่มีโครงสร้าง: เมือง วันที่ จำนวนผู้เข้าพัก และสกุลเงิน เอกสารของซัพพลายเออร์กำหนดทุกฟิลด์

  4. 4

    รหัสสถานะ

    ตัวเลขที่บอกว่าการเรียกเป็นอย่างไร: 200 คือสำเร็จ, 4xx คือปัญหาที่คำขอ, 5xx คือปัญหาฝั่งซัพพลายเออร์

  5. 5

    รหัสคำขอ

    ตัวระบุที่ทั้งสองฝ่ายเก็บไว้ เมื่อฝ่ายสนับสนุนถามว่าเกิดอะไรขึ้นกับการจอง นี่คือสิ่งที่พวกเขาค้นหา

  6. 6

    เนื้อหาคำตอบ

    คำตอบในรูปแบบของซัพพลายเออร์ ซึ่งแพลตฟอร์มของคุณจับคู่เข้ากับห้องพัก ราคา และนโยบายของตัวเอง

หนึ่งการจอง สี่ระบบ

API integration ทำอะไรระหว่างการจองโรงแรม

ติดตามการเข้าพักสองคืนตั้งแต่ค้นหาจนถึงวอชเชอร์ ลูกศรทุกเส้นคือการเรียก API หนึ่งครั้ง นักเดินทางเห็นเพียงขั้นแรกและขั้นสุดท้าย

  1. 01นักเดินทางแพลตฟอร์มการจองค้นหาโรงแรมในดูไบ สองคืน ผู้เข้าพักสองคน
  2. 02แพลตฟอร์มการจองAPI ซัพพลายเออร์คำขอห้องว่างพร้อมวันที่ ผู้เข้าพัก และสกุลเงิน
  3. 03API ซัพพลายเออร์แพลตฟอร์มการจองห้องพัก ราคา นโยบาย และ rate key
  4. 04แพลตฟอร์มการจองนักเดินทางแสดงผลลัพธ์พร้อมมาร์กอัปและสกุลเงินของคุณ
  5. 05แพลตฟอร์มการจองAPI ซัพพลายเออร์ตรวจสอบราคาซ้ำบน rate key ที่เลือกก่อนชำระเงิน
  6. 06แพลตฟอร์มการจองเกตเวย์ชำระเงินขออนุมัติการชำระเงินสำหรับยอดรวม
  7. 07เกตเวย์ชำระเงินแพลตฟอร์มการจองอนุมัติแล้ว ได้รับ webhook ที่ลงนาม
  8. 08แพลตฟอร์มการจองAPI ซัพพลายเออร์คำขอจองพร้อมข้อมูลผู้เข้าพัก
  9. 09API ซัพพลายเออร์แพลตฟอร์มการจองหมายเลขยืนยันและเงื่อนไขการยกเลิก
  10. 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 integration

เชื่อมผลิตภัณฑ์ของคุณเข้ากับอินเทอร์เฟซที่มีอยู่แล้ว ซัพพลายเออร์เป็นเจ้าของ API คุณสร้าง client การจับคู่ข้อมูล และกฎรอบ ๆ มัน

API development

สร้างอินเทอร์เฟซที่ระบบอื่นใช้เชื่อมต่อกับผลิตภัณฑ์ของคุณ เช่น API B2B ที่เครื่องมือของตัวแทนของคุณเรียกใช้ได้ คุณเป็นเจ้าของสัญญาและเวอร์ชันของมัน

โครงการท่องเที่ยวจำนวนมากต้องการทั้งสองอย่าง: แพลตฟอร์มเชื่อมต่อซัพพลายเออร์ด้านหนึ่ง และเผยแพร่ API ของตัวเองให้ตัวแทนและพาร์ทเนอร์อีกด้านหนึ่ง

ก่อนและหลัง

อะไรเปลี่ยนไปเมื่อระบบถูกเชื่อมต่อกัน

ห้าขั้นตอนเดียวกันของการจอง ทำด้วยมือผ่านพอร์ทัลซัพพลายเออร์ และทำผ่าน API integration

ค้นหา

ไม่มีการเชื่อมต่อด้วยมือ

ตัวแทนเปิดพอร์ทัลซัพพลายเออร์ทีละราย แล้วคัดลอกราคาลงในใบเสนอราคา

มี API integrationอัตโนมัติ

การค้นหาครั้งเดียวกระจายไปยังซัพพลายเออร์ที่เชื่อมต่อทุกรายและส่งกลับเป็นรายการเดียว

ราคา

ไม่มีการเชื่อมต่อด้วยมือ

เพิ่มมาร์กอัปในสเปรดชีต ราคาอาจเปลี่ยนไปแล้วเมื่อส่งใบเสนอราคา

มี API integrationอัตโนมัติ

มาร์กอัป ภาษี และกฎสกุลเงินถูกใช้ตอนได้รับคำตอบ ราคาถูกตรวจสอบซ้ำก่อนชำระเงิน

จอง

ไม่มีการเชื่อมต่อด้วยมือ

ข้อมูลผู้เข้าพักถูกพิมพ์ซ้ำลงในพอร์ทัลซัพพลายเออร์ การพิมพ์ผิดกลายเป็นข้อผิดพลาดของการจอง

มี API integrationอัตโนมัติ

ข้อมูลถูกส่งครั้งเดียว ตรวจสอบความถูกต้อง และบันทึกพร้อมการยืนยันจากซัพพลายเออร์

ชำระเงิน

ไม่มีการเชื่อมต่อด้วยมือ

เก็บเงินแยกต่างหากแล้วค่อยจับคู่กับการจองในภายหลัง

มี API integrationอัตโนมัติ

การอนุมัติ การเรียกเก็บ และการคืนเงินผูกกับหมายเลขอ้างอิงการจอง

บริการหลังการขาย

ไม่มีการเชื่อมต่อด้วยมือ

การยกเลิกและการเปลี่ยนแปลงหมายถึงการเข้าสู่ระบบอีกครั้งและอีเมลอีกฉบับ

มี API integrationอัตโนมัติ

การเปลี่ยนแปลงและการยกเลิกทำผ่านการเชื่อมต่อเดียวกันและอัปเดตบันทึก

คำศัพท์

คำที่คุณจะพบในเอกสาร 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. 1ข้อตกลงกับซัพพลายเออร์ เอกสาร และข้อมูลรับรอง sandbox
  2. 2ตลาด สกุลเงิน ผลิตภัณฑ์ และบทบาทผู้ใช้
  3. 3ขอบเขตการค้นหา การจอง การเปลี่ยนแปลง การยกเลิก และการคืนเงิน
  4. 4ข้อกำหนดการรับรองและกระบวนการเข้าถึง production

พร้อมเชื่อมต่อซัพพลายเออร์

PHPTRAVELS เชื่อมต่อซัพพลายเออร์ เกตเวย์ และเครื่องมือทางธุรกิจเข้ากับแพลตฟอร์มแบบ self-hosted ที่ส่งมอบพร้อมซอร์สโค้ด ดู ราคา สำหรับแผนชำระครั้งเดียวสามแบบ หรือสอบถามเราเกี่ยวกับ API ที่ต้องการ

คำถาม

คำถามเกี่ยวกับ API integration พร้อมคำตอบ

คำตอบสั้น ๆ สำหรับคำถามที่ผู้คนถามก่อนเริ่มโครงการเชื่อมต่อครั้งแรก

คุยกับฝ่ายขาย

API integration คือการเชื่อมต่อที่ช่วยให้ระบบซอฟต์แวร์สองระบบแลกเปลี่ยนข้อมูลและสั่งการได้โดยอัตโนมัติ ระบบหนึ่งส่งคำขอที่มีโครงสร้าง อีกระบบส่งคำตอบที่มีโครงสร้างกลับมา และทั้งสองฝ่ายปฏิบัติตามกฎที่ตกลงกันด้านความปลอดภัยและข้อมูล

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

REST เป็นรูปแบบสถาปัตยกรรมที่มักแลกเปลี่ยน JSON ผ่าน HTTP ส่วน XML เป็นรูปแบบข้อมูลที่ยังพบบ่อยในหมู่ซัพพลายเออร์ GDS และ bedbank มักห่อด้วย SOAP สัญญาและเอกสารของซัพพลายเออร์เป็นตัวกำหนดว่าจะใช้แบบใด

ขึ้นอยู่กับการเข้าถึงซัพพลายเออร์ endpoint ในขอบเขต การรับรอง กฎการจับคู่ข้อมูล และกรณีพิเศษของการจอง การประเมินที่เชื่อถือได้มาจากการตรวจสอบเอกสาร ข้อมูลรับรอง และขั้นตอนการทำงานที่คุณต้องการ

ทดสอบการยืนยันตัวตน คำขอที่ถูกต้องและไม่ถูกต้อง timeout, rate limit, การเปลี่ยนราคา การส่งซ้ำ การยกเลิก การคืนเงิน และการกระทบยอด ใน production ทุกคำขอควรสืบย้อนไปยังหมายเลขอ้างอิงการจองได้

ไม่เหมือน การเชื่อมต่อ (integration) เชื่อมผลิตภัณฑ์ของคุณเข้ากับ API ที่มีอยู่ ส่วนการพัฒนา (development) สร้างอินเทอร์เฟซให้ผู้อื่นมาเชื่อมต่อ แพลตฟอร์มท่องเที่ยวมักต้องการทั้งสองอย่าง: เชื่อมต่อซัพพลายเออร์ด้านหนึ่ง และเผยแพร่ API B2B ให้พาร์ทเนอร์อีกด้านหนึ่ง