Conectar tu propia API

Flowker incluye conectores para los servicios de su catálogo. El servicio al que quieres llamar también puede ser el tuyo: una API interna, una API de un socio, cualquier cosa con un documento OpenAPI publicado. Subes ese documento, y un nodo de workflow llama a sus operaciones directamente. Haces esto una vez por documento. Súbelo, crea una configuración de proveedor que apunte a él, y luego apunta a una operación desde cada nodo que llama al servicio.

Antes de empezar

El documento OpenAPI 3.x de tu servicio como archivo, de como máximo 8 MiB, que declare al menos una operación.
Las credenciales que exige tu servicio, y el método de autenticación que espera. Consulta Autenticación para ver los métodos que admite Flowker.
Un despliegue cuyo registro de esquemas tenga almacenamiento de blobs configurado. SCHEMA_REGISTRY_S3_BUCKET guarda los documentos OpenAPI que subes. Consulta Variables de entorno de Flowker.
Un workflow en estado draft para editar. Un workflow activo está bloqueado. Desactívalo primero, y luego mueve el workflow inactivo a draft antes de editarlo y activarlo de nuevo.

La Lerian Console cubre el mismo recorrido. En Providers → + New Provider → Add your own API, seleccionas un documento subido y defines la URL base y la autenticación. Consulta Agregar un proveedor.

Paso 1: Sube el documento OpenAPI

Envía el archivo

Llama a Subir un esquema OpenAPI como multipart/form-data con tres partes: el file, un name y una 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"

Guarda el id

La respuesta 201 describe lo que Flowker leyó del archivo. Su id es el valor que referencian todos los pasos posteriores.

Campo	Qué te dice
`id`	El identificador del documento. Una configuración de proveedor y un disparador de webhook apuntan a él.
`name`, `version`	El par que enviaste.
`title`	El `info.title` del documento.
`openapiVersion`	La versión `openapi` que declara el documento.
`operationCount`	Cuántas operaciones de path y método declara el documento.
`contentHash`, `byteSize`	El digest y el tamaño del archivo almacenado.
`createdBy`, `createdAt`	Quién lo subió y cuándo.

Con qué se identifica un documento almacenado

name y version los eliges tú, de hasta 255 caracteres cada uno. El par es único en tu tenant: subir de nuevo el mismo name y la misma version responde FLK-0812. El id que devuelve Flowker es un UUID nuevo en cada subida. Todo lo demás referencia ese id, nunca el nombre ni la versión. Flowker analiza el archivo antes de almacenarlo. Un archivo que no es un documento OpenAPI 3.x, o uno que no declara ninguna operación, responde FLK-0900. Un archivo de más de 8 MiB responde FLK-0901. Los documentos que subes son solo tuyos. Un documento es visible solo para el tenant que lo subió, y un id de otro tenant nunca se resuelve.

Paso 2: Lee las operaciones a las que puedes llamar

Lista lo que tienes almacenado

Listar esquemas OpenAPI devuelve tus documentos solo como metadatos, sin su contenido. Está paginado: limit, cursor, sortBy y sortOrder, y la respuesta lleva nextCursor y hasMore.

Lee las operaciones de un documento

Obtener un esquema OpenAPI devuelve los mismos metadatos más content (el archivo almacenado) y operations, una entrada por cada operación que declara el documento.

Campo	Qué te dice
`path`	El path de la operación, exactamente como lo escribe el documento, como `/v1/checks`.
`method`	El método HTTP de la operación.
`operationId`	El `operationId` del documento, cuando declara uno.
`hasRequest`	Si la operación declara un cuerpo de solicitud JSON.
`hasResponse`	Si la operación declara una respuesta JSON de éxito.

Copia el path y el method de la operación que quieres. El Paso 4 los pone en el nodo.

Lee los nombres de campo de una operación

Derivar el esquema de una operación toma un path y un method y devuelve inputSchema para el cuerpo de solicitud application/json de la operación y outputSchema para su primera respuesta application/json 2xx. Cualquiera de los dos campos falta cuando el documento no declara ese esquema. Para un cuerpo de solicitud que no es JSON, usa hasBody, bodyRequired y bodyContentType. También devuelve params, una entrada por cada parámetro que declara la operación, cada una con su name, su ubicación in y si es required.Esos son los nombres de campo que escribes como destinos y orígenes de mapeo en el Paso 4. Ambos parámetros de query string son obligatorios, y method no distingue mayúsculas de minúsculas y debe ser uno de GET, PUT, POST, DELETE, OPTIONS, HEAD, PATCH o TRACE. Un path faltante o un method no reconocido responde FLK-0304. Un path y un método que el documento no declara responden FLK-0902.

