Przejdź do treści
Zasoby dla deweloperów
Zasoby dla deweloperów

Pliki i przesyłania (Files and Uploads)

Twórz, wyświetlaj, pobieraj i usuwaj trwałe pliki (Files) lub składaj plik z wieloczęściowych części Upload Parts.

Interfejs API plików przechowuje niezmienne pliki user_data, batch i batch_output o zasięgu konta i zwraca stabilne identyfikatory plików zamiast adresów URL magazynu. Używaj identyfikatora pliku, gdy API przyjmuje wielokrotnie używany zasób File, a punktu końcowego zawartości wtedy, gdy aplikacja potrzebuje dokładnych przechowywanych bajtów.

Wybierz przepływ przesyłania

  • Użyj POST /v1/files, aby utworzyć plik z jednego żądania multipart. Ukończony plik user_data może zawierać do 52,428,800 bajtów.
  • Użyj POST /v1/files z purpose=batch jako bezpośrednie wejście wsadowe do 95,000,000 bajtów.
  • Użyj Uploads API, aby wysyłać części przed złożeniem ostatecznego pliku. Każda część może zawierać do 67,108,864 bajtów; ukończony plik user_data jest ograniczony do 52,428,800 bajtów, a ukończony plik batch do 209,715,200 bajtów. Niedokończone przesyłanie wygasa po jednej godzinie.
  • Aktywne pliki i rezerwacje w toku dzielą limit przestrzeni dyskowej konta wynoszący 5,368,709,120 bajtów.

POST /api/v1/files to oddzielny tymczasowy przepływ przesyłania, który zwraca tymczasowy adres URL. SDK files.create i CLI runapi files create nadal korzystają z tego przepływu. Użyj files.createFile lub files.create_file albo polecenia CLI runapi files create-file, gdy potrzebujesz trwałego obiektu File.

Uwierzytelnianie żądania

Pliki (Files) i przesyłania (Uploads) używają standardowego klucza API RunAPI. Wyślij go jako token Bearer:

SHELL
export RUNAPI_API_KEY="runapi_..."

Każde żądanie dotyczące pliku (File), przesyłania (Upload), części (Part) i treści jest ograniczone do zakresu uwierzytelnionego konta. Identyfikator należący do innego konta zwraca 404 bez ujawniania, czy dany zasób istnieje.

Tworzenie pliku za pomocą zgodnego klienta

Wskaż bazowy URL RunAPI /v1 jako punkt końcowy klienta zgodnego z OpenAI. Żadne pola żądania specyficzne dla RunAPI nie są wymagane:

PYTHON
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RUNAPI_API_KEY"],
    base_url="https://runapi.ai/v1",
)

with open("knowledge.pdf", "rb") as source:
    file = client.files.create(file=source, purpose="user_data")

metadata = client.files.retrieve(file.id)
client.files.content(file.id).write_to_file("knowledge-copy.pdf")
client.files.delete(file.id)

Zwrócony plik nigdy nie zawiera identyfikatora magazynu, backendu ani adresu URL nośnika.

Dokumentacja interfejsu API

  • Persistent Files API obejmuje obiekt File oraz operacje tworzenia, listowania, pobierania, zawartości i usuwania.
  • Uploads API obejmuje obiekt Upload oraz operacje tworzenia, dodawania części, kończenia i anulowania.
  • Batches API obejmuje tworzenie, sprawdzanie statusu, listowanie i anulowanie wsadów moderacji.

Uruchom moderację w partii

Utwórz plik wejściowy JSONL z jednym żądaniem moderacji w każdym wierszu. Każdy wiersz używa zgodnego kształtu wsadu: custom_id, method, url ustawiony na /v1/moderations oraz body zawierający model moderacji i dane wejściowe. Plik z purpose=batch może zawierać do 50 000 żądań. Możliwość wsadowa obsługuje obecnie endpoint /v1/moderations z oknem ukończenia 24h.

