วิธีทดสอบ API ที่ต้องใช้ Client Certificates (mTLS) ใน Apidog

คุณเรียกใช้ Partner API, ส่งคำขอที่จัดรูปแบบอย่างดีพร้อมโทเค็นที่ถูกต้อง แต่ยังคงได้รับข้อผิดพลาดในการตรวจสอบสิทธิ์ TLS ปลายทางไม่ได้ขอกุญแจ API ของคุณ แต่กำลังขอให้ไคลเอนต์ของคุณพิสูจน์ตัวตนด้วยใบรับรอง ก่อนที่คำขอ HTTP จะออกจากเครื่องของคุณ นั่นคือ Mutual TLS (mTLS) และหากคุณไม่เคยกำหนดค่ามันในเครื่องมือทดสอบ มันอาจทำให้การรวมระบบหยุดชะงักไปทั้งวัน

คู่มือนี้จะแนะนำการตั้งค่าใบรับรองไคลเอนต์และใบรับรอง CA ใน Apidog เพื่อให้คุณสามารถทดสอบ API ที่ป้องกันด้วย mTLS ได้โดยไม่ต้องต่อสู้กับการตรวจสอบสิทธิ์ คุณจะเพิ่มใบรับรองไคลเอนต์และคีย์สำหรับโฮสต์ที่เฉพาะเจาะจง แนบใบรับรอง CA เพื่อให้ root ที่ลงนามเองไม่เกิดข้อผิดพลาด และส่งคำขอที่ได้รับการตรวจสอบสิทธิ์ที่ Apidog ลงนามโดยอัตโนมัติ หากข้อผิดพลาดเกี่ยวกับใบรับรองเป็นเรื่องใหม่ บทนำเกี่ยวกับการ ตรวจสอบใบรับรอง SSL ก็ควรค่าแก่การอ่านควบคู่ไปกับบทความนี้ สำหรับตัวโปรโตคอลเอง เอกสารอ้างอิง MDN TLS เป็นคำอธิบายที่มั่นคงและเป็นกลางจากผู้ให้บริการ

Mutual TLS คืออะไร และทำไม API บางตัวจึงต้องการมัน

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

Mutual TLS ทำให้ความไว้วางใจเป็นไปในสองทาง เซิร์ฟเวอร์ยังคงนำเสนอใบรับรอง แต่ก็ขอให้ไคลเอนต์นำเสนอใบรับรองด้วย หากใบรับรองของคุณไม่ได้ลงนามโดย Certificate Authority (CA) ที่เซิร์ฟเวอร์เชื่อถือ การตรวจสอบสิทธิ์จะล้มเหลวและการเชื่อมต่อจะไม่เปิดขึ้น ไม่มีเนื้อหาคำขอ ไม่มีส่วนหัว ไม่มีอะไรผ่านไปได้

คุณจะพบการตรวจสอบสิทธิ์ Mutual TLS (mTLS) ในสถานการณ์ที่โทเค็น bearer ที่รั่วไหลไม่เป็นรูปแบบความล้มเหลวที่ยอมรับได้:

• การธนาคารและการชำระเงิน API การธนาคารแบบเปิดและผู้ประมวลผลบัตรมักต้องการใบรับรองไคลเอนต์ที่ออกให้กับองค์กรของคุณนอกเหนือจาก OAuth เอกสารของ Stripe อธิบายรูปแบบข้อมูลประจำตัวที่ซ้อนกันนี้สำหรับปลายทางทางการเงินที่ละเอียดอ่อน
• การจราจรภายในและระหว่างบริการ บริษัทที่ใช้เครือข่าย Zero-Trust ทำให้บริการต้องพิสูจน์ตัวตนด้วยใบรับรองแทนที่จะเชื่อถือขอบเขตเครือข่าย
• API ของพันธมิตร B2B พันธมิตรอาจออกใบรับรองไคลเอนต์ให้คุณในระหว่างการเริ่มต้นใช้งาน เพื่อให้เฉพาะเครื่องที่ลงทะเบียนของคุณเท่านั้นที่สามารถเข้าถึงปลายทางของพวกเขาได้