Paso 3: Apunta una configuración de proveedor al documento

Llama a Crear una configuración de proveedor con kind definido como external_openapi. Ese kind referencia el documento que subiste en lugar de un proveedor del catálogo.

Campo	Obligatorio	Descripción
`kind`	Sí	`"external_openapi"`. Eliges el kind cuando creas la configuración, y sigue siendo el kind con el que se creó la configuración.
`providerId`	No	Omítelo — esta conexión apunta a tu propio documento, no a un proveedor del catálogo. Una lectura de la configuración devuelve entonces el id reservado `external.openapi`.
`name`	Sí	Un nombre para esta conexión, de 1–100 caracteres.
`config.openapi_schema_id`	Sí	El `id` del Paso 1. Debe nombrar un documento de tu tenant.
`config.base_url`	No	El esquema, el host y el prefijo de path a los que Flowker envía las solicitudes. Omítelo para usar la primera entrada `servers` utilizable del documento.
`config.auth`	No	Un bloque de autenticación `{ type, config }`, con la misma forma que usa cada configuración de proveedor. Consulta Autenticación para ver cada tipo y sus campos. Omítelo para un servicio que no necesita autenticación.
`config.headers`	No	Headers HTTP estáticos para todas las solicitudes a través de esta conexión. Debe ser un objeto de nombres de header válidos y no vacíos con valores de cadena; los nombres no deben chocar sin distinguir mayúsculas de minúsculas. Los valores pueden usar referencias de plantilla que se resuelven en el momento de la solicitud.
`allowedHosts`	No	Los hosts a los que esta configuración puede llamar. Omítelo, o envía una lista vacía, para aceptar cualquier host público.
`allowedPrivateHosts`	No	Hosts privados nombrados a los que esta configuración puede llegar. Las direcciones de metadatos de nube y link-local siguen bloqueadas.
`schemaBindings`	No	Los documentos almacenados a los que se vincula esta configuración. Consulta Vincula el documento.
`description`	No	Texto libre, de hasta 500 caracteres.
`metadata`	No	Tus propios pares de clave y valor.

config.headers se almacena con la configuración de proveedor y las lecturas de configuración pueden devolverlo. Nunca pongas ahí claves de API, tokens, cookies u otros secretos. Pon las credenciales en config.auth, cuyos valores secretos son de solo escritura y se respaldan en el backend de secretos configurado.

Dónde va la credencial

El secreto dentro de config.auth es de solo escritura en la creación y en la actualización. Flowker lo envía a tu backend de secretos y lo quita del documento de configuración antes de guardar el documento. Flowker resuelve el secreto desde el backend en el momento de la ejecución. Para una configuración external_openapi, la lectura por id no resuelve ni devuelve los valores secretos de config.auth. Mantén las credenciales en config.auth. Una lectura puede devolver otros valores de configuración. Para rotar un secreto más adelante, envía el valor nuevo en una actualización. Para conservar el actual, omite el campo o envíalo vacío mientras auth.type siga siendo el mismo. Consulta Autenticación.

Dónde se definen las listas de hosts permitidos

Ambas listas de permitidos pertenecen a esta llamada de creación, y después a Actualizar una configuración de proveedor. La lista allowedHosts nombra los hosts a los que puede llegar cada nodo que llama a través de esta configuración. Flowker compara con ella la URL de la solicitud y cada salto de redirección en tiempo de ejecución. Una entrada con un punto inicial coincide con subdominios, así que .acme-kyc.example.com coincide con api.acme-kyc.example.com. Las entradas son solo nombres de host, sin literal de IP, sin comodín y sin puerto. allowedPrivateHosts es la lista complementaria para un servicio que vive en una red privada. No anula a allowedHosts: cuando allowedHosts no está vacía, también debe incluir el host privado. Una entrada allowedPrivateHosts que coincide solo levanta el bloqueo de IP privada o de loopback. Las direcciones de metadatos de nube y link-local siguen bloqueadas.

