> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Conectando a sua própria API
> Envie o documento OpenAPI do seu serviço para o Flowker e chame as operações dele a partir de um nó de workflow. Registre o documento, aponte uma configuração de provedor para ele e enderece uma operação por nó.
O Flowker vem com conectores para os serviços do catálogo dele. O serviço que você quer chamar também pode ser o seu: uma API interna, uma API de parceiro, qualquer coisa com um documento OpenAPI publicado. Você envia esse documento, e um nó de workflow chama as operações dele diretamente.
Você faz isso uma vez por documento. Envie ele, crie uma configuração de provedor que aponta para ele, depois enderece uma operação a partir de cada nó que chama o serviço.
## Antes de começar
***
* O documento OpenAPI 3.x do seu serviço como arquivo, com no máximo 8 MiB, declarando pelo menos uma operação.
* As credenciais que o seu serviço exige e o método de autenticação que ele espera. Veja [Autenticação](/pt/products/flowker/integration-guide#authentication) para os métodos aos quais o Flowker oferece suporte.
* Um deploy cujo registro de schemas tem armazenamento de blobs configurado. `SCHEMA_REGISTRY_S3_BUCKET` guarda os documentos OpenAPI que você envia. Veja [Variáveis de ambiente do Flowker](/pt/products/flowker/flowker-environment-variables).
* Um workflow em status `draft` para editar. Um workflow ativo fica travado. Desative ele primeiro, depois mova o workflow inativo para `draft` antes de editar e ativar de novo.
O Lerian Console cobre o mesmo caminho. Em **Providers → + Novo Provider → Adicionar sua própria API**, você seleciona um documento já enviado e define a URL base e a autenticação. Veja [Adicionando um provider](/pt/products/flowker/console/adding-a-provider).
Etapa 1: Envie o documento OpenAPI
***
Chame [Enviar um schema OpenAPI](/pt/reference/products/flowker/upload-openapi-schema) como `multipart/form-data` com três partes: o `file`, um `name` e uma `version`.
```bash theme={null}
curl -X POST https://your-flowker-host/v1/openapi-schemas \
-H "Authorization: Bearer $TOKEN" \
-F "file=@acme-kyc.json" \
-F "name=acme-kyc" \
-F "version=v1.0.0"
```
A resposta `201` descreve o que o Flowker leu do arquivo. O `id` dela é o valor que toda etapa posterior referencia.
| Campo | O que ele diz a você |
| ------------------------- | ---------------------------------------------------------------------------------------------------- |
| `id` | O identificador do documento. Uma configuração de provedor e um gatilho de webhook apontam para ele. |
| `name`, `version` | O par que você enviou. |
| `title` | O `info.title` do documento. |
| `openapiVersion` | A versão `openapi` que o documento declara. |
| `operationCount` | Quantas operações de caminho e método o documento declara. |
| `contentHash`, `byteSize` | O digest e o tamanho do arquivo armazenado. |
| `createdBy`, `createdAt` | Quem enviou e quando. |
### Pelo que um documento armazenado é indexado
`name` e `version` são seus para escolher, com até 255 caracteres cada. O par é único no seu tenant: enviar o mesmo `name` e a mesma `version` de novo responde `FLK-0812`. O `id` que o Flowker retorna é um UUID novo a cada envio. Todo o resto referencia esse id, nunca o nome nem a versão.
O Flowker faz o parse do arquivo antes de armazenar. Um arquivo que não é um documento OpenAPI 3.x, ou um que não declara nenhuma operação, responde `FLK-0900`. Um arquivo acima de 8 MiB responde `FLK-0901`.
Os documentos que você envia são apenas seus. Um documento é visível apenas para o tenant que o enviou, e um id de outro tenant nunca resolve.
## Etapa 2: Leia as operações que você pode chamar
***
[Listar schemas OpenAPI](/pt/reference/products/flowker/list-openapi-schemas) retorna os seus documentos apenas como metadados, sem o conteúdo deles. É paginado: `limit`, `cursor`, `sortBy` e `sortOrder`, e a resposta leva `nextCursor` e `hasMore`.
[Obter um schema OpenAPI](/pt/reference/products/flowker/get-openapi-schema) retorna os mesmos metadados mais `content` (o arquivo armazenado) e `operations`, uma entrada por operação que o documento declara.
| Campo | O que ele diz a você |
| ------------- | ------------------------------------------------------------------------------ |
| `path` | O caminho da operação, exatamente como o documento escreve, como `/v1/checks`. |
| `method` | O método HTTP da operação. |
| `operationId` | O `operationId` do documento, quando ele declara um. |
| `hasRequest` | Se a operação declara um corpo de requisição JSON. |
| `hasResponse` | Se a operação declara uma resposta JSON de sucesso. |
Copie o `path` e o `method` da operação que você quer. A Etapa 4 coloca eles no nó.
[Derivar o schema de uma operação](/pt/reference/products/flowker/derive-openapi-operation-schema) recebe um `path` e um `method` e retorna `inputSchema` para o corpo de requisição `application/json` da operação e `outputSchema` para a primeira resposta `application/json` 2xx dela. Cada um desses campos fica ausente quando o documento não declara esse schema. Para um corpo de requisição que não é JSON, use `hasBody`, `bodyRequired` e `bodyContentType`. Ele também retorna `params`, uma entrada por parâmetro que a operação declara, cada uma com o `name`, a localização `in` e se ela é `required`.
Esses são os nomes de campo que você escreve como alvos e origens de mapeamento na Etapa 4. Os dois parâmetros de query são obrigatórios, e `method` não diferencia maiúsculas de minúsculas e deve ser um de `GET`, `PUT`, `POST`, `DELETE`, `OPTIONS`, `HEAD`, `PATCH` ou `TRACE`. Um `path` ausente ou um `method` não reconhecido responde `FLK-0304`. Um caminho e um método que o documento não declara respondem `FLK-0902`.
## Etapa 3: Aponte uma configuração de provedor para o documento
***
Chame [Criar uma configuração de provedor](/pt/reference/products/flowker/create-provider-configuration) com `kind` definido como `external_openapi`. Esse kind referencia o documento que você enviou em vez de um provedor do catálogo.
| Campo | Obrigatório | Descrição |
| -------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `kind` | Sim | `"external_openapi"`. Você escolhe o kind quando cria a configuração, e ele continua sendo o kind com que a configuração foi criada. |
| `providerId` | Não | Omita ele — esta conexão tem como alvo o seu próprio documento, não um provedor do catálogo. Uma leitura da configuração então retorna o id reservado `external.openapi`. |
| `name` | Sim | Um nome para esta conexão, de 1 a 100 caracteres. |
| `config.openapi_schema_id` | Sim | O `id` da [Etapa 1](#step-1-upload-the-openapi-document). Ele deve nomear um documento no seu tenant. |
| `config.base_url` | Não | O esquema, o host e o prefixo de caminho para onde o Flowker envia as requisições. Omita ele para usar a primeira entrada `servers` utilizável do documento. |
| `config.auth` | Não | Um bloco de autenticação `{ type, config }`, no mesmo formato que toda configuração de provedor usa. Veja [Autenticação](/pt/products/flowker/integration-guide#authentication) para cada tipo e os campos dele. Omita ele para um serviço que não precisa de autenticação. |
| `config.headers` | Não | Headers HTTP estáticos para toda requisição por esta conexão. Deve ser um objeto de nomes de header válidos e não vazios com valores de string; os nomes não devem colidir sem diferenciar maiúsculas de minúsculas. Os valores podem usar referências de template resolvidas no momento da requisição. |
| `allowedHosts` | Não | Os hosts que esta configuração pode chamar. Omita ele, ou envie uma lista vazia, para aceitar qualquer host público. |
| `allowedPrivateHosts` | Não | Hosts privados nomeados que esta configuração pode alcançar. Endereços de metadados de nuvem e link-local continuam bloqueados. |
| `schemaBindings` | Não | Os documentos armazenados aos quais esta configuração se vincula. Veja [Vincule o documento](#bind-the-document). |
| `description` | Não | Texto livre, com até 500 caracteres. |
| `metadata` | Não | Os seus próprios pares de chave e valor. |
O `config.headers` é armazenado com a configuração de provedor e pode ser retornado por leituras da configuração. Nunca coloque chaves de API, tokens, cookies ou outros segredos ali. Coloque as credenciais em `config.auth`, cujos valores secretos são apenas de escrita e ficam no backend de segredos configurado.
### Onde a credencial fica
O segredo dentro de `config.auth` é apenas de escrita na criação e na atualização. O Flowker envia ele para o seu backend de segredos e remove ele do documento de configuração antes de salvar o documento. O Flowker resolve o segredo a partir do backend em tempo de execução. Para uma configuração `external_openapi`, a busca por id não resolve nem retorna os valores secretos em `config.auth`. Mantenha as credenciais em `config.auth`. Uma leitura pode retornar outros valores de configuração.
Para rotacionar um segredo depois, envie o novo valor em uma atualização. Para manter o atual, omita o campo ou envie ele em branco enquanto `auth.type` continua o mesmo. Veja [Autenticação](/pt/products/flowker/integration-guide#authentication).
### Onde as listas de hosts permitidos são definidas
As duas listas de permissão pertencem a esta chamada de criação e, depois, a [Atualizar uma configuração de provedor](/pt/reference/products/flowker/update-provider-configuration). A lista `allowedHosts` nomeia os hosts que cada nó que chama por esta configuração pode alcançar. O Flowker confere a URL da requisição e cada salto de redirecionamento contra ela em tempo de execução. Uma entrada com ponto inicial casa com subdomínios, então `.acme-kyc.example.com` casa com `api.acme-kyc.example.com`. As entradas são apenas nomes de host, sem IP literal, sem curinga e sem porta.
`allowedPrivateHosts` é a lista complementar para um serviço que fica em uma rede privada. Ela não sobrescreve `allowedHosts`: quando `allowedHosts` não está vazia, ela também deve incluir o host privado. Uma entrada `allowedPrivateHosts` correspondente apenas levanta o bloqueio de IP privado ou de loopback. Endereços de metadados de nuvem e link-local continuam bloqueados.
Vincule o documento
Adicione uma entrada `schemaBindings` para o documento que você referenciou. Cada entrada nomeia um documento armazenado. Defina `type` como `"openapi"` e `schemaId` com o mesmo id que você colocou em `config.openapi_schema_id`. O array `operations` opcional delimita o vínculo armazenado. O Flowker valida esse array contra o documento quando você salva a configuração.
Esse array não verifica o que os nós de workflow chamam, e não limita um nó `external_openapi` em tempo de execução. O nó usa `config.openapi_schema_id`, `operation_path` e `operation_method`.
O vínculo é o que torna visíveis os dependentes do documento. Com ele, [Listar recursos que referenciam um schema OpenAPI](/pt/reference/products/flowker/list-openapi-schema-references) informa esta configuração, e uma exclusão do documento é recusada enquanto a configuração está ativa. Veja [Removendo um documento](#removing-a-document).
O Flowker resolve cada vínculo quando você salva. Um `schemaId` que não nomeia nenhum documento no seu tenant responde `FLK-0942`, e uma entrada `operations` que o documento não declara responde `FLK-0943`, cada um nomeando a entrada que falhou. Uma entrada malformada responde `FLK-0293`. Malformada significa um `type` desconhecido, um `schemaId` que não é um UUID, `operations` em um vínculo que não é `openapi`, ou uma operação sem caminho ou sem método.
```json theme={null}
POST /v1/provider-configurations
{
"name": "Acme KYC production",
"description": "Production KYC checks",
"kind": "external_openapi",
"config": {
"openapi_schema_id": "018f3e2a-1c4d-7b9e-a1b2-c3d4e5f6a7b8",
"base_url": "https://api.acme-kyc.example.com",
"auth": {
"type": "api_key",
"config": {
"key": "sk-live-xxx",
"header_name": "X-API-Key",
"location": "header"
}
}
},
"allowedHosts": ["api.acme-kyc.example.com"],
"schemaBindings": [
{
"type": "openapi",
"schemaId": "018f3e2a-1c4d-7b9e-a1b2-c3d4e5f6a7b8",
"operations": [
{ "path": "/v1/checks", "method": "POST" },
{ "path": "/v1/checks/{checkId}", "method": "GET" }
]
}
]
}
```
A resposta retorna o `id` da nova configuração. Guarde ele. A [Etapa 4](#step-4-address-an-operation-from-a-workflow-node) coloca ele no `providerConfigId` de cada nó que chama este serviço.
O Flowker confere a configuração antes de armazenar. Um `config` sem `openapi_schema_id`, ou um cujo valor não é um UUID, responde `FLK-0946`. Um id que não nomeia nenhum documento no seu tenant responde `FLK-0947`. Um bloco `config.auth` que o Flowker não consegue ler (um tipo desconhecido, ou um tipo sem um dos campos obrigatórios dele) responde `FLK-0948`. Um bloco `config.headers` malformado responde `FLK-0955`.
O Flowker não chama a sua API de destino aqui. Ele lê o documento referenciado e, quando `config.auth` contém um segredo, escreve esse segredo no backend de segredos configurado antes de persistir a configuração.
Etapa 4: Enderece uma operação a partir de um nó de workflow
***
Um nó executor nomeia uma operação do documento com dois campos no `data` dele, ao lado do `providerConfigId` da configuração da Etapa 3.
| Campo | Obrigatório | Descrição |
| ------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `providerConfigId` | Sim | O UUID da configuração de provedor que aponta para o documento. |
| `operation_path` | Para rodar | O caminho da operação, exatamente como o documento escreve, incluindo os templates de parâmetro `{...}` dele. |
| `operation_method` | Para rodar | O método HTTP da operação. A correspondência não diferencia maiúsculas de minúsculas. |
| `inputMapping` | Não | Move valores do contexto do workflow para dentro da requisição. Cada `target` é um caminho no corpo de requisição da operação, ou um nome de parâmetro. |
| `outputMapping` | Não | Tira valores da resposta para os nós posteriores lerem. |
Não envie `executorId` em um nó desses. O Flowker resolve a configuração de provedor, reconhece o kind e preenche o campo por você antes de validar o workflow. O caminho de salvamento pode persistir um nó sem um dos campos de operação, mas a execução então falha com `FLK-0950` antes de o Flowker enviar uma requisição. Todos os outros campos do nó se comportam como [Referenciar a configuração de provedor a partir de um nó de workflow](/pt/products/flowker/integration-guide#step-3-reference-the-provider-configuration-from-a-workflow-node) descreve.
### Como a requisição é montada
O Flowker lê a operação do documento armazenado em tempo de execução e monta a requisição a partir dela:
* **O destino** é `config.base_url` quando a configuração define esse campo, caso contrário a primeira entrada `servers` utilizável do documento, unida com `operation_path`.
* **Um parâmetro `path`** pega o valor dele primeiro dos dados resolvidos do nó e, em segundo lugar, do corpo da requisição. Cada parâmetro `path` precisa de um valor.
* **Um parâmetro `query` ou `header`** resolve do mesmo jeito. Um parâmetro opcional sem valor fica de fora. Um parâmetro obrigatório sem valor faz o nó falhar antes de qualquer requisição sair do Flowker, com `FLK-0954`. Um valor estático de `config.headers` ou a autenticação configurada pode satisfazer um parâmetro de header obrigatório.
* **O corpo da requisição** com o `request_format` padrão (`json`) é o que o seu `inputMapping` monta. Com `xml_converted`, o Flowker serializa esse objeto mapeado como XML. Com `xml_passthrough`, o Flowker ignora o mapeamento e encaminha os bytes XML originais do gatilho de webhook. Escreva cada `target` exatamente como o schema de requisição da operação o nomeia. Não há objeto invólucro nem prefixo a acrescentar. [Trabalhando com dados de requisição e resposta](/pt/products/flowker/working-with-request-and-response-data) cobre mapeamentos e transformações por completo.
```json theme={null}
POST /v1/workflows
{
"name": "kyc-check",
"description": "Opens a KYC check on the Acme API and records the result.",
"nodes": [
{
"id": "kyc-received",
"type": "trigger",
"name": "KYC request received",
"position": { "x": 0, "y": 0 },
"data": {
"triggerType": "webhook",
"path": "kyc/requested",
"method": "POST",
"input_contract": "open",
"format": "json"
}
},
{
"id": "open-check",
"type": "executor",
"name": "Open KYC check",
"position": { "x": 200, "y": 0 },
"data": {
"providerConfigId": "019c96a0-0ac0-7de9-9f53-9cf842a2ee5a",
"operation_path": "/v1/checks",
"operation_method": "POST",
"inputMapping": [
{ "source": "workflow.documentNumber", "target": "documentNumber" },
{ "source": "workflow.fullName", "target": "fullName" }
],
"outputMapping": [
{ "source": "body.checkId", "target": "checkId" },
{ "source": "body.status", "target": "status" }
]
}
},
{
"id": "record-check",
"type": "action",
"name": "Record the check",
"position": { "x": 400, "y": 0 },
"data": {
"actionType": "set_output",
"output": {
"checkId": "${open-check.checkId}",
"status": "${open-check.status}"
}
}
}
],
"edges": [
{ "id": "e1", "source": "kyc-received", "target": "open-check" },
{ "id": "e2", "source": "open-check", "target": "record-check" }
]
}
```
O nó `open-check` envia `POST https://api.acme-kyc.example.com/v1/checks` com o corpo que o `inputMapping` dele montou. O `outputMapping` dele levanta dois campos da resposta, então o próximo nó lê `${open-check.checkId}`.
Um nó que chama `GET /v1/checks/{checkId}` em vez disso lê o parâmetro do mesmo escopo de nó. Mapeie um valor para `checkId`, e o Flowker substitui ele no caminho.
Um gatilho de webhook pode validar o payload de entrada contra uma operação do mesmo documento. Defina `input_contract` como `"openapi"` e dê ao gatilho `openapi_schema_id`, `operation_path` e `operation_method`. Veja [Configurando um gatilho de webhook](/pt/products/flowker/configuring-a-webhook-trigger).
## Etapa 5: Rode e confirme que funcionou
***
Chame [Ativar um workflow](/pt/reference/products/flowker/activate-workflow). A ativação registra a rota de webhook e resolve o que o contrato do gatilho referencia.
Chame [Executar um workflow](/pt/reference/products/flowker/execute-workflow) com um header `Idempotency-Key` novo, ou envie uma requisição para a rota de webhook.
Um nó que alcançou o seu serviço registra a resposta sob o próprio id. Com um `outputMapping`, os nomes mapeados ficam diretamente sob esse id: `open-check.checkId`. Sem um `outputMapping`, a saída do nó mantém o envelope da resposta, então o corpo da resposta fica um nível abaixo, sob `body`.
## Publicando uma nova versão do seu documento
***
Um documento armazenado não muda. Para entregar uma revisão, envie o arquivo de novo sob uma `version` nova. Isso dá a você um segundo documento armazenado com o próprio `id`.
Enviar um documento novo não muda as configurações existentes. Porém, cada nó executor lê a configuração de provedor dele quando roda. Atualizar `config.openapi_schema_id` pode mudar o documento usado por nós posteriores de uma execução em andamento, então coordene a virada.
Envie o `config` da configuração de provedor com o id novo por [Atualizar uma configuração de provedor](/pt/reference/products/flowker/update-provider-configuration). O campo `config` substitui o mapa armazenado em vez de se fundir a ele. Inclua na mesma chamada os valores `base_url` e `auth` configurados que você precisa manter. O Flowker revalida o id novo contra o seu tenant e responde `FLK-0947` quando ele não resolve.
Verifique [Listar recursos que referenciam um schema OpenAPI](/pt/reference/products/flowker/list-openapi-schema-references) no documento anterior antes de aposentar ele. A resposta é uma lista de exibição, não um inventário completo: ela retorna até 100 entradas em cada um dos dois grupos dela. Uma configuração de provedor ativa além desse limite de exibição ainda bloqueia a exclusão.
## Versões de spec para os serviços do catálogo
***
Os serviços do próprio catálogo do Flowker resolvem contra um registro compartilhado e separado de specs publicadas. Três operações gerenciam esse registro. Elas nunca tocam em um documento que você enviou na Etapa 1.
| Operação | O que ela faz |
| ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Listar versões de spec OpenAPI](/pt/reference/products/flowker/list-openapi-spec-versions) | Lista as versões publicadas da spec de um serviço em `versions`, e informa a que o seu tenant fixou em `pinnedVersion`. `pinnedVersion` fica vazio quando o seu tenant não fixou nenhuma. |
| [Fixar uma versão de spec OpenAPI](/pt/reference/products/flowker/pin-openapi-spec-version) | Seleciona a versão contra a qual o seu tenant resolve para aquele serviço. É idempotente: fixar de novo substitui a versão no lugar. Uma requisição sem o serviço ou sem a versão responde `FLK-0801`. |
| [Enviar uma versão de spec OpenAPI](/pt/reference/products/flowker/upload-openapi-spec-version) | Publica uma versão da spec de um serviço, para todos os tenants. As versões são imutáveis: um par `service` e `version` que já existe responde `FLK-0803`. Quem chama precisa da permissão `create` no recurso `catalog`. |
A fixação é por tenant. Publicar uma versão não muda nada para um tenant até que esse tenant a fixe. Um envio novo, portanto, nunca move um workflow em execução para uma spec diferente. O Flowker lê a sua versão fixada quando informa os schemas de executor daquele serviço no catálogo, então [Obter um executor do catálogo](/pt/reference/products/flowker/get-catalog-executor) descreve a versão que você escolheu.
Removendo um documento
***
[Listar recursos que referenciam um schema OpenAPI](/pt/reference/products/flowker/list-openapi-schema-references) retorna dois grupos, `providerConfigurations` e `workflows`. Os dois estão sempre presentes, cada um leva até 100 entradas, e cada entrada leva um `id`, um `name` e um `status`. É uma lista de exibição, não um inventário completo. Uma configuração de provedor ativa além do limite de exibição ainda bloqueia a exclusão, enquanto uma entrada inativa apenas avisa.
[Excluir um schema OpenAPI](/pt/reference/products/flowker/delete-openapi-schema) responde conforme o que ainda referencia o documento:
| Resultado | O que significa |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `204 No Content` | Nada referenciava o documento. Ele não existe mais. |
| `200 OK` | Apenas referências inativas o seguravam — um workflow em rascunho ou inativo, ou uma configuração de provedor desabilitada. O documento não existe mais, e o corpo mostra os avisos dele em `warnings` e `providerConfigurationWarnings`; os detalhes de exibição de configuração de provedor podem ser limitados a 100. |
| `409` com `FLK-0945` | Uma configuração de provedor ativa vincula o documento. Nada é excluído, e o corpo mostra as configurações de provedor e os workflows que o referenciam; os detalhes de exibição de configuração de provedor podem ser limitados a 100. |
| `409` com `FLK-0936` | Um workflow ativo referencia o documento a partir de um gatilho de webhook. Nada é excluído. |
Para liberar um bloqueio, desabilite a configuração de provedor ou desative o workflow ativo. Mova um workflow inativo para `draft` apenas se você precisa editar ele.
## O que dá errado
***
| Sintoma | Causa | Correção |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| O envio é recusado embora o arquivo abra no seu editor. | O documento declara uma versão `openapi` fora da série 3.x, ou não declara nenhuma operação. | Verifique o campo `openapi` e o objeto `paths`, depois envie de novo. |
| A chamada de criação informa que o id do schema é desconhecido. | O id pertence a outro tenant, ou o documento foi excluído. | Chame [Listar schemas OpenAPI](/pt/reference/products/flowker/list-openapi-schemas) e pegue o id na resposta. |
| O workflow é recusado com `FLK-0150`. | O `providerConfigId` do nó nomeia uma configuração que não existe, ou uma que está desabilitada. | Confirme o UUID no nó e habilite a configuração com [Habilitar uma configuração de provedor](/pt/reference/products/flowker/enable-provider-configuration). |
| O nó falha sem alcançar o seu serviço. | A operação está ausente do documento, ou nenhuma URL base resolve. | Compare `operation_path` e `operation_method` com a lista `operations` da Etapa 2, e defina `config.base_url` quando o documento não declara nenhuma entrada `servers`. |
| O serviço responde que um campo obrigatório está faltando. | Um `target` de mapeamento não corresponde ao schema de requisição da operação. | Leia `inputSchema` em [Derivar o schema de uma operação](/pt/reference/products/flowker/derive-openapi-operation-schema) e escreva cada target exatamente como ele aparece lá. |
| O serviço nunca é alcançado e a etapa informa uma URL rejeitada. | `allowedHosts` não cobre o host de destino. | Adicione o host a `allowedHosts` na configuração de provedor. |
| Código de erro | Quando | O que significa |
| -------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `FLK-0150` | Criar ou ativar o workflow | O `providerConfigId` do nó nomeia uma configuração que não existe, ou uma que não está ativa. |
| `FLK-0812` | Envio | Já existe um documento com este `name` e esta `version`. Escolha outra versão. |
| `FLK-0900` | Envio | O arquivo não faz parse como documento OpenAPI 3.x, ou não declara nenhuma operação. |
| `FLK-0901` | Envio | O arquivo passa de 8 MiB. |
| `FLK-0811` | Leitura, derivação, exclusão | O id do documento não resolve para o seu tenant. |
| `FLK-0902` | Derivar o schema de uma operação | O documento não declara nenhuma operação com esse caminho e método. |
| `FLK-0304` | Derivar o schema de uma operação | O parâmetro de query `path` está faltando, ou `method` está faltando ou não é um método HTTP. |
| `FLK-0946` | Criar ou atualizar a configuração de provedor | `config.openapi_schema_id` está faltando, ou não é um UUID. |
| `FLK-0947` | Criar ou atualizar a configuração de provedor, e tempo de execução | O documento referenciado não existe no seu tenant. |
| `FLK-0948` | Criar ou atualizar a configuração de provedor | O bloco `config.auth` está malformado. |
| `FLK-0293` | Criar ou atualizar a configuração de provedor | Uma entrada `schemaBindings` está malformada. |
| `FLK-0942` | Criar ou atualizar a configuração de provedor | Uma entrada `schemaBindings` nomeia um documento que não existe no seu tenant. |
| `FLK-0943` | Criar ou atualizar a configuração de provedor | Uma entrada `schemaBindings` restringe a uma operação que o documento não declara. |
| `FLK-0949` | Tempo de execução | Nem `config.base_url` nem uma entrada `servers` utilizável resolve uma URL base. O nó falha sem chamar o serviço. |
| `FLK-0950` | Tempo de execução | A operação vinculada está ausente do documento, ou um parâmetro `path` não encontrou valor. O nó falha sem chamar o serviço. |
| `FLK-0954` | Tempo de execução | Um parâmetro `header` ou `query` obrigatório não encontrou valor. O nó falha sem chamar o serviço. |
| `FLK-0955` | Criar ou atualizar a configuração de provedor | O bloco `config.headers` opcional está malformado. Ele deve mapear nomes de header válidos e não vazios para valores de string, sem duplicatas que ignorem maiúsculas e minúsculas. |
| `FLK-0945` | Excluir o documento | Uma configuração de provedor ativa vincula ele. |
| `FLK-0936` | Excluir o documento | Um workflow ativo referencia ele a partir de um gatilho de webhook. |
| `FLK-0803` | Enviar uma versão de spec | Esse par de serviço e versão já está publicado. As versões são imutáveis. |
| `FLK-0801` | Fixar uma versão de spec | A requisição está sem o serviço ou sem a versão. |
Veja a [lista de erros do Flowker](/pt/reference/products/flowker/flowker-error-list) para todos os códigos.
## O que vem depois
***
Mapeie valores para o corpo de requisição da operação e leia a resposta dela de volta.
Valide um payload de entrada contra uma operação do mesmo documento.
Defina a autenticação, as novas tentativas e o circuit breaker que toda configuração de provedor compartilha.
Conheça os endpoints do registro de schemas.