หาก OAuth ก็มีส่วนร่วม ทั้งสองจะรวมกันได้อย่างลงตัว RFC 8705 กำหนดวิธีการที่ Mutual TLS ผูกโทเค็น OAuth เข้ากับใบรับรองไคลเอนต์ ใบรับรองเป็นข้อมูลรับรองระดับเครือข่าย แยกจากการตรวจสอบสิทธิ์ระดับแอปพลิเคชันในคำขอของคุณ ความแตกต่างนี้มีความสำคัญใน Apidog และเป็นสิ่งที่ผู้คนมักจะสับสนมากที่สุด ใบรับรองจัดการ mTLS แท็บ Authorization จัดการกุญแจ API, โทเค็น bearer, OAuth และ Basic auth คุณมักต้องการทั้งสองอย่างพร้อมกัน แต่คุณกำหนดค่ามันในที่ที่ต่างกัน

Apidog กำหนดขอบเขตใบรับรองตามโฮสต์อย่างไร

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

ใบรับรองสองประเภททำงานสองอย่างที่แตกต่างกัน:

• ใบรับรองไคลเอนต์ คือสิ่งที่คุณนำเสนอเพื่อพิสูจน์ตัวตนของคุณสำหรับการตรวจสอบสิทธิ์ Mutual TLS เป็นข้อมูลรับรองที่ Partner API ร้องขอ
• ใบรับรอง CA บอก Apidog ให้เชื่อถือ Certificate Authority ที่ยังไม่รู้จัก ชี้ไปที่ root CA ภายในของคุณ และข้อผิดพลาด SSL Error: Self signed certificate ที่น่ากลัวก็จะหายไป เนื่องจาก Apidog ตอนนี้เชื่อถือปลายทางที่ลงนามโดย CA นั้น

กุญแจสำคัญในการกำหนดขอบเขตคือโฮสต์ ใบรับรองไคลเอนต์ทุกใบผูกอยู่กับโดเมน และ Apidog จะจับคู่โฮสต์ของคำขอขาออกกับการผูกนั้น หากระบุโฮสต์ถูกต้อง ทุกอย่างที่เหลือจะทำงานโดยอัตโนมัติ หากระบุผิด Apidog จะไม่ส่งอะไรเลยเงียบๆ เพราะไม่พบการจับคู่

ตั้งค่าใบรับรองไคลเอนต์สำหรับ mTLS API

นี่คือสถานการณ์ พันธมิตรด้านการชำระเงิน partner-api.acmebank.com ได้ออกใบรับรองไคลเอนต์และคีย์ส่วนตัวให้คุณในระหว่างการเริ่มต้นใช้งาน API ของพวกเขาเป็นแบบ HTTPS เท่านั้น และปฏิเสธไคลเอนต์ใดๆ ที่ไม่สามารถนำเสนอใบรับรองนั้นได้ คุณต้องการเรียกใช้ GET /v1/settlements และตรวจสอบการตอบกลับ

ขั้นตอนที่ 1: เปิดการตั้งค่าใบรับรอง

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

ขั้นตอนที่ 2: เพิ่มใบรับรองไคลเอนต์

ภายใต้ Client Certificates ให้เลือก Add Certificate แบบฟอร์มจะเปิดขึ้นสำหรับการผูกโฮสต์และไฟล์ใบรับรอง

กรอกข้อมูลในช่อง Host ด้วยโดเมนเท่านั้น ไม่มีโปรโตคอล:

partner-api.acmebank.com

ไม่ต้องใส่ https:// ช่องนี้จะใช้เฉพาะโดเมนเปล่า หากคุณต้องการใบรับรองเดียวเพื่อครอบคลุมโดเมนย่อยหลายโดเมน ช่องโฮสต์รองรับการจับคู่รูปแบบ การป้อน *.acmebank.com จะใช้ใบรับรองไคลเอนต์เดียวกันสำหรับโดเมนย่อยทั้งหมดภายใต้ acmebank.com ซึ่งมีประโยชน์เมื่อพันธมิตรใช้ partner-api, sandbox-api และ settlements-api จากใบรับรองที่ออกให้เดียวกัน

