Skip to main content
Per le richieste che richiedono più di qualche secondo, tipiche nelle applicazioni di intelligenza artificiale, abbiamo sviluppato un sistema di code. Questo sistema ti offre un controllo granulare per gestire i picchi di traffico, annullare le richieste se necessario e monitorare lo stato della tua richiesta in coda. Elimina anche la necessità di gestire richieste HTTP a lunga esecuzione.

Endpoint della coda

Puoi accedere a tutte le funzionalità della coda tramite i seguenti endpoint: Ad esempio, per inviare una richiesta utilizzando curl e aggiungerla alla coda:
Ecco una risposta di esempio che include il request_id:
Il payload include il request_id e fornisce URL per controllare lo stato, annullare o recuperare la risposta, semplificando il flusso di lavoro senza ulteriore sviluppo di endpoint.

Stato della richiesta

Per monitorare l’avanzamento della tua richiesta, utilizza l’endpoint fornito con il tuo ID richiesta univoco. Ciò ti consente di tenere traccia dello stato, della posizione in coda o di recuperare la risposta una volta pronta.

Utilizzo dell’endpoint

Risposta di esempio

Quando la tua richiesta è in coda, riceverai una risposta come questa:

Stati possibili

La tua richiesta può trovarsi in uno dei tre stati seguenti:
  • IN_QUEUE: indica che la richiesta è in attesa di essere elaborata.
    • queue_position: mostra la tua posizione nella coda.
    • response_url: URL per recuperare la risposta una volta completata l’elaborazione.
  • IN_PROGRESS: la richiesta è attualmente in fase di elaborazione.
    • logs: log dettagliati (se abilitati) che mostrano i passaggi di elaborazione.
    • response_url: dove sarà disponibile la risposta finale.
  • COMPLETED: l’elaborazione è terminata.
    • logs: log che descrivono in dettaglio l’intero processo.
    • response_url: link diretto alla tua risposta completata.

Abilitazione dei log

I log forniscono informazioni dettagliate sull’elaborazione delle richieste. Sono disabilitati per impostazione predefinita ma possono essere abilitati con un parametro di query:
Ogni voce di log include:
  • message: descrizione dell’evento.
  • level: gravità (ad esempio, INFO, ERROR).
  • source: origine del log.
  • timestamp: ora in cui è stato generato il log.

Monitoraggio in tempo reale

Per aggiornamenti continui, utilizza l’endpoint di streaming:
Ciò fornisce aggiornamenti di stato in tempo reale in formato text/event-stream fino al completamento della richiesta.

Webhooks

Se preferisci essere notificato invece di fare polling, passa un parametro di query webhook al momento dell’invio della richiesta. Sunra eseguirà un POST con il risultato finale a quell’URL non appena la richiesta raggiunge uno stato terminale, quindi non è necessario mantenere una connessione aperta o pianificare il polling.

Abilitazione dei Webhooks

Aggiungi un parametro di query webhook codificato come URL all’endpoint di invio:
Codifica l’URL del webhook come URL (es. https%3A%2F%2F...) e assicurati che Sunra possa raggiungerlo; HTTPS è fortemente consigliato. La risposta di invio rimane invariata — ricevi sempre un request_id e gli stessi URL di status/cancel/response.

Quando viene attivato il Webhook

Sunra chiama il tuo webhook solo per eventi terminali:
  • succeeded — la richiesta è stata completata e l’output è incluso nel payload.
  • failed — la richiesta è fallita e i dettagli dell’errore sono inclusi nel payload.
Gli stati intermedi (IN_QUEUE, IN_PROGRESS) non attivano un webhook. Se hai bisogno anche di aggiornamenti di avanzamento, combina il webhook con gli endpoint di streaming o polling descritti sopra.

Formato della Richiesta

Sunra invia una richiesta POST al tuo URL webhook con: Il tuo endpoint deve rispondere con un codice di stato 2xx entro 5 secondi. Conferma rapidamente e delega il lavoro pesante a un job in background — risposte lente vengono trattate come fallimenti e attivano i tentativi.

Payload

Un evento di successo:
Un evento di fallimento sostituisce output con error. Il contenuto esatto di error varia a seconda del tipo di fallimento — l’esempio seguente mostra una forma comune:

Comportamento dei Tentativi

La consegna del webhook è almeno-una-volta. Se il tuo endpoint va in timeout (5 s) o restituisce uno stato non-2xx, Sunra riprova con backoff esponenziale — fino a 3 tentativi con ritardi a partire da 10 secondi e limitati a 30 secondi. Dopo l’ultimo tentativo, il fallimento viene registrato e non vengono effettuati ulteriori tentativi. Poiché i tentativi possono consegnare lo stesso evento più di una volta, il tuo handler dovrebbe essere idempotente — usa il campo id come chiave di deduplicazione.

Best Practice

  • Usa HTTPS e verifica che il traffico raggiunga l’endpoint atteso.
  • Rispondi 2xx immediatamente e processa il payload in modo asincrono.
  • Considera la consegna come almeno-una-volta e deduplica per id.
  • Combina i webhook con gli endpoint di polling o streaming se hai bisogno di aggiornamenti di avanzamento prima dell’evento terminale.

Annullamento delle richieste

Se la tua richiesta è ancora in coda, puoi annullarla con:

Recupero delle risposte

Una volta che la tua richiesta è COMPLETED, recupera la risposta utilizzando:
Questo endpoint fornisce anche i log per la revisione.

Integrazione semplificata con il client Sunra

Il client Sunra automatizza il monitoraggio dello stato, semplificando lo sviluppo di app con le funzioni Sunra.

Limiti di velocità

Per garantire un utilizzo equo e la stabilità del sistema, i nostri endpoint API sono soggetti ai seguenti limiti di velocità: Se si superano questi limiti, si riceverà una risposta 403 Forbidden. Si consiglia di implementare un meccanismo di tentativi con backoff esponenziale per gestire questi casi.