SHELL
INPUT_FILE_ID=$(curl -sS https://runapi.ai/v1/files \
  -H "Authorization: Bearer $RUNAPI_API_KEY" \
  -F purpose=batch \
  -F [email protected] | jq -r .id)

BATCH_ID=$(curl -sS https://runapi.ai/v1/batches \
  -H "Authorization: Bearer $RUNAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg file "$INPUT_FILE_ID" '{input_file_id:$file,endpoint:"/v1/moderations",completion_window:"24h"}')" \
  | jq -r .id)

curl -sS "https://runapi.ai/v1/batches/$BATCH_ID" \
  -H "Authorization: Bearer $RUNAPI_API_KEY"

Użyj GET /v1/batches, aby wyświetlić listę zadań, powtarzaj GET /v1/batches/{batch_id} do momentu osiągnięcia stanu terminalnego lub wywołaj POST /v1/batches/{batch_id}/cancel, gdy zadanie jest jeszcze uruchomione. Ukończone dane wyjściowe i błędy w formacie JSONL są udostępniane jako pliki Files typu batch_output; pobierz ich metadane za pomocą GET /v1/files/{file_id}, a dokładne bajty za pomocą GET /v1/files/{file_id}/content.

Cykl życia przesyłania wieloczęściowego

Utwórz przesyłanie z ostateczną liczbą bajtów, nazwą pliku, typem MIME i purpose=user_data. Dodaj jedną lub więcej części, a następnie przekaż ich identyfikatory do complete w kolejności składania. Ukończenie zwraca przesyłanie wraz z gotowym plikiem.

SHELL
UPLOAD_ID=$(curl -sS https://runapi.ai/v1/uploads \
  -H "Authorization: Bearer $RUNAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"bytes":1048576,"filename":"archive.bin","mime_type":"application/octet-stream","purpose":"user_data"}' \
  | jq -r .id)

PART_ID=$(curl -sS "https://runapi.ai/v1/uploads/$UPLOAD_ID/parts" \
  -H "Authorization: Bearer $RUNAPI_API_KEY" \
  -F [email protected] | jq -r .id)

curl -sS "https://runapi.ai/v1/uploads/$UPLOAD_ID/complete" \
  -H "Authorization: Bearer $RUNAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"part_ids\":[\"$PART_ID\"]}"

Anuluj niedokończone przesyłanie za pomocą POST /v1/uploads/{upload_id}/cancel. Powtórzenie tego samego zamiaru ukończenia lub anulowania jest bezpieczne; konkurencyjne ukończenie, anulowanie lub wygaśnięcie zwraca 409 upload_state_conflict, gdy inny wynik końcowy już wygrał.

Zasoby CLI i SDK

Interfejs CLI udostępnia kompletny cykl życia:

SHELL
runapi files create-file knowledge.pdf
runapi files list --order desc
runapi files retrieve file_123
runapi files content file_123 --output knowledge-copy.pdf
runapi files delete file_123

runapi uploads create --bytes 1048576 --filename archive.bin --mime-type application/octet-stream
runapi uploads add-part upload_123 archive.part-01
runapi uploads complete upload_123 --part-id part_123
runapi uploads cancel upload_123

Każdy klient dostawcy (Provider Client) udostępnia zasoby files i uploads. JavaScript i PHP używają createFile / deleteFile / addPart; Python i Ruby używają create_file / delete_file / add_part; Go używa CreateFile / DeleteFile / AddPart; Java używa createFile / deleteFile / addPart. Metody list, retrieve, content, create, complete i cancel stosują konwencję nazewnictwa właściwą dla danego języka. Informacje o instalacji pakietów znajdziesz w sekcji SDKs.

Zachowanie cyklu życia

Treść pliku (File) jest niezmienna. Usunięcie pliku natychmiast wyklucza go z aktywnych list i planuje czyszczenie pamięci masowej. Ukończenie przesyłania scala części wyłącznie w podanej kolejności, a pomyślne ukończenie tworzy jeden plik. Zachowaj oryginalną kolejność identyfikatorów części (Part ID) podczas ponawiania niepewnej odpowiedzi ukończenia.