พอร์ตที่กำหนดเองเป็นทางเลือก หากปล่อยว่าง Apidog จะใช้ 443 ซึ่งเป็นพอร์ต HTTPS มาตรฐาน ตั้งค่าพอร์ตก็ต่อเมื่อปลายทาง mTLS รับฟังที่อื่น เช่น 8443

ขั้นตอนที่ 3: เลือกไฟล์ใบรับรอง

Apidog ยอมรับรูปแบบไฟล์สองแบบสำหรับใบรับรองไคลเอนต์ เลือกแบบที่พันธมิตรของคุณให้มา:

• ไฟล์ CRT + Key ไฟล์ใบรับรองแยกและไฟล์คีย์ส่วนตัว เลือกแต่ละไฟล์ในช่องของมัน
• ไฟล์ PFX ไฟล์เดียวที่รวมใบรับรองและคีย์เข้าด้วยกัน

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

ขั้นตอนที่ 4: บันทึก

เลือก Add เพื่อบันทึกใบรับรองไคลเอนต์ ตอนนี้มันจะปรากฏในรายการของคุณ โดยผูกกับ partner-api.acmebank.com ตั้งแต่นี้ไปคุณจะไม่ต้องแตะมันอีกเลยต่อคำขอ

ขั้นตอนที่ 5: ส่งคำขอที่ได้รับการตรวจสอบสิทธิ์

สร้างคำขอไปยังโฮสต์และส่ง:

GET https://partner-api.acmebank.com/v1/settlements
Authorization: Bearer <your_oauth_token>

Apidog จะจับคู่โฮสต์ แนบใบรับรองไคลเอนต์ของคุณในระหว่างการตรวจสอบสิทธิ์ TLS และทำการตรวจสอบสิทธิ์ Mutual TLS ให้เสร็จสิ้นก่อนที่คำขอจะถูกส่งออกไป หากพันธมิตรต้องการ OAuth ด้วย โทเค็น bearer นั้นจะถูกส่งไปในคำขอตามปกติ ใบรับรองพิสูจน์เครื่อง โทเค็นพิสูจน์ผู้เรียก การตอบกลับที่ประสบความสำเร็จอาจมีลักษณะดังนี้:

{
  "settlements": [
    {
      "id": "stl_88213",
      "amount": 41200,
      "currency": "USD",
      "status": "cleared",
      "settled_at": "2026-07-14T09:31:00Z"
    }
  ],
  "next_cursor": null
}

ไม่มีขั้นตอนการทำด้วยมือต่อคำขอทำให้สิ่งนี้เกิดขึ้น การจับคู่โฮสต์ทำหน้าที่นั้น

เพิ่มใบรับรอง CA สำหรับ Root ภายในหรือที่ลงนามเอง

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

เมื่อสิ่งนั้นเกิดขึ้น คำขอจะล้มเหลวด้วยข้อความเช่น SSL Error: Self signed certificate ก่อนที่ mTLS จะมีโอกาสแก้ไข สิ่งที่ต้องทำคือการส่งมอบ CA ให้ Apidog เพื่อให้ Apidog เชื่อถือ root นั้น

ในแท็บ Certificates เดียวกัน ให้เปิดใช้งานการสลับถัดจาก CA Certificates จากนั้นเลือกไฟล์ PEM ของคุณ ใบรับรอง CA ใช้รูปแบบ PEM และไฟล์ PEM ไฟล์เดียวสามารถมีใบรับรอง CA ได้หลายใบ ดังนั้นคุณสามารถรวมห่วงโซ่ทั้งหมดของ root และ intermediate ภายในไว้ในไฟล์เดียว:

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQG...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEFTCCAv2gAwIBAgIQeM8V5x8B3QksZ4 b2VqkJTANBgkqhkiG9w0BAQ...
-----END CERTIFICATE-----

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

เคล็ดลับขั้นสูงและรูปแบบทั่วไป

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

