async: true: a API responde de imediato com a execução, e você consultaGET /v2/chat/completions/{id}até ela terminar.webhook_url: a execução se torna assíncrona automaticamente, e o Tela envia o resultado por POST para a sua URL quando ela termina.
GET /v1/completion-run.
A
webhook_url de uma completion avisa sobre aquela única execução. Não é a mesma coisa que os Eventos da Workstation, que são assinaturas configuradas em um App e disparam para toda tarefa daquele App.O objeto da execução
Chamadas assíncronas respondem com a execução em vez de umchat.completion. O mesmo objeto é retornado no polling e enviado para o seu webhook. O seu status vai de created para running, e então para succeeded ou failed.
O que uma execução com
status: "failed" traz sobre a falha não está documentado aqui. Trate failed como final e verifique a execução no Usage do Canvas.Usando a flag async
Acrescenteasync: true ao corpo. A resposta é a execução com status: "created".
Consultando o resultado
ChameGET /v2/chat/completions/{id} com o ID da execução até o status ser succeeded ou failed, e então leia output_content.content. Os exemplos abaixo iniciam uma execução e a consultam no mesmo script.
Usando uma URL de webhook
Passe umawebhook_url e a execução se torna assíncrona sem a flag async. A resposta imediata é a execução com status: "created"; quando a execução termina, o Tela envia uma requisição POST para a sua URL.
O callback
O seu endpoint recebe umPOST com:
- Headers:
Content-Type: application/jsonex-completion-run-id, o ID da execução. Use-o para associar o callback à execução que você criou, já que é o mesmoidretornado na resposta de criação. - Corpo: o objeto da execução com o seu
statusfinal (succeededoufailed) e, em caso de sucesso, a resposta emoutput_content.contenteraw_output.
2xx, e processe depois. Não está documentado aqui se a entrega é repetida quando o seu endpoint falha; se você precisa de garantia, consulte também GET /v2/chat/completions/{id} para as execuções que não deram retorno depois de um tempo.
Listando execuções anteriores
Toda completion, síncrona ou não, é guardada como uma completion run.GET /v1/completion-run retorna as execuções do seu Workspace, da mais recentemente atualizada para a mais antiga, para você auditar o que rodou, conciliar um lote ou encontrar uma execução cujo callback você perdeu.
cURL
data e um objeto meta com totalCount, limit, offset, currentPage, totalPages e links (first, last, next, previous). Cada execução tem as mesmas informações do objeto da execução acima, com duas diferenças: as chaves são camelCase (inputContent, rawInput, promptVersionId) e ela acrescenta tags, creditsUsed, promptId e um metadata com um retrato da versão que executou (modelConfigurations, variablesDefinitions e, quando a requisição usou um ambiente, requestedEnvironmentName).
Resposta
member ou superior; chaves de API do Workspace atendem a isso. Quando você filtra por promptId, promptVersionId ou promptApplicationId, o recurso precisa estar acessível para a sua chave, caso contrário a chamada retorna 404.
Para ler uma execução pelo ID a qualquer momento, use GET /v2/chat/completions/{id}, como em Consultando o resultado. Os detalhes completos de parâmetros e schemas estão na referência da API: Run Canvas, Retrieve Canvas Run e List completion runs.