Rivya API là gì?

Rivya API là hợp đồng dành cho nhà phát triển để dùng các khả năng mô hình Rivya được hỗ trợ trong sản phẩm, tập lệnh hoặc quy trình của bạn khi Public API đã bật cho bản triển khai và khả dụng với tài khoản.

Nó không phải một sản phẩm tách khỏi Rivya Studio. Nó dùng cùng ranh giới tài khoản, cùng ví điểm tín dụng và cùng lớp mô hình công khai mà người dùng thấy trên Rivya. Khác biệt nằm ở cách công việc bắt đầu: thay vì bấm qua Studio, ứng dụng của bạn gửi yêu cầu bằng API key.

Nếu bạn cần chi tiết điểm cuối, hãy bắt đầu với Tổng quan Rivya API và Bắt đầu nhanh với Rivya API. Bài viết này là phần giải thích ở cấp sản phẩm: API dùng để làm gì, nằm ở đâu và khi nào không nên là đường đầu tiên.

Phiên bản ngắn

Rivya API v1 cho phép tài khoản đã đăng nhập và đủ điều kiện tạo khóa API, rồi gọi các mô hình sẵn sàng cho API từ bên ngoài giao diện web. Trang nhà phát triển mô tả hợp đồng đã triển khai; bản triển khai, quyền tài khoản và trạng thái mô hình quyết định yêu cầu có chạy được hay không.

Phạm vi API đã triển khai gồm:

• khám phá mô hình qua danh sách mô hình API

• job tạo hình ảnh, video và âm thanh bất đồng bộ

• tải lên qua Files API cho các mô hình cần media tham chiếu

• polling trạng thái tạo sinh bằng công khai tác vụ IDs

• kiểm tra điểm tín dụng tài khoản

• lượt Chat API, bao gồm SSE truyền theo luồng tùy chọn

• webhook đã ký cho sự kiện hoàn tất tạo nội dung khi webhook được bật cho bản triển khai

• TypeScript SDK thử nghiệm cho đội muốn có ứng dụng khách lớp bao

Hub nhà phát triển công khai là Developers. Đây là điểm vào tốt nhất nếu bạn muốn tổng quan có hướng dẫn, liên kết tới cài đặt API key và một luồng debugger an toàn.

Vì sao Rivya có API

Studio hữu ích khi một người vẫn đang chọn mô hình, định hình câu lệnh, rà soát đầu ra và quyết định làm gì tiếp theo.

API hữu ích khi quyết định đó đã biến thành một quy trình sản phẩm hoặc vận hành có thể lặp lại.

Các ví dụ phổ biến, khi quyền truy cập API đã bật, gồm:

• một sản phẩm muốn tạo biến thể hình ảnh sau khi người dùng gửi brief

• một quy trình marketing cần tạo bản nháp hình ảnh từ đầu vào chiến dịch có cấu trúc

• một công cụ nội bộ cần gửi job video hoặc âm thanh mà không yêu cầu ai mở trình duyệt

• một hệ thống hỗ trợ hoặc nội dung muốn có một lượt mô hình trò chuyện trong giao diện riêng

• một dịch vụ backend muốn callback có chữ ký khi job tạo sinh hoàn tất

Trong các trường hợp đó, Rivya API giữ công việc gắn với cùng tài khoản Rivya thay vì buộc bạn dựng một stack riêng cho thanh toán, lựa chọn mô hình và trạng thái nhiệm vụ.

API không thay thế điều gì

API không thay thế mọi lý do để dùng Rivya trực tiếp.

Dùng Hướng dẫn Rivya Studio hoặc các khu vực làm việc công khai khi:

• câu lệnh vẫn cần con người khám phá

• lựa chọn mô hình chưa ổn định

• creator cần so sánh đầu ra bằng mắt

• dự án phụ thuộc vào lịch sử đã lưu và rà soát thủ công

• đội chưa quyết định định dạng đầu vào và đầu ra nào nên trở thành phần lặp lại được

Dùng API khi quy trình đã đủ rõ để tự động hóa.

Ranh giới đó quan trọng. Một câu hỏi sáng tạo mơ hồ thường thuộc về Studio trước. Một luồng sản phẩm đã biết với đầu vào dự đoán được có thể chuyển sang API.

Các khối xây dựng chính

Hãy xem API như sáu phần được kết nối.

Tài liệu API là nguồn chuẩn cho dạng yêu cầu và phản hồi. Bài viết này chỉ giúp bạn quyết định phần nào cần dùng trước.

Điểm tín dụng hoạt động thế nào

Việc dùng API rút từ cùng ví điểm tín dụng tài khoản Rivya như Studio.