การครอบคลุมโดเมนย่อยด้วยใบรับรองเดียว หากพันธมิตรออกใบรับรองที่กำหนดขอบเขตแบบ wildcard ให้ตั้งค่าโฮสต์เป็น *.acmebank.com ครั้งเดียวแทนที่จะลงทะเบียน partner-api, sandbox-api และส่วนที่เหลือแยกกัน การผูกครั้งเดียวครอบคลุมทุกโดเมนย่อย

พอร์ตที่ไม่ได้มาตรฐาน เกตเวย์ mTLS ภายในชอบพอร์ตเช่น 8443 หรือ 9443 ค่าเริ่มต้นคือ 443 ดังนั้นให้ระบุพอร์ตที่กำหนดเองเมื่อใดก็ตามที่ปลายทางรับฟังที่อื่น มิฉะนั้นโฮสต์จะไม่ตรงกันและจะไม่มีการส่งใบรับรอง

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

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

แยกใบรับรองและการอนุญาตออกจากกันในใจของคุณ นี่คือสาเหตุของความสับสนที่ใหญ่ที่สุด mTLS อยู่ในแท็บ Certificates กุญแจ API, โทเค็น bearer, OAuth และ Basic auth อยู่ในแท็บ Authorization ของคำขอหรือโฟลเดอร์ และคำขอจะสืบทอดการอนุญาตจากโฟลเดอร์หลัก การอนุญาตมีสามระดับ: คำขอแต่ละรายการ, คำขอทั้งหมดในโฟลเดอร์ และคำขอทั้งหมดในคอลเลกชัน หากพันธมิตรต้องการทั้งใบรับรองไคลเอนต์และ OAuth คุณต้องตั้งค่าใบรับรองใน Certificates และโทเค็นใน Authorization พวกมันไม่ทับซ้อนกัน สำหรับการพิจารณาการตั้งค่าการตรวจสอบสิทธิ์ด้วยโทเค็นที่ลึกซึ้งยิ่งขึ้น คู่มือการตรวจสอบสิทธิ์ API gateway ครอบคลุมด้านคำขอ และหากคุณกำลังจัดการกับสแต็กที่เน้น Windows การกำหนดค่าการตรวจสอบสิทธิ์ Kerberos ใน Apidog เป็นคู่มือพี่น้องที่ควรบุ๊กมาร์กไว้

HTTPS เท่านั้น เสมอ Apidog จะไม่แนบใบรับรองไคลเอนต์กับคำขอ HTTP ธรรมดา หากเป้าหมายการทดสอบของคุณคือ http:// ใบรับรองจะไม่ถูกส่งและตรรกะการตรวจสอบสิทธิ์จะไม่ทำงาน ปลายทางต้องเป็น HTTPS เพื่อให้สิ่งเหล่านี้ใช้งานได้

ทำให้เวิร์กโฟลว์เป็นอัตโนมัติด้วย Apidog CLI

เมื่อคำขอ mTLS ของคุณผ่านด้วยมือแล้ว ให้รวมเข้ากับสถานการณ์การทดสอบที่บันทึกไว้และเรียกใช้แบบ Headless ด้วย Apidog CLI ติดตั้งและตรวจสอบสิทธิ์:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

จากนั้นเรียกใช้สถานการณ์ที่บันทึกไว้กับสภาพแวดล้อม:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

คำสั่ง apidog run รองรับการกำหนดค่าใบรับรองไคลเอนต์โดยตรง ดังนั้น mTLS จะยังคงทำงานได้เมื่อเปลี่ยนจาก GUI ไปยัง Pipeline สำหรับใบรับรองเดียว ให้ส่ง --ssl-client-cert (ใบรับรอง PEM), --ssl-client-key (คีย์ส่วนตัว) และ --ssl-client-passphrase หากคีย์มีรหัสผ่าน ชี้ --ssl-extra-ca-certs ไปยัง CA ที่เชื่อถือได้เพิ่มเติม หรือใช้ --ssl-client-cert-list พร้อมไฟล์กำหนดค่าเมื่อคุณจับคู่ใบรับรองกับโฮสต์ตามรูปแบบ URL ผู้รายงานจะถูกตั้งค่าด้วย -r (ลองใช้ -r html,cli) เชื่อมคำสั่งนั้นเข้ากับงาน และ API ที่ป้องกันด้วยใบรับรองของคุณจะถูกทดสอบทุกครั้งที่ผลักดันโค้ด คู่มือ Apidog CLI ใน CI/CD ครอบคลุมการเรียกใช้ใน Pipeline

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