Vincula el documento

Agrega una entrada schemaBindings para el documento que referenciaste. Cada entrada nombra un documento almacenado. Define type como "openapi" y schemaId como el mismo id que pusiste en config.openapi_schema_id. El array operations opcional acota el vínculo almacenado. Flowker valida ese array contra el documento cuando guardas la configuración. Ese array no verifica a qué llaman los nodos del workflow, y no limita un nodo external_openapi en el momento de la ejecución. El nodo usa config.openapi_schema_id, operation_path y operation_method. El vínculo es lo que hace visibles a los dependientes del documento. Con él, Listar recursos que referencian un esquema OpenAPI informa esta configuración, y una eliminación del documento se rechaza mientras la configuración esté activa. Consulta Eliminar un documento. Flowker resuelve cada vínculo cuando guardas. Un schemaId que no nombra ningún documento de tu tenant responde FLK-0942, y una entrada operations que el documento no declara responde FLK-0943, y cada uno nombra la entrada que falla. Una entrada malformada responde FLK-0293. Malformada significa un type desconocido, un schemaId que no es un UUID, operations en un vínculo que no es openapi, o una operación sin path ni método.

Solicitud de ejemplo

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" }
      ]
    }
  ]
}

La respuesta devuelve el id de la configuración nueva. Guárdalo. El Paso 4 lo pone en el providerConfigId de cada nodo que llama a este servicio.

Flowker verifica la configuración antes de almacenarla. Un config sin openapi_schema_id, o uno cuyo valor no es un UUID, responde FLK-0946. Un id que no nombra ningún documento de tu tenant responde FLK-0947. Un bloque config.auth que Flowker no puede leer (un tipo desconocido, o un tipo al que le falta uno de sus campos obligatorios) responde FLK-0948. Un bloque config.headers malformado responde FLK-0955. Flowker no llama aquí a tu API de destino. Sí lee el documento referenciado y, cuando config.auth contiene un secreto, escribe ese secreto en el backend de secretos configurado antes de persistir la configuración.

Paso 4: Apunta a una operación desde un nodo de workflow

Un nodo ejecutor nombra una operación del documento con dos campos en su data, junto al providerConfigId de la configuración del Paso 3.

Campo	Obligatorio	Descripción
`providerConfigId`	Sí	El UUID de la configuración de proveedor que apunta al documento.
`operation_path`	Para ejecutar	El path de la operación, exactamente como lo escribe el documento, incluidas sus plantillas de parámetros `{...}`.
`operation_method`	Para ejecutar	El método HTTP de la operación. La coincidencia no distingue mayúsculas de minúsculas.
`inputMapping`	No	Mueve valores del contexto del workflow hacia la solicitud. Cada `target` es un path del cuerpo de solicitud de la operación, o el nombre de un parámetro.
`outputMapping`	No	Saca valores de la respuesta para que los lean nodos posteriores.

No envíes executorId en un nodo así. Flowker resuelve la configuración de proveedor, reconoce el kind y completa el campo por ti antes de validar el workflow. El guardado puede persistir un nodo al que le falte cualquiera de los dos campos de operación, pero la ejecución falla entonces con FLK-0950 antes de que Flowker envíe una solicitud. Todos los demás campos del nodo se comportan como describe Referenciar la configuración de proveedor desde un nodo de workflow.

Cómo se arma la solicitud

Flowker lee la operación del documento almacenado en tiempo de ejecución y arma la solicitud a partir de ella:

El destino es config.base_url cuando la configuración lo define, y si no, la primera entrada servers utilizable del documento, unida con operation_path.
Un parámetro path toma su valor primero de los datos resueltos del nodo, y en segundo lugar del cuerpo de solicitud. Cada parámetro path necesita un valor.
Un parámetro query o header se resuelve de la misma forma. Un parámetro opcional sin valor se deja fuera. Un parámetro obligatorio sin valor hace fallar el nodo antes de que salga ninguna solicitud de Flowker, con FLK-0954. Un valor estático de config.headers o la autenticación configurada pueden satisfacer un parámetro de header obligatorio.
El cuerpo de solicitud con el request_format predeterminado (json) es lo que arma tu inputMapping. Con xml_converted, Flowker serializa ese objeto mapeado como XML. Con xml_passthrough, Flowker ignora el mapeo y reenvía los bytes XML originales del disparador de webhook. Escribe cada target exactamente como lo nombra el esquema de solicitud de la operación. No hay objeto envoltorio ni prefijo que agregar. Trabajar con datos de solicitud y respuesta cubre los mapeos y las transformaciones por completo.

