Przejrzyj źródła schematu Rivya API v1, reguły kompatybilności, pola publiczne i tylko do odczytu kontrakt OpenAPI JSON.

Rivya API v1 udostępnia kontrakt schematu tylko do odczytu pod adresem:

https://rivya.ai/api/v1/openapi.json

Ta trasa jest publicznym wyjściem kontraktu. Nie odczytuje danych sesji użytkownika, nie wysyła zadań modeli i nie ujawnia prywatnych danych konta.

Źródła Kontraktu

Kontrakt pochodzi z:

publicznych schematów żądań API
publicznych kodów błędów
publicznej warstwy referencji modeli API
tego samego katalogu modeli, którego używa /api/v1/models

Lista modeli jest dynamiczna. Nie buduj integracji zależnych od ręcznie wpisanej liczby modeli.

Polityka Wersji

Bieżąca wersja API to v1.

Zmiany kompatybilne wstecz mogą obejmować:

dodanie modelu do /api/v1/models
dodanie opcjonalnego pola odpowiedzi
dodanie opcjonalnego parametru żądania dla modelu
dodanie nowego publicznego kodu błędu

Zmiany łamiące kompatybilność wymagają nowej wersji albo udokumentowanej ścieżki migracji.

Granica Pól Publicznych

Publiczne pola schematu używają publicznych nazw:

id
status
model
session_id
message
usage
reserved_credits
final_credits
created_at
updated_at
result
error

Nie polegaj na wewnętrznych polach przechowywania zadań. Nie są częścią publicznego kontraktu.

Schemat Żądania

POST /api/v1/generations akceptuje:

model: wymagany publiczny ID modelu
prompt: opcjonalny string, wymagany przez wiele modeli
params: opcjonalny obiekt z parametrami specyficznymi dla modelu
client_request_id: opcjonalny string dla Twojego własnego ID śledzenia

Użyj Referencji modeli API dla params specyficznych dla modelu.

Media referencyjne zwrócone przez /api/v1/files należą do params.referenceMediaItems. Schemat dokumentuje url, kind, opcjonalne name, opcjonalne mimeType, opcjonalne durationSeconds i opcjonalne durationToken. Rivya nie akceptuje pola files na najwyższym poziomie w POST /api/v1/generations.

POST /api/v1/files akceptuje multipart form data z file, kind, opcjonalnym model i opcjonalnym client_request_id. Odpowiedzią jest PublicApiFile. GET /api/v1/files/{fileId} zwraca te same publiczne metadane pliku dla plików należących do konta API.

POST /api/v1/chat/completions akceptuje model, message, opcjonalne session_id, opcjonalne kontrole, opcjonalne załączniki Files API file_id i opcjonalne client_request_id. Zwraca jedną pełną niestreamingową wiadomość asystenta.

POST /api/v1/chat/completions/stream akceptuje ten sam schemat żądania i zwraca text/event-stream ze zdarzeniami session.created, message.delta, message.completed, usage.completed, heartbeat, error i done. Chat API v1 nie akceptuje surowej tablicy messages.

Schematy Odpowiedzi

Wyjście OpenAPI dokumentuje te publiczne kształty odpowiedzi:

ModelList dla GET /api/v1/models
PublicApiModel i ModelParam dla wyboru modelu i formularzy parametrów
PublicApiFile dla POST /api/v1/files i GET /api/v1/files/{fileId}
ReferenceMediaItem dla parametrów generowania opartych na plikach
PublicGeneration dla odpowiedzi tworzenia i statusu
GenerationResult i GenerationError dla ukończonych zadań
ChatCompletionRequest, ChatCompletion, ChatSession, ChatMessage, ChatUsage, ChatCredits oraz schematy zdarzeń strumienia Chat dla Chat API
CreditBalance dla GET /api/v1/credits
WebhookEndpoint, WebhookEvent, WebhookDelivery i WebhookTestResult dla podpisanych API webhooks
PublicApiError dla stabilnych odpowiedzi błędów

Schemat jest bezpieczny do użycia w walidacji klienta i wewnętrznych testach integracyjnych. Beta TypeScript SDK pozostaje ograniczona tym schematem.

Zarządzanie Przykładami

Przykłady curl, JavaScript i Python w tej dokumentacji używają tych samych publicznych nazw pól co schemat:

Authorization: Bearer rvya_sk_...
Idempotency-Key
model
prompt
message
session_id
params
client_request_id

Przykłady Chat dodatkowo używają:

chat:create
chat:read
file_id

Przykłady webhooków dodatkowo używają:

Rivya-Webhook-Signature
Rivya-Webhook-Timestamp
webhooks:manage

Gdy zmienia się parametr modelu, najpierw zaktualizuj katalog modeli i publiczny serializer. Dokumentacja i debugger powinny korzystać z tej samej publicznej warstwy zamiast kopiować osobną tabelę.

Kontrakt OpenAPI i schemat