ฉันต้องการใบรับรองไคลเอนต์และใบรับรอง CA หรือเพียงอย่างเดียว?

ขึ้นอยู่กับปลายทาง ใบรับรองไคลเอนต์พิสูจน์ตัวตนของคุณ ดังนั้นคุณจึงจำเป็นต้องใช้เมื่อใดก็ตามที่เซิร์ฟเวอร์ต้องการ Mutual TLS ใบรับรอง CA จำเป็นเมื่อใบรับรองของเซิร์ฟเวอร์เองถูกลงนามโดย CA ที่เครื่องของคุณยังไม่เชื่อถือ เช่น root CA ภายใน Partner API สาธารณะบน CA สาธารณะที่เชื่อถือได้ต้องการเพียงใบรับรองไคลเอนต์เท่านั้น บริการ mTLS ภายในบน root ส่วนตัวมักต้องการทั้งสองอย่าง

ทำไม Apidog ไม่ส่งใบรับรองไคลเอนต์ของฉัน?

เกือบตลอดเวลาเกิดจากการจับคู่โฮสต์ไม่ถูกต้องหรือเป้าหมายเป็น HTTP ธรรมดา ตรวจสอบว่าช่อง Host มีโดเมนที่ถูกต้องโดยไม่มีคำนำหน้า https:// ว่าพอร์ตตรงกัน (ค่าเริ่มต้นคือ 443 ดังนั้นให้ตั้งค่าพอร์ตที่กำหนดเองหากปลายทางรับฟังที่อื่น) และ URL คำขอเป็น HTTPS Apidog จะไม่แนบใบรับรองกับคำขอ HTTP

กุญแจ API และโทเค็น bearer ไปที่ไหนถ้าไม่ได้อยู่ใน Certificates?

อยู่ในแท็บ Authorization ของคำขอหรือโฟลเดอร์ ซึ่งแยกจากการตั้งค่าใบรับรอง ใบรับรองจัดการตัวตนระดับ TLS การอนุญาตจัดการ API Key, Bearer Token, OAuth และ Basic auth ที่ระดับคำขอ คุณสามารถดูรายละเอียดทั้งหมดของประเภทการตรวจสอบสิทธิ์ได้ใน คู่มือ Security Schemes และคุณสามารถตั้งค่าการตรวจสอบสิทธิ์ครั้งเดียวที่ระดับโฟลเดอร์หรือคอลเลกชันเพื่อให้คำขอทั้งหมดสืบทอดไป

ใบรับรองเดียวสามารถครอบคลุมหลายโดเมนย่อยได้หรือไม่?

ได้ ช่องโฮสต์รองรับการจับคู่รูปแบบ ป้อน *.example.com และใบรับรองไคลเอนต์เดียวกันจะใช้กับทุกโดเมนย่อยของ example.com นั่นเป็นวิธีที่สะอาดในการใช้ใบรับรองที่กำหนดขอบเขตแบบ wildcard ที่พันธมิตรออกให้สำหรับโดเมนย่อย API หลายตัวของพวกเขา

ฉันจะอัปเดตใบรับรองหลังจากเพิ่มได้อย่างไร?

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

สรุป

การทดสอบ API ที่ป้องกันด้วย mTLS สรุปได้ด้วยการดำเนินการสามขั้นตอนใน Apidog: ผูกใบรับรองไคลเอนต์กับโฮสต์ที่ถูกต้อง, แนบใบรับรอง CA หากเซิร์ฟเวอร์ใช้ root ส่วนตัว, และให้การจับคู่โฮสต์ลงนามคำขอ HTTPS ทุกครั้งโดยอัตโนมัติ แยกใบรับรองและการอนุญาตออกจากกัน และการตรวจสอบสิทธิ์จะไม่เป็นปริศนาอีกต่อไป

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