> ## 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.
# Conectar tu propia API
> Sube a Flowker el documento OpenAPI de tu servicio y llama a sus operaciones desde un nodo de workflow. Registra el documento, haz que una configuración de proveedor apunte a él y apunta a una operación por nodo.
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](/es/products/flowker/integration-guide#authentication) 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](/es/products/flowker/flowker-environment-variables).
* 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](/es/products/flowker/console/adding-a-provider).
Paso 1: Sube el documento OpenAPI
***
Llama a [Subir un esquema OpenAPI](/es/reference/products/flowker/upload-openapi-schema) como `multipart/form-data` con tres partes: el `file`, un `name` y una `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"
```
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
***
[Listar esquemas OpenAPI](/es/reference/products/flowker/list-openapi-schemas) devuelve tus documentos solo como metadatos, sin su contenido. Está paginado: `limit`, `cursor`, `sortBy` y `sortOrder`, y la respuesta lleva `nextCursor` y `hasMore`.
[Obtener un esquema OpenAPI](/es/reference/products/flowker/get-openapi-schema) 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.
[Derivar el esquema de una operación](/es/reference/products/flowker/derive-openapi-operation-schema) 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](/es/reference/products/flowker/create-provider-configuration) 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](#step-1-upload-the-openapi-document). 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](/es/products/flowker/integration-guide#authentication) 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](#bind-the-document). |
| `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](/es/products/flowker/integration-guide#authentication).
### 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](/es/reference/products/flowker/update-provider-configuration). 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](/es/reference/products/flowker/list-openapi-schema-references) informa esta configuración, y una eliminación del documento se rechaza mientras la configuración esté activa. Consulta [Eliminar un documento](#removing-a-document).
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.
```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" }
]
}
]
}
```
La respuesta devuelve el `id` de la configuración nueva. Guárdalo. El [Paso 4](#step-4-address-an-operation-from-a-workflow-node) 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](/es/products/flowker/integration-guide#step-3-reference-the-provider-configuration-from-a-workflow-node).
### 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](/es/products/flowker/working-with-request-and-response-data) cubre los mapeos y las transformaciones 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" }
]
}
```
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](/es/products/flowker/configuring-a-webhook-trigger).
## Paso 5: Ejecútalo y confirma que funcionó
***
Llama a [Activar un workflow](/es/reference/products/flowker/activate-workflow). La activación registra la ruta del webhook y resuelve lo que referencia el contrato del disparador.
Llama a [Ejecutar un workflow](/es/reference/products/flowker/execute-workflow) con un header `Idempotency-Key` nuevo, o envía una solicitud a la ruta del webhook.
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](/es/reference/products/flowker/update-provider-configuration). 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](/es/reference/products/flowker/list-openapi-schema-references) 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](/es/reference/products/flowker/list-openapi-spec-versions) | 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](/es/reference/products/flowker/pin-openapi-spec-version) | 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](/es/reference/products/flowker/upload-openapi-spec-version) | 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](/es/reference/products/flowker/get-catalog-executor) describe la versión que elegiste.
Eliminar un documento
***
[Listar recursos que referencian un esquema OpenAPI](/es/reference/products/flowker/list-openapi-schema-references) 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.
[Eliminar un esquema OpenAPI](/es/reference/products/flowker/delete-openapi-schema) 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](/es/reference/products/flowker/list-openapi-schemas) 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](/es/reference/products/flowker/enable-provider-configuration). |
| 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](/es/reference/products/flowker/derive-openapi-operation-schema) 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](/es/reference/products/flowker/flowker-error-list) para ver todos los códigos.
## Qué sigue
***
Mapea valores hacia el cuerpo de solicitud de la operación y lee de vuelta su respuesta.
Valida un payload entrante contra una operación del mismo documento.
Define la autenticación, los reintentos y el circuit breaker que comparte cada configuración de proveedor.
Explora los endpoints del registro de esquemas.