Ejemplo: un workflow que llama a dos operaciones del 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" }
  ]
}

El nodo open-check envía POST https://api.acme-kyc.example.com/v1/checks con el cuerpo que armó su inputMapping. Su outputMapping extrae dos campos de la respuesta, así que el nodo siguiente lee ${open-check.checkId}.Un nodo que en cambio llama a GET /v1/checks/{checkId} lee el parámetro del mismo ámbito de nodo. Mapea un valor sobre checkId, y Flowker lo sustituye en el path.

Un disparador de webhook puede validar el payload entrante contra una operación del mismo documento. Define input_contract como "openapi" y dale al disparador openapi_schema_id, operation_path y operation_method. Consulta Configurar un disparador de webhook.

Paso 5: Ejecútalo y confirma que funcionó

Activa el workflow

Llama a Activar un workflow. La activación registra la ruta del webhook y resuelve lo que referencia el contrato del disparador.

Ejecútalo

Llama a Ejecutar un workflow con un header Idempotency-Key nuevo, o envía una solicitud a la ruta del webhook.

Lee los resultados por paso

Un nodo que alcanzó tu servicio registra la respuesta bajo su propio id. Con un outputMapping, los nombres mapeados quedan directamente bajo ese id: open-check.checkId. Sin outputMapping, la salida del nodo conserva el envelope de la respuesta, así que el cuerpo de la respuesta queda un nivel más abajo, bajo body.

Publicar una versión nueva de tu documento

Un documento almacenado no cambia. Para entregar una revisión, sube el archivo de nuevo con una version nueva. Eso te da un segundo documento almacenado con su propio id. Subir un documento nuevo no cambia las configuraciones existentes. Sin embargo, cada nodo ejecutor lee su configuración de proveedor cuando corre. Actualizar config.openapi_schema_id puede cambiar el documento que usan los nodos posteriores de una ejecución en curso, así que coordina el cambio. Envía el config de la configuración de proveedor con el id nuevo mediante Actualizar una configuración de proveedor. El campo config reemplaza el mapa almacenado en lugar de fusionarse con él. Incluye en la misma llamada los valores base_url y auth configurados que necesites conservar. Flowker revalida el id nuevo contra tu tenant, y responde FLK-0947 cuando no se resuelve. Revisa Listar recursos que referencian un esquema OpenAPI sobre el documento anterior antes de retirarlo. La respuesta es una lista para mostrar, no un inventario completo: devuelve hasta 100 entradas en cada uno de sus dos grupos. Una configuración de proveedor activa más allá de ese límite de visualización igual bloquea la eliminación.

Versiones de spec para los servicios del catálogo

Los servicios del propio catálogo de Flowker se resuelven contra un registro compartido y separado de specs publicadas. Tres operaciones lo gestionan. Nunca tocan un documento que subiste en el Paso 1.

Operación	Qué hace
Listar versiones de spec OpenAPI	Lista en `versions` las versiones publicadas de la spec de un servicio, e informa en `pinnedVersion` la que tu tenant ha fijado. `pinnedVersion` está vacío cuando tu tenant no ha fijado ninguna.
Fijar una versión de spec OpenAPI	Selecciona la versión contra la que tu tenant se resuelve para ese servicio. Es idempotente: fijar de nuevo reemplaza la versión en el lugar. Una solicitud a la que le falta el servicio o la versión responde `FLK-0801`.
Subir una versión de spec OpenAPI	Publica una versión de la spec de un servicio, para todos los tenants. Las versiones son inmutables: un par de `service` y `version` que ya existe responde `FLK-0803`. Quien llama necesita el permiso `create` sobre el recurso `catalog`.

La fijación es por tenant. Publicar una versión no cambia nada para un tenant hasta que ese tenant la fija. Por eso una subida nueva nunca mueve un workflow en ejecución a una spec distinta. Flowker lee tu versión fijada cuando informa los esquemas de ejecutor de ese servicio en el catálogo, así que Obtener un ejecutor del catálogo describe la versión que elegiste.

