Rivya API คือเส้นทางสำหรับนักพัฒนาในการใช้ความสามารถของโมเดล Rivya จากผลิตภัณฑ์ สคริปต์ หรือเวิร์กโฟลว์ของคุณเอง
มันไม่ใช่ผลิตภัณฑ์แยกจาก Rivya Studio แต่ใช้ขอบเขตบัญชีเดียวกัน กระเป๋าเครดิตเดียวกัน และชั้นโมเดลสาธารณะเดียวกันกับที่ผู้ใช้เห็นทั่ว Rivya ความต่างอยู่ที่งานเริ่มอย่างไร: แทนที่จะคลิกผ่าน Studio แอปพลิเคชันของคุณส่งคำขอด้วย API key
ถ้าต้องการรายละเอียด endpoint ให้เริ่มจาก Rivya API Overview และ Rivya API Quickstart บทความนี้คือคำอธิบายระดับผลิตภัณฑ์: API มีไว้ทำอะไร อยู่ตรงไหน และเมื่อไหร่ไม่ควรเป็นเส้นทางแรก
ฉบับสั้น
Rivya API v1 ให้บัญชีที่ลงชื่อเข้าใช้สร้าง API keys และเรียกความสามารถของโมเดล Rivya จากนอก web interface ได้
พื้นผิว API ปัจจุบันมี:
- การค้นหาโมเดลผ่านรายการโมเดลของ API
- งานสร้าง image, video และ audio แบบ asynchronous
- การอัปโหลดผ่าน Files API สำหรับโมเดลที่ต้องใช้สื่ออ้างอิง
- การ polling สถานะ generation ด้วย public task IDs
- การตรวจเครดิตบัญชี
- Chat API turns รวมถึง SSE streaming ที่เลือกใช้ได้
- signed webhooks สำหรับ generation completion
- TypeScript SDK beta สำหรับทีมที่ต้องการ client wrapper
ฮับนักพัฒนาสาธารณะคือ Developers เป็นทางเข้าที่ดีที่สุดถ้าต้องการภาพรวมแบบมีไกด์ ลิงก์ไปยังการตั้งค่า API key และ flow ดีบักที่ปลอดภัย
ทำไม Rivya ต้องมี API
Studio มีประโยชน์เมื่อคนยังเลือกโมเดล ปรับพรอมต์ รีวิวผลลัพธ์ และตัดสินใจว่าจะทำอะไรต่อ
API มีประโยชน์เมื่อการตัดสินใจนั้นกลายเป็นเวิร์กโฟลว์ของผลิตภัณฑ์หรือการปฏิบัติการที่ทำซ้ำได้
ตัวอย่างที่พบบ่อย:
- ผลิตภัณฑ์ต้องการสร้างรูปแบบ image หลังจากผู้ใช้ส่ง brief
- เวิร์กโฟลว์การตลาดต้องสร้าง visual drafts จาก campaign inputs ที่มีโครงสร้าง
- เครื่องมือภายในต้องส่ง video หรือ audio jobs โดยไม่ต้องให้ใครเปิด browser
- ระบบ support หรือ content ต้องการหนึ่ง chat model turn ภายใน interface ของตัวเอง
- backend service ต้องการ signed callbacks เมื่อ generation jobs เสร็จ
ในกรณีเหล่านี้ Rivya API ช่วยให้งานยังเชื่อมกับบัญชี Rivya เดียวกัน แทนที่จะบังคับให้มี stack แยกสำหรับ billing, model selection และ task status
API ไม่ได้แทนที่อะไร
API ไม่ได้แทนที่เหตุผลทั้งหมดในการใช้ Rivya โดยตรง
ใช้ Studio หรือพื้นผิวงานสาธารณะเมื่อ:
- prompt ยังต้องให้มนุษย์สำรวจ
- การเลือกโมเดลยังไม่นิ่ง
- creator ต้องเปรียบเทียบผลลัพธ์ด้วยสายตา
- โปรเจกต์พึ่งพา saved history และ manual review
- ทีมยังไม่ตัดสินใจว่ารูปแบบ input และ output แบบไหนควรถูกทำซ้ำ
ใช้ API เมื่อเวิร์กโฟลว์ชัดพอที่จะทำให้เป็นอัตโนมัติ
ขอบเขตนี้สำคัญ คำถามครีเอทีฟที่ยังคลุมเครือมักควรอยู่ใน Studio ก่อน ส่วน product flow ที่มี input คาดเดาได้สามารถย้ายไป API ได้
ส่วนประกอบหลัก
ให้คิดว่า API เป็นชิ้นส่วนที่เชื่อมกัน 6 ส่วน
| ส่วนประกอบ | ใช้จัดการอะไร | อ่านต่อที่ไหน |
|---|---|---|
| API keys | การเข้าถึง server-to-server จากบัญชีของคุณ | API Authentication |
| Models | public model IDs และข้อมูล readiness | API Models |
| Generations | งาน image, video และ audio แบบ async | Create Generation |
| Files | การอัปโหลด reference image, video หรือ audio | Files API |
| Chat | chat turns แบบ non-streaming หรือ streaming | Chat API |
| Webhooks | signed completion events สำหรับ generation jobs | API Webhooks |
เอกสาร API คือแหล่งอ้างอิงของ request และ response shape บทความนี้ช่วยให้คุณตัดสินว่าควรใช้ชิ้นส่วนใดก่อน
เครดิตทำงานอย่างไร
การใช้งาน API ดึงจากกระเป๋าเครดิตบัญชี Rivya เดียวกับ Studio
นั่นหมายความว่า API ไม่ใช่ anonymous model proxy คำขอหนึ่งเป็นของบัญชี Rivya หนึ่ง ใช้ API key ที่บัญชีนั้นสร้าง และตามขอบเขตเครดิตระดับผลิตภัณฑ์เดียวกับที่อธิบายใน API Credits
สิ่งนี้มีประโยชน์กับทีม เพราะการทดลองใน Studio และการใช้ API อยู่ในโมเดลการปฏิบัติการเดียวกัน คุณสามารถทดสอบโมเดลด้วยมือ แล้วค่อยย้ายส่วนที่ทำซ้ำได้เข้าสู่ integration โดยไม่ต้องสร้าง billing layer ที่สอง
ไฟล์เข้ามาเกี่ยวข้องอย่างไร
บางโมเดลรันจากข้อความอย่างเดียวได้ บางโมเดลต้องใช้ reference image, video หรือ audio file
สำหรับ API integrations สื่ออ้างอิงเหล่านั้นควรผ่าน Files API การอัปโหลดจะสร้าง managed file record ที่ส่งต่อเข้า model parameters ที่รองรับได้
กฎเชิงปฏิบัติง่าย ๆ คือ:
- ถ้าโมเดลรับ text-only input ได้ ให้เริ่มจาก generation endpoint
- ถ้าโมเดลต้องใช้ reference media ให้อัปโหลดไฟล์ก่อน
- ถ้าโมเดล chat ต้องใช้ image attachments ให้ใช้ Chat API และ file IDs
อย่าออกแบบ integration รอบ upload flow ที่ใช้ได้เฉพาะ browser หรือ saved Studio sessions API มีขอบเขตไฟล์สาธารณะของตัวเองด้วยเหตุผลที่ชัดเจน
Webhooks ช่วยตรงไหน
Polling คือเส้นทาง integration แรกที่ง่ายที่สุด ส่ง generation job, บันทึก public task ID แล้ว poll จนสำเร็จหรือล้มเหลว
Webhooks มีประโยชน์เมื่อ integration ใกล้ production มากขึ้น:
- คุณไม่ต้องการให้ worker polling ทุก job
- แอปต้องอัปเดต record เมื่อ generation เสร็จ
- คุณต้องการ signed event ที่ retry ได้อย่างปลอดภัย
- jobs ที่ล้มเหลวต้องเข้าสู่ recovery path ที่ชัดเจน
สำหรับ signed event contract ให้ใช้ API Webhooks ทำให้ webhook receiver แคบไว้: ตรวจ signatures, จัดการ duplicate events และหลีกเลี่ยงการใส่ค่า secret ใน logs
โปรเจกต์ API แรกที่ดี
โปรเจกต์ API แรกที่ดีที่สุดมักเล็กและเป็นรูปธรรม
ตัวอย่าง:
- สร้าง API key ใน settings
- เรียกรายการโมเดล
- เลือกโมเดลที่ available หนึ่งตัว
- ส่ง generation job หนึ่งงานพร้อม idempotency key
- poll endpoint สถานะ
- ตรวจเครดิตก่อนและหลัง
- หลังจากนั้นค่อยเพิ่ม Files API, Chat API หรือ Webhooks
เส้นทางนี้ให้ integration ที่ใช้งานได้โดยไม่ต้องผสมทุกฟีเจอร์ API เข้าไปในการทดสอบแรก
เมื่อไหร่ API ไม่ใช่จุดเริ่มที่ถูกต้อง
API อาจไม่ใช่ขั้นแรกที่ถูกต้องเมื่อ:
- ทีมยังไม่ได้เลือก model family
- output ที่ต้องการยังเปลี่ยนทุกการรัน
- prompt พึ่งพารสนิยมและการรีวิวของมนุษย์มาก
- integration จะซ่อนการใช้เครดิตจากคนที่ต้องเข้าใจมัน
- ผลิตภัณฑ์ต้องการ public demo ก่อน automation
ในกรณีเหล่านี้ เริ่มจาก Image, Video, Audio, Chat หรือ AI Models เมื่อเส้นทางทำซ้ำได้แล้ว ค่อยย้ายส่วนที่นิ่งไป API
ไปต่อที่ไหน
- เปิด Developers สำหรับ API hub และ debugger สาธารณะ
- อ่าน Rivya API Quickstart เพื่อทำ request แรกอย่างปลอดภัย
- อ่าน API Authentication ก่อนวาง key บน server
- อ่าน API Models ก่อนเลือก model IDs
- อ่าน When to Use Rivya API Instead of Studio ถ้าขอบเขตผลิตภัณฑ์ยังไม่ชัด
- อ่าน How to Build a Multimodal AI Workflow with Rivya API เมื่อคุณกำลังวางแผน integration เต็มรูปแบบสำหรับ image, video, audio หรือ chat