Điều đó nghĩa là API không phải proxy mô hình ẩn danh. Một yêu cầu thuộc về một tài khoản Rivya, dùng API key do tài khoản đó tạo và tuân theo cùng ranh giới điểm tín dụng cấp sản phẩm được mô tả trong API Điểm tín dụng.

Điều này hữu ích cho đội vì thử nghiệm trong Studio và sử dụng API vẫn nằm trong một mô hình vận hành. Bạn có thể kiểm thử mô hình thủ công, rồi chuyển phần lặp lại được vào tích hợp mà không tạo thêm lớp thanh toán thứ hai.

Tệp đầu vào nằm ở đâu

Một số mô hình có thể chạy chỉ từ văn bản. Một số khác cần ảnh, video hoặc âm thanh tham chiếu.

Với tích hợp API, các tham chiếu đó nên đi qua Files API. Việc tải lên tạo một bản ghi tệp được quản lý, có thể truyền vào các tham số mô hình được hỗ trợ.

Quy tắc thực tế rất đơn giản:

• nếu mô hình nhận đầu vào chỉ văn bản, hãy bắt đầu với tạo nội dung điểm cuối

• nếu mô hình cần media tham chiếu, hãy tải tệp lên trước

• nếu mô hình trò chuyện cần ảnh đính kèm, hãy dùng Chat API và tệp IDs

Đừng thiết kế tích hợp quanh luồng tải lên chỉ có trong trình duyệt hoặc phiên Studio đã lưu. API có ranh giới tệp công khai riêng vì một lý do rõ ràng.

Webhooks giúp ở đâu

Polling là đường tích hợp đầu tiên dễ nhất. Gửi một tạo nội dung job, lưu công khai tác vụ ID và thăm dò cho đến khi thành công hoặc thất bại.

Khi webhook được bật cho bản triển khai, tính năng này hữu ích hơn khi tích hợp tiến gần môi trường sản xuất:

• bạn không muốn một worker thăm dò mọi job

• ứng dụng cần cập nhật bản ghi khi tạo sinh hoàn tất

• bạn muốn một sự kiện có chữ ký và có thể thử lại an toàn

• job thất bại cần đi vào một đường phục hồi rõ ràng

Để dùng hợp đồng sự kiện đã ký, hãy xem API Webhooks. Xác nhận tính năng khả dụng trước khi thiết kế phụ thuộc vào nó. Giữ bộ nhận webhook gọn: xác minh chữ ký, xử lý sự kiện trùng lặp và không ghi giá trị bí mật vào log.

Một dự án API đầu tiên tốt

Dự án API đầu tiên tốt nhất thường nhỏ và cụ thể.

Ví dụ:

1. xác nhận quyền truy cập API đã bật cho bản triển khai và tài khoản

2. tạo khóa API trong phần cài đặt

3. gọi danh sách mô hình

4. chọn một mô hình sẵn sàng cho API

5. gửi tác vụ tạo nội dung với khóa idempotency

6. polling điểm cuối trạng thái

7. kiểm tra điểm tín dụng trước và sau

8. sau đó mới thêm Files API, Chat API hoặc Webhooks mà bản triển khai cung cấp

Đường đi đó cho bạn một tích hợp hoạt động mà không trộn mọi tính năng API vào lần kiểm thử đầu tiên.

Khi API là điểm bắt đầu sai

API có lẽ không phải bước đầu đúng khi:

• đội chưa chọn họ mô hình

• đầu ra mong muốn vẫn thay đổi ở mỗi lượt chạy

• câu lệnh phụ thuộc vào gu và rà soát thủ công

• tích hợp sẽ che khuất việc dùng điểm tín dụng khỏi những người cần hiểu nó

• sản phẩm cần demo công khai trước khi cần tự động hóa

Trong các trường hợp đó, hãy bắt đầu từ Image, Video, Audio, Chat hoặc AI Models. Khi đường đi đã lặp lại được, hãy chuyển phần ổn định sang API.

Nên đi tiếp đến đâu

• Mở Developers để xem hub API công khai và debugger.

• Đọc Bắt đầu nhanh với Rivya API để tạo yêu cầu an toàn đầu tiên.

• Đọc Xác thực API trước khi đặt key lên máy chủ.

• Đọc Mô hình API trước khi chọn mô hình IDs.

• Đọc Khi nào nên dùng Rivya API thay vì Studio nếu ranh giới sản phẩm vẫn chưa rõ.

• Đọc Cách xây quy trình AI đa phương thức với Rivya API khi bạn đang lập kế hoạch tích hợp đầy đủ cho hình ảnh, video, âm thanh hoặc trò chuyện.