Eliminar un documento

Revisa qué se rompería

Listar recursos que referencian un esquema OpenAPI devuelve dos grupos, providerConfigurations y workflows. Los dos están siempre presentes, cada uno lleva hasta 100 entradas, y cada entrada lleva un id, un name y un status. Es una lista para mostrar, no un inventario completo. Una configuración de proveedor activa más allá del límite de visualización igual bloquea la eliminación, mientras que una entrada inactiva solo advierte.

Elimínalo

Eliminar un esquema OpenAPI responde según lo que todavía referencia el documento:

Resultado	Qué significa
`204 No Content`	Nada referenciaba el documento. Ya no está.
`200 OK`	Solo lo retenían referencias inactivas — un workflow en draft o inactivo, o una configuración de proveedor deshabilitada. El documento ya no está, y el cuerpo muestra sus advertencias en `warnings` y `providerConfigurationWarnings`; los detalles de visualización de configuraciones de proveedor pueden estar limitados a 100.
`409` con `FLK-0945`	Una configuración de proveedor activa vincula el documento. No se elimina nada, y el cuerpo muestra las configuraciones de proveedor y los workflows que lo referencian; los detalles de visualización de configuraciones de proveedor pueden estar limitados a 100.
`409` con `FLK-0936`	Un workflow activo referencia el documento desde un disparador de webhook. No se elimina nada.

Para quitar un bloqueo, deshabilita la configuración de proveedor o desactiva el workflow activo. Mueve un workflow inactivo a draft solo si necesitas editarlo.

Qué sale mal

Síntoma	Causa	Arreglo
La subida se rechaza aunque el archivo abre en tu editor.	El documento declara una versión `openapi` fuera de la serie 3.x, o no declara ninguna operación.	Revisa el campo `openapi` y el objeto `paths`, y sube de nuevo.
La llamada de creación informa que el id del esquema es desconocido.	El id pertenece a otro tenant, o el documento se eliminó.	Llama a Listar esquemas OpenAPI y toma el id de la respuesta.
El workflow se rechaza con `FLK-0150`.	El `providerConfigId` del nodo nombra una configuración que no existe, o una que está deshabilitada.	Confirma el UUID en el nodo, y habilita la configuración con Habilitar una configuración de proveedor.
El nodo falla sin alcanzar tu servicio.	La operación no está en el documento, o no se resuelve ninguna URL base.	Compara `operation_path` y `operation_method` con la lista `operations` del Paso 2, y define `config.base_url` cuando el documento no declara ninguna entrada `servers`.
El servicio responde que falta un campo obligatorio.	Un `target` de mapeo no coincide con el esquema de solicitud de la operación.	Lee `inputSchema` en Derivar el esquema de una operación y escribe cada target exactamente como aparece ahí.
Nunca se alcanza el servicio y el paso informa una URL rechazada.	`allowedHosts` no cubre el host de destino.	Agrega el host a `allowedHosts` en la configuración de proveedor.

