Conectando a sua própria API

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 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.
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.

Etapa 1: Envie o documento OpenAPI

Envie o arquivo

Chame Enviar um schema OpenAPI como multipart/form-data com três partes: o file, um name e uma version.

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"

Guarde o id

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

Liste o que você tem armazenado

Listar schemas OpenAPI 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.

Leia as operações de um documento

Obter um schema OpenAPI 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ó.

Leia os nomes de campo de uma operação

Derivar o schema de uma operação 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 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. 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 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.
`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.

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. 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 informa esta configuração, e uma exclusão do documento é recusada enquanto a configuração está ativa. Veja Removendo um documento. 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.

Exemplo de requisição

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 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 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 cobre mapeamentos e transformações por completo.

Exemplo: um workflow que chama duas operações do documento

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.

Etapa 5: Rode e confirme que funcionou

Ative o workflow

Chame Ativar um workflow. A ativação registra a rota de webhook e resolve o que o contrato do gatilho referencia.

Rode ele

Chame Executar um workflow com um header Idempotency-Key novo, ou envie uma requisição para a rota de webhook.

Leia os resultados das etapas

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. 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 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	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	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	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 descreve a versão que você escolheu.

Removendo um documento

Verifique o que quebraria

Listar recursos que referenciam um schema OpenAPI 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.

Exclua ele

Excluir um schema OpenAPI 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 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.
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 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 para todos os códigos.

O que vem depois

Trabalhando com dados de requisição e resposta

Mapeie valores para o corpo de requisição da operação e leia a resposta dela de volta.

Configurando um gatilho de webhook

Valide um payload de entrada contra uma operação do mesmo documento.

Guia de integração

Defina a autenticação, as novas tentativas e o circuit breaker que toda configuração de provedor compartilha.

API de schemas OpenAPI

Conheça os endpoints do registro de schemas.

Visão geral

Guias

Console

Operações

Conectando a sua própria API

Antes de começar

Etapa 1: Envie o documento OpenAPI

Pelo que um documento armazenado é indexado

Etapa 2: Leia as operações que você pode chamar

Etapa 3: Aponte uma configuração de provedor para o documento

Onde a credencial fica

Onde as listas de hosts permitidos são definidas

Vincule o documento

Etapa 4: Enderece uma operação a partir de um nó de workflow

Como a requisição é montada

Etapa 5: Rode e confirme que funcionou

Publicando uma nova versão do seu documento

Versões de spec para os serviços do catálogo

Removendo um documento

O que dá errado

O que vem depois

Trabalhando com dados de requisição e resposta

Configurando um gatilho de webhook

Guia de integração

API de schemas OpenAPI

​Antes de começar

​Etapa 1: Envie o documento OpenAPI

​Pelo que um documento armazenado é indexado

​Etapa 2: Leia as operações que você pode chamar

​Etapa 3: Aponte uma configuração de provedor para o documento

​Onde a credencial fica

​Onde as listas de hosts permitidos são definidas

​Vincule o documento

​Etapa 4: Enderece uma operação a partir de um nó de workflow

​Como a requisição é montada

​Etapa 5: Rode e confirme que funcionou

​Publicando uma nova versão do seu documento

​Versões de spec para os serviços do catálogo

​Removendo um documento

​O que dá errado

​O que vem depois

Trabalhando com dados de requisição e resposta

Configurando um gatilho de webhook

Guia de integração

API de schemas OpenAPI

Antes de começar

Etapa 1: Envie o documento OpenAPI

Pelo que um documento armazenado é indexado

Etapa 2: Leia as operações que você pode chamar

Etapa 3: Aponte uma configuração de provedor para o documento

Onde a credencial fica

Onde as listas de hosts permitidos são definidas

Vincule o documento

Etapa 4: Enderece uma operação a partir de um nó de workflow

Como a requisição é montada

Etapa 5: Rode e confirme que funcionou

Publicando uma nova versão do seu documento

Versões de spec para os serviços do catálogo

Removendo um documento

O que dá errado

O que vem depois