เรียกใช้ API
ทุกสิ่งที่แอปทำจะทำผ่าน HTTP API เดียวกันซึ่งคุณสามารถเรียกได้ด้วยตนเอง ทุก endpoint จะมีรายการใน REST API reference; หน้านี้ครอบคลุมสามสิ่งที่คุณต้องการก่อนที่พวกเขาจะทำงานได้
รับรองความถูกต้อง
Section titled “รับรองความถูกต้อง”ส่งโทเค็นประจำตัวเป็นข้อมูลรับรอง bearer:
curl -H "Authorization: Bearer <your-token>" \ https://app.example.com/api/workflowsโทเค็นมาจากการลงชื่อเข้าใช้ ไม่จำเป็นต้องสร้าง API key แยกต่างหาก: ไอดี API ของคุณก็คือไอดีผู้ใช้ของคุณ ดังนั้นทุกสิ่งที่คุณสามารถเข้าถึงในแอปคุณก็สามารถเข้าถึงด้วย curl ได้ และไม่มีอะไรอื่น
ทุก endpoint ต้องการสิ่งนี้ ไม่มีการอ่านแบบไม่ระบุชื่อ: คำขอที่ไม่มีข้อมูลรับรองจะถูกปฏิเสธก่อนที่จะถึง endpoint ไม่ว่า endpoint นั้นจะเป็นอะไร ทางเดินสาธารณะที่แท้จริงเพียงไม่กี่แห่ง — รายการราคา, เอกสารเหล่านี้ — เปิดให้สาธารณชนโดยการตัดสินใจอย่างชัดเจน ไม่ใช่เพราะการรับรองความถูกต้องเป็นทางเลือก
บอกว่า workspace ไหนที่คุณหมายถึง
Section titled “บอกว่า workspace ไหนที่คุณหมายถึง”หากคุณเป็นสมาชิกในหลาย workspace, บอกเราว่าคำขอทำงานใน workspace ไหน:
curl -H "Authorization: Bearer <your-token>" \ -H "X-Account-Id: <workspace-id>" \ https://app.example.com/api/workflowsหากไม่ใส่มัน คุณจะได้ workspace แรกที่คุณเป็นสมาชิก ส่ง workspace ที่คุณไม่เป็นสมาชิกและคุณจะได้ workspace แรกแทน — header จะเลือกจาก workspace ที่คุณเป็นสมาชิกอยู่แล้ว ไม่ได้ให้การเข้าถึง workspace ที่คุณไม่ได้เป็นสมาชิก
header มีชื่อว่า X-Account-Id ด้วยเหตุผลทางประวัติกรรม; ค่าคือ id ของ workspace ในทุกที่อื่น คำนี้หมายถึงการเข้าสู่ระบบของคุณเอง
คุณจะเห็นข้อมูลของ workspace ของคุณเองเท่านั้น จุดสิ้นสุดการเก็บรวบรวมข้อมูลจะคืนค่าภาพของคุณและไม่มีอย่างอื่น; การขออะไรใน workspace ที่คุณไม่ได้เป็นสมาชิกจะถูกปฏิเสธแทนที่จะถูกคืนค่าเป็นศูนย์
โฮสต์ที่คุณเรียกสำคัญ
Section titled “โฮสต์ที่คุณเรียกสำคัญ”หากองค์กรของคุณดำเนินการผลิตภัณฑ์ที่มีแบรนด์มากกว่าหนึ่งตัว hostname ที่คุณเรียกจะเลือกแบรนด์ที่คุณต้องการ ทั้งสองข้อมูลรับรองบนโฮสต์ที่แตกต่างกันจะเห็นชุด workspace ที่แตกต่างกัน — ตัวที่คุณมีในแต่ละตัว นี่เป็นสิ่งที่ตั้งใจ: workspace เป็นของแบรนด์หนึ่งและคำขอต้องบอกว่าเป็นแบรนด์ไหน
การอ่านข้อผิดพลาด
Section titled “การอ่านข้อผิดพลาด”| Status | Meaning | What to do |
|---|---|---|
401 |
ไม่มีข้อมูลรับรองหรือไม่ถูกต้อง | ลงชื่อเข้าใช้อีกครั้งและลองใหม่ด้วยโทเค็นใหม่ |
402 |
workspace ไม่มีการสมัครสมาชิกที่ใช้งานอยู่ | การอ่านยังทำงานได้; การเขียนต้องการแผน ดู Usage and billing |
403 |
ได้รับการรับรองความถูกต้องแต่ไม่ใช่ของคุณ | คุณไม่เป็นสมาชิกใน workspace นั้น, หรือการดำเนินการต้องการเจ้าของ |
404 |
ไม่พบ — หรือไม่ใช่ของคุณ | สำหรับทรัพยากรที่ถูกเรียกโดยชื่อ เราจะตอบ 404 แทนที่จะเป็น 403 เพื่อให้การตอบกลับไม่ยืนยันว่าสิ่งนั้นมีอยู่ |
429 |
ถูกจำกัดอัตรา หรือเครดิตพรีเพดหมด | ช้าลง; หากมันบอกเครดิต, เติมเงิน |
การ 402 ควรเข้าใจ: workspace ที่ไม่ได้ชำระเงินจะกลายเป็น อ่านเท่านั้น แทนที่จะถูกปิด คุณยังคงเข้าถึงทุกสิ่งที่มีอยู่และคุณยังสามารถส่งออกได้ — คุณเพียงแค่ไม่สามารถสร้างงานใหม่ได้จนกว่าจะมีแผนอีกครั้ง จุดสิ้นสุดการเรียกเก็บเงินและสมาชิกยังคงทำงาน เนื่องจากนี่คือวิธีที่คุณจะแก้ไขมัน
Webhooks และ embeds รับรองความถูกต้องแตกต่างกัน
Section titled “Webhooks และ embeds รับรองความถูกต้องแตกต่างกัน”สองกลุ่ม endpoint ไม่ได้ถูกเรียกโดยบุคคลที่ลงชื่อเข้าใช้ดังนั้นพวกเขาจึงไม่ได้ใช้โทเค็นของคุณ:
- Webhook triggers จะมีโทเค็นของตนเองใน URL ดังนั้นระบบภายนอกสามารถเริ่มกระบวนงานได้โดยไม่ต้องมีบัญชีผู้ใช้
- Embed endpoints จะได้รับอนุญาตโดยโทเค็นที่ฝังและรายการของไซต์ที่ได้รับอนุญาตให้ใช้มัน — ดู Embed a widget.
ทั้งสองจะปฏิเสธอย่างชัดเจนเมื่อ workspace ของเจ้าของไม่มีการสมัครสมาชิกที่ใช้งานอยู่แทนที่จะลดคุณภาพลงเป็นอ่านเฉพาะ ผู้เข้าชมที่เว็บไซต์ของผู้อื่นไม่ควรเห็นปัญหาการเรียกเก็บเงิน