Código de error	Cuándo	Qué significa
`FLK-0150`	Crear o activar el workflow	El `providerConfigId` del nodo nombra una configuración que no existe, o una que no está activa.
`FLK-0812`	Subir	Ya existe un documento con este `name` y esta `version`. Elige otra versión.
`FLK-0900`	Subir	El archivo no se analiza como documento OpenAPI 3.x, o no declara ninguna operación.
`FLK-0901`	Subir	El archivo supera 8 MiB.
`FLK-0811`	Leer, derivar, eliminar	El id del documento no se resuelve para tu tenant.
`FLK-0902`	Derivar el esquema de una operación	El documento no declara ninguna operación con ese path y ese método.
`FLK-0304`	Derivar el esquema de una operación	Falta el parámetro `path` de query string, o falta `method` o no es un método HTTP.
`FLK-0946`	Crear o actualizar la configuración de proveedor	Falta `config.openapi_schema_id`, o no es un UUID.
`FLK-0947`	Crear o actualizar la configuración de proveedor, y tiempo de ejecución	El documento referenciado no existe en tu tenant.
`FLK-0948`	Crear o actualizar la configuración de proveedor	El bloque `config.auth` está malformado.
`FLK-0293`	Crear o actualizar la configuración de proveedor	Una entrada `schemaBindings` está malformada.
`FLK-0942`	Crear o actualizar la configuración de proveedor	Una entrada `schemaBindings` nombra un documento que no existe en tu tenant.
`FLK-0943`	Crear o actualizar la configuración de proveedor	Una entrada `schemaBindings` restringe a una operación que el documento no declara.
`FLK-0949`	Tiempo de ejecución	Ni `config.base_url` ni una entrada `servers` utilizable resuelven una URL base. El nodo falla sin llamar al servicio.
`FLK-0950`	Tiempo de ejecución	La operación vinculada no está en el documento, o un parámetro `path` no encontró valor. El nodo falla sin llamar al servicio.
`FLK-0954`	Tiempo de ejecución	Un parámetro `header` o `query` obligatorio no encontró valor. El nodo falla sin llamar al servicio.
`FLK-0955`	Crear o actualizar la configuración de proveedor	El bloque `config.headers` opcional está malformado. Debe mapear nombres de header válidos y no vacíos a valores de cadena, sin duplicados que solo difieran en mayúsculas.
`FLK-0945`	Eliminar el documento	Una configuración de proveedor activa lo vincula.
`FLK-0936`	Eliminar el documento	Un workflow activo lo referencia desde un disparador de webhook.
`FLK-0803`	Subir una versión de spec	Ese par de servicio y versión ya está publicado. Las versiones son inmutables.
`FLK-0801`	Fijar una versión de spec	A la solicitud le falta el servicio o la versión.

Consulta la lista de errores de Flowker para ver todos los códigos.

Qué sigue

Trabajar con datos de solicitud y respuesta

Mapea valores hacia el cuerpo de solicitud de la operación y lee de vuelta su respuesta.

Configurar un disparador de webhook

Valida un payload entrante contra una operación del mismo documento.

Guía de integración

Define la autenticación, los reintentos y el circuit breaker que comparte cada configuración de proveedor.

API de esquemas OpenAPI

Explora los endpoints del registro de esquemas.

Resumen

Guías

Console

Operaciones

Conectar tu propia API

Antes de empezar

Paso 1: Sube el documento OpenAPI

Con qué se identifica un documento almacenado

Paso 2: Lee las operaciones a las que puedes llamar

Paso 3: Apunta una configuración de proveedor al documento

Dónde va la credencial

Dónde se definen las listas de hosts permitidos

Vincula el documento

Paso 4: Apunta a una operación desde un nodo de workflow

Cómo se arma la solicitud

Paso 5: Ejecútalo y confirma que funcionó

Publicar una versión nueva de tu documento

Versiones de spec para los servicios del catálogo

Eliminar un documento

Qué sale mal

Qué sigue

Trabajar con datos de solicitud y respuesta

Configurar un disparador de webhook

Guía de integración

API de esquemas OpenAPI

​Antes de empezar

​Paso 1: Sube el documento OpenAPI

​Con qué se identifica un documento almacenado

​Paso 2: Lee las operaciones a las que puedes llamar

​Paso 3: Apunta una configuración de proveedor al documento

​Dónde va la credencial

​Dónde se definen las listas de hosts permitidos

​Vincula el documento

​Paso 4: Apunta a una operación desde un nodo de workflow

​Cómo se arma la solicitud

​Paso 5: Ejecútalo y confirma que funcionó

​Publicar una versión nueva de tu documento

​Versiones de spec para los servicios del catálogo

​Eliminar un documento

​Qué sale mal

​Qué sigue

Trabajar con datos de solicitud y respuesta

Configurar un disparador de webhook

Guía de integración

API de esquemas OpenAPI

Antes de empezar

Paso 1: Sube el documento OpenAPI

Con qué se identifica un documento almacenado

Paso 2: Lee las operaciones a las que puedes llamar

Paso 3: Apunta una configuración de proveedor al documento

Dónde va la credencial

Dónde se definen las listas de hosts permitidos

Vincula el documento

Paso 4: Apunta a una operación desde un nodo de workflow

Cómo se arma la solicitud

Paso 5: Ejecútalo y confirma que funcionó

Publicar una versión nueva de tu documento

Versiones de spec para los servicios del catálogo

Eliminar un documento

Qué sale mal

Qué sigue