Celigo

Delete an on-premise agent -- Deletes an on-premise agent. Soft-deleted and retained in the recycle bin for 30 days. Does not uninstall the agent software on the host. Connections using this agent's `_agentId` will block deletion with 422 — check dependencies first. via DELETE /v1/agents/{_id}

Delete an API -- Deletes an API. Soft-deleted and retained in the recycle bin for 30 days. The public endpoint stops responding immediately. The delete succeeds even with dependents, but those resources will break -- check `GET /v1/apis/{_id}/dependencies` first. via DELETE /v1/apis/{_id}

Delete API request logs in a date range -- Queues asynchronous deletion of stored request log payloads for the API within `[startedAt, endAt]`. Returns `202 Accepted`; cleanup runs in the background. Requires manage access for log deletion — monitor-level users receive `403`. via DELETE /v1/apis/{_id}/requests

Delete a user -- Remove a user from the current account. This is irreversible — for a reversible alternative, use `PUT /v1/ashares/{_id}/disable`. Works on both accepted and pending invites. via DELETE /v1/ashares/{_id}

Delete an async helper -- Deletes an async helper. The resource is soft-deleted and retained in the recycle bin for 30 days before permanent removal. If other resources reference this async helper (e.g. exports, flows), the delete is blocked — use `GET /v1/asynchelpers/{_id}/dependencies` to discover dependents first. via DELETE /v1/asynchelpers/{_id}

Delete all state keys for a resource -- Deletes **all** state keys and values stored under the specified resource. This is destructive and cannot be undone. Prefer `DELETE /v1/{resourceType}/{_resourceId}/state/{key}` to remove individual keys. via DELETE /v1/{resourceType}/{_resourceId}/state

Delete a resource-scoped state key -- Deletes a specific state key and its value from the resource. Returns `404` if the key does not exist. via DELETE /v1/{resourceType}/{_resourceId}/state/{key}

Delete a connection -- Deletes a connection. The connection is soft-deleted and retained in the recycle bin for 30 days before permanent removal. Use `POST /v1/recycleBinTTL/connections/{_id}` to restore it during that window. via DELETE /v1/connections/{_id}

Clear the debug log buffer for a connection -- Purges the connection's debug log buffer. Subsequent `GET /v1/connections/{_id}/debug` calls return empty until new traffic is captured (assuming `debugDate` is still in the future). Idempotent — works whether the buffer held entries, was already empty, or the given connection id does not exist. Does **not** clear the connection's `debugDate` — debug capture remains enabled until `debugDate` expires or is removed via a PUT. Useful between test runs to isolate logs for a single scenario. To fully disable debug capture, also `PUT /v1/connections/{_id}` with `debugDate` removed from the body. via DELETE /v1/connections/{_id}/debug

Delete a connector -- Deletes a connector. This does not affect existing installations. **Partner-only endpoint.** via DELETE /v1/connectors/{_id}

Delete a license -- Deletes a license for a connector. **Partner-only endpoint.** via DELETE /v1/connectors/{_id}/licenses/{_licenseId}

Delete an EDI profile -- Deletes an EDI profile. Soft-deleted and retained for 30 days. via DELETE /v1/ediprofiles/{_id}

Revoke an end user -- Soft-deletes the end-user access record and clears its group memberships. Any workspace access record the same person holds is unaffected. Requires account owner or administrator access. via DELETE /v1/endusers/{_ashareId}

Delete an export -- Deletes an export. The export is soft-deleted and retained in the recycle bin for 30 days before permanent removal. If the export is currently in use by any flows, those flows may fail until reconfigured. via DELETE /v1/exports/{_id}

Delete a file definition -- Soft-deletes a file definition. Retained in the recycle bin for 30 days. via DELETE /v1/filedefinitions/{_id}

Delete a flow -- Deletes a flow. Soft-deleted and retained in the recycle bin for 30 days. Scheduled executions are stopped and any running jobs are cancelled. Check `GET /v1/flows/{_id}/dependencies` first — if other resources reference this flow, the delete is blocked. Soft-deleted flows can be restored via the recycle bin endpoints within 30 days. via DELETE /v1/flows/{_id}

Delete stored HTTP request/response traces by key -- Permanently removes specific stored request+response pairs from the per-step trace cache. Despite the un-parameterized path, this is **not** a blanket purge — the request body must name the exact `reqAndResKey` values to delete (from the errors listing). After deletion, subsequent calls to `GET .../requests/{reqAndResKey}` for the deleted keys fail with `file_not_found`. The live API **requires `Content-Type: application/json`** plus a non-empty `keys[]` array. A request with no body, `{}`, or `{keys: []}` rejects with 400 `invalid_url` / `"keys is not valid."`. The underlying error record in `GET .../errors` remains after deletion, but its `reqAndResKey` pointer will dangle. There is no single "purge all" call — enumerate current errors and collect all `reqAndResKey` values to clear the full cache. via DELETE /v1/flows/{_id}/{_stepId}/requests

Permanently delete resolved errors -- Permanently removes resolved error records from the account. Use when the retention window hasn't expired yet but you want to clear out the resolved list (e.g. after a one-time cleanup pass). Only resolved errors can be deleted through this endpoint — open errors must be resolved first. This is destructive: the records and their associated HTTP request/response captures are permanently removed. The request body field is named `errors` (carrying error ids). To clear the whole resolved list without listing ids, send `selectAll: true` with a `lastErrorAt` high-water mark instead of `errors` — note that here `lastErrorAt` bounds each record's `resolvedAt`, not `occurredAt`. via DELETE /v1/flows/{_id}/{_stepId}/resolved

Delete execution logs for a flow within a time range -- Asynchronously deletes execution-log entries for the flow that fall within the specified time range. Returns `202 Accepted` with an empty body — the deletion runs in the background. Both `startedAt` and `endAt` are required query parameters and must be valid ISO 8601 datetime strings. `startedAt` must be strictly before `endAt`; the server returns `400 invalid_query_params` otherwise. This is a destructive, irreversible operation. The 202 response does not include a job id; there is no way to poll for completion. via DELETE /v1/flows/{_id}/logs

Delete a group -- Soft-deletes the group and removes the corresponding membership entry from every end user in the account. Requires account owner or administrator access. via DELETE /v1/groups/{_id}

Delete an HTTP connector -- Permanently deletes an HTTP Connector and all its child resources and endpoints. via DELETE /v1/httpconnectors/{_id}

Delete an iClient -- Permanently deletes an iClient. Blocked if the iClient is still referenced by a connection. via DELETE /v1/iclients/{_id}

Delete an import -- Deletes an import. The import is soft-deleted and retained in the recycle bin for 30 days before permanent removal. If the import is currently in use by any flows, those flows may fail until reconfigured. Celigo documents this same endpoint on 3 resource pages: imports (deleteImport) plus ai-agents (deleteAiAgent), guardrails (deleteGuardrail). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via DELETE /v1/imports/{_id}

Delete an integration -- Deletes an integration. The integration is soft-deleted and retained in the recycle bin for 30 days before permanent removal. via DELETE /v1/integrations/{_id}

Unregister a connection from an integration -- Removes a connection's registration from the integration. This does not delete the connection itself -- it only removes it from the integration's registered-connections list. via DELETE /v1/integrations/{_id}/connections/{_connectionId}/register

Unregister a lookup cache from an integration -- Removes a lookup cache's registration from the integration. This does not delete the lookup cache itself — it only removes it from the integration's `_registeredLookupCacheIds` list. Fails when the cache is not registered on the integration, when a flow step in the integration still references it, or when an alias on the integration (or one of its flows) still points at it — including the alias that registration itself created. Remove the flow-step references and the alias (update the `aliases` array on the integration or flow) first, then retry. via DELETE /v1/integrations/{_id}/lookupcaches/{_lookupCacheId}/register

Purge a job's stored files -- Deletes **all** file artifacts associated with the job (exported rows, error-record dumps, page-processor artifacts, etc.) from underlying storage. After a successful call, `GET /v1/jobs/{_id}` will show an empty `files[]` array and `POST /v1/jobs/{_id}/files/signedURL` will return `204 No Content`. The job record itself is retained -- only the files are purged. This is irreversible. The platform also purges files automatically at `purgeAt` / `clickhousePurgeAt`; manual purge is only needed for storage-quota management or compliance workflows. via DELETE /v1/jobs/{_id}/files

Delete a lookup cache -- Soft-deletes a lookup cache and all its data. Retained for 30 days before permanent removal. To clear data without deleting the cache itself, use `DELETE /v1/lookupcaches/{_id}/data/purge` instead. via DELETE /v1/lookupcaches/{_id}

Delete specific keys from a lookup cache -- Removes named keys from a lookup cache. Send the keys to delete in the request body. To wipe every entry instead, call `DELETE /v1/lookupcaches/{_id}/data/purge`. Send the request with `Content-Type: application/json`. The body must be a JSON object with a `keys` property; a request with no body is rejected as `missing_parameter`. The response reports `success: true` for every submitted key, including keys that did not exist in the cache. via DELETE /v1/lookupcaches/{_id}/data

Purge all data from a lookup cache -- Removes every entry from a lookup cache. The cache itself is preserved — only its contents are cleared. Use this instead of deleting-and-recreating when you want to keep the cache's `_id`, name, and any references from flows intact. This operation is irreversible. To delete a subset of keys, use `DELETE /v1/lookupcaches/{_id}/data` with a `keys` body. via DELETE /v1/lookupcaches/{_id}/data/purge

Delete an MCP OAuth provider -- Deletes an MCP OAuth provider. MCP servers referencing this provider via `_mcpOAuthProviderId` will lose their OAuth configuration. via DELETE /v1/mcpoauthproviders/{_id}

Delete an MCP server -- Soft-deletes an MCP server. Retained in the recycle bin for 30 days before permanent removal. via DELETE /v1/mcpservers/{_id}

Permanently delete a resource -- Permanently purges a resource from the recycle bin. This action cannot be undone — the resource data is irrecoverably removed. Resources are auto-purged after 30 days. via DELETE /v1/recycleBinTTL/{_resourceType}/{_id}

Delete a role -- Soft-deletes the role and removes it from the `_roleIds` of every group in the account. Requires account owner or administrator access. via DELETE /v1/roles/{_id}

Delete a script -- Deletes a script. Soft-deleted and retained in the recycle bin for 30 days. via DELETE /v1/scripts/{_id}

Delete debug logs for a script -- Deletes all debug logs for the specified script. Synchronous and idempotent — works even if the script has no logs. via DELETE /v1/scripts/{_id}/logs

Delete a stack -- Deletes a stack. Soft-deleted and retained in the recycle bin for 30 days. via DELETE /v1/stacks/{_id}

Recycle stack system token (server stacks only) -- Rotates (recycles) the server stack's system token. The old token is immediately invalidated. Retrieve the new token via `GET /v1/stacks/{_id}/systemToken`. via DELETE /v1/stacks/{_id}/systemToken

Delete all global state keys -- Deletes **all** global state keys and their values. This is a destructive operation and cannot be undone. Prefer `DELETE /v1/state/{key}` to remove individual keys. via DELETE /v1/state

Delete a global state key -- Deletes a specific global state key and its value. Returns `404` if the key does not exist. via DELETE /v1/state/{key}

Delete an item -- Soft-deletes a file or folder to the recycle bin, where it is retained for 30 days and can be restored with `POST /v1/storage/items/{_id}/restore`. Deleting a folder also removes its entire subtree; the folder is removed immediately and its descendants follow asynchronously. Delete is never blocked by references — flows, exports, imports, and tokens that point at the item are left dangling and fail at runtime, so check `GET /v1/storage/items/{_id}/dependencies` first. A pending multipart upload cannot be deleted here — cancel it with `POST /v1/storage/files/{_id}/cancel`. via DELETE /v1/storage/items/{_id}

Purge an item -- Permanently deletes a soft-deleted item from the recycle bin and frees its storage. This cannot be undone. Purging a folder also purges its descendants; the folder and its subtree are removed asynchronously. Only items deleted directly can be purged — a descendant removed by its parent's deletion is purged together with that parent. The item must already be in the recycle bin. via DELETE /v1/storage/items/{_id}/purge

Delete a sync -- Deletes a sync and tears down its replication resources, including its datasets. The sync must be disabled first — deleting an enabled sync fails with `400 sync_delete_not_allowed`. Syncs are not recoverable through the recycle bin. via DELETE /v1/syncs/{_id}

Delete a tag -- Permanently deletes a tag from the account's tag catalog. via DELETE /v1/tags/{_id}

Delete a template -- Permanently deletes a template. via DELETE /v1/templates/{_id}

Delete a tool -- Deletes a tool. Soft-deleted and retained in the recycle bin for 30 days. Fails with 422 if other resources (MCP servers, access tokens) still reference this tool — call `GET /v1/tools/{_id}/dependencies` first to check. via DELETE /v1/tools/{_id}

Delete a trading partner connector -- Soft-deletes a trading partner connector. via DELETE /v1/tpconnectors/{_id}

Get form metadata catalog -- Returns projected resource and endpoint summaries for one import or export plane. Import catalogs may include derived `ignoreExisting`, `ignoreMissing`, and `isIdentifierPresent` flags on endpoints. Export catalogs return endpoint `{ id, name }` only. Published-only requests may be served from the MongoDB catalog cache and include an `X-Catalog-Cache` response header. via GET /api/httpconnectors/{_id}/catalog

Get resource and endpoint detail -- Returns scoped `httpConnectorResource` and `httpConnectorEndpoint` documents for a single export/import endpoint, or a paired import create/update batch. Lookup endpoints may be inlined when they are published and belong to the same connector. `endpointId` and `endpointIds` are mutually exclusive; `endpointIds` is only valid when `resourceType` is `import` and must contain exactly two comma-separated ObjectIds. Composite `id1+id2` values are rejected. via GET /api/httpconnectors/{_id}/resourceEndpointDetail

List on-premise agents -- Returns all on-premise agents configured in the account. Check `offline` to determine agent health — `true` means the platform has not received a heartbeat recently. via GET /v1/agents

Get an on-premise agent -- Returns a single on-premise agent. via GET /v1/agents/{_id}

List dependencies of an agent -- Returns resources that depend on this agent. Keys are resource types (e.g. `connections`); values are arrays of dependency entries. Check dependencies before deleting — the DELETE endpoint is blocked if dependents exist. Returns `{}` for both zero-dependency and nonexistent IDs. via GET /v1/agents/{_id}/dependencies

Display on-premise agent access token -- Returns the current unmasked access token for an agent. The agent process needs this token to authenticate its tunnel back to integrator.io. The access token is not included in normal GET/PUT responses — this is the only way to retrieve it. via GET /v1/agents/{_id}/display-token

Get on-premise agent installer download URL -- Returns a short-lived presigned S3 URL for downloading the on-premise agent installer binary. The URL is pre-signed for roughly 15 minutes. The `os` query parameter selects which installer to return: - `linux` → `agent-linux.run` - `windows` → `agent-windows.exe` via GET /v1/agents/{_id}/installer/signedURL

List APIM APIs -- Returns APIs published in the APIM platform for the account. Results are paginated with `page` and `perPage`. via GET /v1/apim/apis

Get APIM resource view URL -- Returns a signed URL that opens a published resource in the APIM console. via GET /v1/apim/{apiId}/{modelPlural}/{_id}/view

Get APIM console redirect URL -- Returns a signed URL that opens the APIM console home page for the account. via GET /v1/apim/redirect

Get APIM analytics redirect URL -- Returns a signed URL that opens the APIM analytics dashboard for the account. Optionally scope the dashboard to a time range with `from` and `to`. via GET /v1/apim/redirect/analytics

Get APIM settings -- Returns the APIM subdomain and service account email configured for the account. via GET /v1/apim/settings

List APIs -- Returns all APIs configured in the account. No pagination -- every API is returned in a single response. Legacy script-mode APIs (created before the builder/script distinction) may omit `type`, `version`, and `disabled`. A 204 response means the account has zero APIs. via GET /v1/apis

Get an API -- Returns the complete configuration of a specific API. via GET /v1/apis/{_id}

List captured requests for an API step -- Returns the set of requests captured for a single step of an API. `_stepId` identifies the step within the API's configuration. Each entry in `requests[]` is a captured request summary; follow up with `GET /v1/apis/{_id}/{_stepId}/requests/{key}` to retrieve one entry in full. An empty `requests[]` simply means nothing is currently stored for this step. via GET /v1/apis/{_id}/{_stepId}/requests

Get one captured request for an API step by key -- Returns the full captured request/response envelope for one entry of an API step, looked up by the opaque `key` values surfaced in `GET /v1/apis/{_id}/{_stepId}/requests`. Matches the exact entry whose key is provided — there is no partial-match query on this endpoint. Use the `key` exactly as returned by the parent listing; do not construct one manually. A 404 means the key has expired from retention or was never captured. via GET /v1/apis/{_id}/{_stepId}/requests/{key}

List dependencies of an API -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. An empty object `{}` means no other resources depend on the target -- this is also returned for a well-formatted but nonexistent id. via GET /v1/apis/{_id}/dependencies

List recent request/response logs for an API -- Returns the recent invocation traces captured for the named API. Each entry is a decoded request/response pair — masked for credentials — that the runtime stored when the API was called via its public endpoint. Use this to audit what the API has handled and to triage errors without re-invoking the API. Traces are **file-backed** with server-controlled retention and capture scope; an empty `requests[]` simply means nothing is currently stored for this API. Two invocation sources do **not** populate this log: - Test-runs via `POST /v1/apis/{_id}/test/run` never surface here. - Script-mode API invocations via `POST /v1/apis/{_id}/request` also do not surface here despite counting toward `/v1/apis/usage`. Only **builder-mode** invocations against the public endpoint (`https://api.integrator.io/apis/{version}{relativeURI}`) populate logs. List entries are **summaries** (`key`, `time`, `method`, `statusCode`) — to see the decoded request/response payload, follow up with `GET /v1/apis/{_id}/logs/{key}`. `statusCode` is returned as a string in list entries but as an integer on the detail endpoint. Credential values are masked as `********` before storage and are not recoverable. via GET /v1/apis/{_id}/logs

Get one request/response log entry by key -- Returns the full decoded request/response envelope for one API invocation, looked up by the opaque `key` values surfaced in `GET /v1/apis/{_id}/logs`. Matches the exact entry whose key is provided — there is no partial-match or range query on this endpoint. Unlike the parent list (which only carries `{key, time, method, statusCode}`), this endpoint returns the complete payload: request method/url/headers/body/queryParams/clientAddress, response status/headers/body/responseTime, and (for builder-mode APIs) the `inputToResponseBubble` snapshot of what the response-mapper saw. Sensitive header values (`authorization`, OAuth bearer tokens) are masked as `********` before storage. For builder APIs where the response mapper didn't produce the expected output, inspect `inputToResponseBubble.sourceRecord` to see what the response stage actually received. `response.statusCode` is an integer here but the sibling list endpoint returns it as a string. A 404 `file_not_found` means the key has expired from retention or was never captured. via GET /v1/apis/{_id}/logs/{key}

List API request run history (defaults to last 5 minutes) -- Returns the logged request executions for an API — one entry per inbound request captured while the API's `logging.mode` was anything other than `noLogging`. Distinct from `GET /v1/apis/{_id}/logs`, which returns the legacy file-backed request/response envelopes: use `/requests` for run history and trace drill-down, `/logs` for the raw decoded request and response of a single call. Whether requests are captured into run history depends on server-side enablement of the capture pipeline, which is separate from this read API. On accounts where capture is not active, this endpoint responds normally (including filter validation) but `requests` is empty regardless of the API's `logging.mode` — even for requests that the legacy `GET /v1/apis/{_id}/logs` (an independent capture path) does record. Results are cursor-paginated (`next`/`prev`). When `time_gte` / `time_lte` are omitted, only the last 5 minutes are returned — pass an explicit window for a broader history. Use the `executionId` from a list entry with `GET /v1/apis/{_id}/requests/{executionId}` to open the trace view for requests logged in `detailed` or `debug` mode. via GET /v1/apis/{_id}/requests

Get trace metadata for an API request execution -- Returns the top-level execution steps for the trace view of one API request. Trace data is only available for requests that were logged in `detailed` or `debug` mode (see `logMode` on the run-history entry), and only when the run-history capture pipeline is active for the account (see `GET /v1/apis/{_id}/requests`) — otherwise `steps` is empty for every execution id. A malformed `executionId` returns `422`; an unknown API `_id` returns `404`. via GET /v1/apis/{_id}/requests/{executionId}

List child records under an API trace step -- Returns the child records under a parent record within an API request trace (lookup / one-to-many expansions). Results are cursor-paginated (`next`/`prev`). via GET /v1/apis/{_id}/requests/{executionId}/{_expOrImpId}/logs/{parentRecordId}/children

Get a signed URL for a stored API request log payload -- Returns a short-lived signed S3 URL (about 120 seconds expiry) for the provided `s3Key` suffix, taken from an `externalReference` returned by the log-data query endpoint. The full S3 key is resolved under the execution's own log prefix, so callers can only access logs for this API and execution. via GET /v1/apis/{_id}/requests/{executionId}/logs/signedURL

Get a downloadable template for an API -- Packages a builder-mode API as an installable template and returns a signed S3 URL where the template `.zip` can be downloaded. The URL is pre-signed and short-lived (approximately 15 minutes), so fetch the file promptly; call the endpoint again for a fresh URL. The `.zip` contains the API definition plus every resource it references — imports, exports, connections, and scripts — grouped into one folder per resource type, with an `integration.json` manifest at the root. Only **builder-type** APIs can be exported — requesting a script-type API returns 404, the same as an unknown id. Requires the `create:api:template` permission. via GET /v1/apis/{_id}/template

Get a step's stages from an API test run -- Returns the per-stage execution detail for a single step of a completed API test run. `runId` is the parent `flowJob._id` returned by `POST /v1/apis/{_id}/test/run`, and `_stepId` is the step id surfaced in that run's `metadata` map. Each entry in `stages[]` carries the stage `name` (e.g. `request`, `parse`, `router`) plus its `input`, `output`, and `errors`. Stages that did not produce data for a given direction return `null` for that field. Top-level `errors` aggregates step-level errors. via GET /v1/apis/{_id}/test/run/{runId}/{_stepId}

Get request/response captures for an API test-run step -- Returns the request/response captures recorded for a single export or import step of an API test run. `runId` is the parent `flowJob._id` from `POST /v1/apis/{_id}/test/run`, and `_stepId` is the step id from that run's `metadata` map. Each entry in `requests[]` is a summary identified by an opaque `key`; fetch the full decoded request/response envelope with `GET /v1/apis/{_id}/{_stepId}/requests/{key}`. A step id that is not an export or import (such as a router) returns a 400 `invalid_ref`, and a step that captured no request/response data returns a 404 `req_res_logs_not_found`. via GET /v1/apis/{_id}/test/run/{runId}/{_stepId}/logs/requestAndResponse

List month-to-date API invocation counts -- Returns one invocation-counter record per resource + method + relativeURI in the current month. Counts API-style invocations across every resource type that exposes an HTTP-callable endpoint: custom APIs (builder and script), individual exports/imports called via `/invoke`, virtual imports, and APIM-fronted invocations. The endpoint aggregates -- it does not return one record per individual call. Each entry rolls up every invocation of that (resource, method, URI) triple in the current month. Counters reset on the 1st of each month; there is no pagination and no historical-months filter on this path. `ioInvocationCount` bills against the Celigo subscription; `apimInvocationCount` is billed separately for external APIM passthrough. To find the resource behind a row, read `metadata._resourceId` (present for exports/imports) or parse the resource id out of `relativeURI`. via GET /v1/apis/usage

List applications in use -- Returns every external application that has at least one connection in the account, grouped with summaries of those connections. via GET /v1/applications

List users -- Returns all users with access to the account. The account owner is not included — only invited users appear. via GET /v1/ashares

Get a user -- Retrieve a single user's access record by its id. via GET /v1/ashares/{_id}

List async helpers -- Returns an array of all async helper resources in the account. via GET /v1/asynchelpers

Get an async helper -- Returns a single async helper resource by its ID. via GET /v1/asynchelpers/{_id}

List dependencies of an async helper -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` for both zero-dependency and nonexistent IDs. via GET /v1/asynchelpers/{_id}/dependencies

Query audit logs -- Search audit log entries across all resources in the current account. Use this to answer "what changed?" across the account — filter by resource type, user, source, action, or time range. Results are ordered newest-first. Filtering by `resourceType` + `_resourceId` returns entries for that exact resource only — to include descendants (e.g. an integration's flows and exports), use `GET /v1/{resourceType}/{_id}/audit` instead. `_resourceId` requires `resourceType` to also be set. via GET /v1/audit

Get signed URL to download audit logs CSV (all documents) -- Generates a signed URL for downloading a CSV export of audit logs across all documents. The CSV columns are: Time, Source, User, Resource, Name/ID, Action, Field, Old value, New value, Support. The signed URL expires after 15 minutes. When `hasMore` is true, pass the last CSV row's timestamp as `to` to fetch the next batch. via GET /v1/audit/signedURL

Get audit log for a resource (and descendants) -- Returns audit log entries for a specific resource and its descendants. For example, querying an integration returns changes to the integration, its flows, exports, imports, and connections. For account-wide searches, use `GET /v1/audit` instead. via GET /v1/{resourceType}/{_id}/audit

List state keys for a resource -- Returns the list of state key names stored under the specified resource. These keys are separate from global state. Returns `204 No Content` when no keys exist for the resource. Only `exports`, `imports`, and `integrations` support resource-scoped state. Other resource types return `403`. This only lists key names, not values. Call `GET /v1/{resourceType}/{_resourceId}/state/{key}` to retrieve a specific value. via GET /v1/{resourceType}/{_resourceId}/state

Get a resource-scoped state value -- Returns the JSON value stored under the given key for a specific resource. Only `exports`, `imports`, and `integrations` support resource-scoped state. Returns the raw JSON value (object or array), not wrapped in an envelope. A 403 means the resource type doesn't support state, not a permissions issue. via GET /v1/{resourceType}/{_resourceId}/state/{key}

Get the authorization URL to re-authorize a connection -- Returns a short-lived authorization URL for running (or re-running) the OAuth handshake behind this connection. Redirect the end user to it; once they consent, Celigo's callback writes the tokens back and flips `needsAuthorization` to `false`. The single `authorizationUrl` response field serves both OAuth 2.0 and OAuth 1.0a connections (NetSuite returns an OAuth 1.0a URL with an `oauth_token` parameter). Note the resource segment is singular — `/v1/connection/{_id}/oauth2`, not plural. The URL's `state` token is one-time and expires quickly, so request a fresh one if the flow is interrupted, then poll `GET /v1/connections/{_id}` until `needsAuthorization` is `false`. via GET /v1/connection/{_id}/oauth2

List connections -- Returns a list of all connections configured in the account. If no connections exist in the account, a 204 response with no body will be returned. via GET /v1/connections

Get a connection -- Retrieves a specific connection by its unique identifier. Returns the complete connection configuration including authentication settings. via GET /v1/connections/{_id}

Fetch debug logs for a connection -- Returns the buffered debug log stream for the connection — request/response pairs from recent exports, imports, and lookups that used it. Capture is gated by the connection's `debugDate`: logs are recorded only while `debugDate` is in the future, so enable it first via `PUT /v1/connections/{_id}` or the buffer stays empty. The response is a plain-text stream (not JSON): each entry is a header line (`timestamp traceKey resourceType resourceId`) followed by a single-line JSON payload, entries separated by blank lines; paired request/response entries share a `traceKey`. Logs are shared across every flow using the connection (filter by `resourceId` client-side), and sensitive header values are redacted (`"Authorization": "********"`). For execution logs tied to a specific run, use `GET /v1/flows/{_id}/jobs/{_jobId}/logs` instead. via GET /v1/connections/{_id}/debug

List dependencies of a connection -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` for both zero-dependency and nonexistent IDs. via GET /v1/connections/{_id}/dependencies

List connectors -- Returns all connectors owned by the authenticated Partner account. **Partner-only endpoint.** via GET /v1/connectors

Get a connector -- Returns a single connector by ID. **Partner-only endpoint.** via GET /v1/connectors/{_id}

Get the install base for a connector -- Returns the list of accounts that have installed this connector. **Partner-only endpoint.** via GET /v1/connectors/{_id}/installBase

List licenses for a connector -- Returns all licenses issued for this connector. **Partner-only endpoint.** via GET /v1/connectors/{_id}/licenses

Get a license -- Returns a specific license for a connector. **Partner-only endpoint.** via GET /v1/connectors/{_id}/licenses/{_licenseId}

Preview a connector install -- Returns a preview of what installing this connector would produce. The connector must be associated with an integration that has the install function configured. via GET /v1/connectors/{_id}/preview

List datasets available on a connection -- Returns the catalog of tables/objects a connection's application exposes for syncing, plus the connection's existing export resources that can back export-based datasets. Use the returned `name` values as `externalId` when creating datasets via `PUT /v1/syncs/{_syncId}/datasets`. via GET /v1/di/metadata/connections/{_connectionId}/datasets

Get column details for a dataset on a connection -- Returns the full column/field catalog for one table/object on a connection, as read from the source application. Use it to build the `dataElements` selection before saving a dataset via `PUT /v1/syncs/{_syncId}/datasets` — each element's `name` here is the `name` to reference there. via GET /v1/di/metadata/connections/{_connectionId}/datasets/{datasetName}/details

List supported sync destination applications -- Returns the catalog of applications that can be used as the **destination** of a sync — the data warehouse a sync loads records into. Use the returned `id` as the destination application when building a sync. Identifiers include `snowflake` (Snowflake), `nsaw` (NetSuite Analytics Warehouse), and `bigquery` (Google BigQuery). via GET /v1/di/metadata/destinations

List supported sync source applications -- Returns the catalog of applications that can be used as the **source** of a sync — the system a sync extracts records from. Use the returned `id` as the source application when building a sync, and `category` to group the options in a picker. via GET /v1/di/metadata/sources

List a connection's datasets merged with a sync's configuration -- Returns the connection's full dataset catalog with the sync's saved configuration merged in: catalog entries the sync already replicates carry their stored dataset fields (`_id`, `enable`, `ingestionMode`, …) plus computed `totalFieldCount` and `selectedFieldCount`, while unsaved entries appear with catalog fields only. `dataElements` arrays are stripped from every item to keep the payload small — read one item's columns with the sync-scoped details endpoint. Use this to render or reconcile a sync's dataset selection; for just the saved datasets, `GET /v1/syncs/{_syncId}/datasets` is lighter. via GET /v1/di/metadata/sync/{_syncId}/connections/{_connectionId}/datasets

Get column details for a dataset in a sync's context -- Returns one table/object's full column catalog from the source, merged with the sync's saved dataset state — enablement, `ingestionMode`, `exportProperties`, drift policy, and per-column selections. Use it to edit a dataset's `dataElements` with the current source schema and saved selections in one payload. via GET /v1/di/metadata/sync/{_syncId}/connections/{_connectionId}/datasets/{datasetName}/details

List events for a sync -- Returns the events recorded for a sync across all of its runs — schema drift the platform detected or applied, and data-catalog activity — newest first. Events are retained per the account's data retention period; a `time_lte` older than the retention window returns an empty list. via GET /v1/di/resource/syncs/{_syncId}/events

Download an EDI file -- Downloads the raw EDI file content for a specific document number. The `documentType` query parameter is required and must be the EDI document type code — for X12, the numeric transaction-set ID as a string (e.g. `850`, `810`, `856`, `997`); for EDIFACT, the UNH01 message type (e.g. `ORDERS`, `INVOIC`, `DESADV`, `CONTRL`). The server uses `documentType` + `documentNumber` together to locate the transaction record and return the associated raw EDI file. Get `documentNumber` and `documentType` from a transaction record returned by `POST /v1/ediTransactions/query`. Alternatively, download via `POST /v1/jobs/{_flowJobId}/files/signedURL` using the `s3Key` from the transaction record. via GET /v1/edi/documents/{documentNumber}/ediFile

Get historic label-printing usage -- Returns account-wide EDI label-printing (BarTender) consumption bucketed into the trailing 12 ISO weeks (Monday–Sunday UTC), most-recent week first. Each week's total sums every flow and environment under the account. Pair with the `ediLabelPrintingUsage` block on `GET /v1/licenseEntitlementUsage` for the current week's per-flow breakdown. via GET /v1/ediLabelPrinting/usage/summary

List EDI profiles -- Returns all EDI profiles configured in the account. via GET /v1/ediprofiles

Get an EDI profile -- Returns a specific EDI profile. via GET /v1/ediprofiles/{_id}

List dependencies of an EDI profile -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` when no dependents exist, including for well-formatted but nonexistent IDs. via GET /v1/ediprofiles/{_id}/dependencies

Get FA details for an EDI transaction -- Returns functional acknowledgment (FA) details for a specific EDI transaction. FA details are only available for transactions with a "Rejected" status in B2B Manager. via GET /v1/ediTransactions/{_ediTransactionId}/faDetails

Get MDN details for an EDI transaction -- Returns AS2 Message Disposition Notification (MDN) metadata for a specific EDI transaction record from the B2B Manager dashboard. The server reads the stored MDN artifact associated with the transaction and returns its raw body text together with a parsed disposition classification. Get `_id` from a record returned by `POST /v1/ediTransactions/query`. via GET /v1/ediTransactions/{_ediTransactionId}/mdn

List end users -- Returns the account's end users with identity fields (`email`, `name`, `lastSignIn`) joined from each user record, plus a computed `hasWorkspaceShare` flag indicating whether the same person also holds a workspace access record. Requires account owner or administrator access. via GET /v1/endusers

Get an end user's effective access -- Compiles the end user's effective MCP server tool access with source attribution — the union of direct grants, group grants, role grants, and permission sets. The result is recomputed on every request rather than cached. Requires account owner or administrator access. via GET /v1/endusers/{_ashareId}/effective-access

List environments -- Returns all environments in the account. Requires the environments feature to be enabled -- accounts without it receive `feature_not_enabled`. Every account with the feature has at least one environment (Production). The full list is returned in a single unpaginated response. via GET /v1/environments

Get an environment -- Retrieves a single environment by ID. via GET /v1/environments/{_id}

Get static filter enum metadata for errors -- Returns the static enumeration values used to filter errors across the platform. The response is not scoped to the authenticated user — every caller receives the same set of filter dimensions and allowed values. Currently returns two filter dimensions: - **source** (24 values): `internal`, `application`, `connection`, `resource`, `transformation`, `output_filter`, `input_filter`, `import_filter`, `lookup`, `mapping`, `response_mapping`, `pre_save_page_hook`, `pre_parse_hook`, `pre_map_hook`, `post_map_hook`, `post_submit_hook`, `post_response_map_hook`, `post_aggregate_hook`, `pre_send_hook_ss`, `pre_map_hook_ss`, `post_map_hook_ss`, `post_submit_hook_ss`, `tool_input`, `tool_output`. - **classification** (10 values): `connection`, `duplicate`, `governance`, `intermittent`, `missing`, `parse`, `value`, `rate_limit`, `too_large`, `none`. The values are static and identical for all callers — cache them aggressively. via GET /v1/errors/filterMetadata

List event reports -- Returns all event report objects for the account. No pagination or filtering is supported — query parameters like `eventReportId`, `_limit`, and `status` are accepted but silently ignored. via GET /v1/eventreports

Get an event report -- Returns a single event report by ID. Check `status` for `completed` before attempting to download via the signed URL. The `reportGenerationErrors` array may contain per-flow errors even when the overall status is `completed`. via GET /v1/eventreports/{_id}

Get signed URL for an event report -- Returns a pre-signed S3 URL for downloading the completed event report as a CSV file. The URL is valid for approximately 15 minutes. Only works when the report `status` is `completed` -- requesting it in any other status returns 400. If the URL has expired, call this endpoint again to get a fresh one. via GET /v1/eventreports/{_id}/signedURL

List exports -- Returns a list of all exports configured in the account. If no exports exist in the account, a 204 response with no body will be returned. via GET /v1/exports

Get an export -- Returns the complete configuration of a specific export. via GET /v1/exports/{_id}

List dependencies of an export -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` when no dependents exist, including for well-formatted but nonexistent IDs. via GET /v1/exports/{_id}/dependencies

List file definitions -- Returns file definitions configured in the account. via GET /v1/filedefinitions

Get a file definition -- Returns the complete configuration including parsing rules. via GET /v1/filedefinitions/{_id}

List dependencies of a file definition -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` when no dependents exist, including for well-formatted but nonexistent IDs. via GET /v1/filedefinitions/{_id}/dependencies

List flows -- Returns all flows in the account. via GET /v1/flows

Get a flow -- Returns the complete configuration of a flow, including its page generators, processors, routers, schedule, and all nested settings. Walk `pageGenerators[]._exportId` and `pageProcessors[]._importId` (or `routers[].branches[].pageProcessors[]`) to discover the exports and imports wired into the flow. For the full resource objects, use `GET /v1/flows/{_id}/descendants` instead of fetching each one individually. Instance flows (`_abstractFlowId` is set) have sparse top-level fields because the runtime merges them with the abstract flow's config. via GET /v1/flows/{_id}

Get the stored retry-data snapshot for an error -- Returns the per-record snapshot the runtime captured at the moment of failure — the shape that `POST .../retry` re-feeds into the flow pipeline. The response is an envelope: `data` carries the adaptor-specific record payload; surrounding fields (`stage`, `pgExportId`, `oneToMany`, `pathToMany`, `childIndex`, `traceKey`) identify where in the pipeline the record was when it failed and how it's structured. The `data` field shows exactly the payload the runtime tried to submit — compare it against the source system to pinpoint transformation drift. Use `PUT .../{retryDataKey}/data` to mutate the snapshot before retrying. Only errors with a `retryDataKey` expose this endpoint; connection-class errors are rejected with `no_retrydata_found`. The `stage` field indicates where the retry will resume: `page_processor_import` re-runs the import (most common), `page_generator` means the error was upstream of the processor. via GET /v1/flows/{_id}/{_stepId}/{retryDataKey}/data

Get a signed URL to download file-type retry data -- Returns a pre-signed S3 URL for downloading the raw retry data file associated with an error. This only works for **file-type** retry data (e.g. file-based exports/imports). For standard record-based retry data, use `GET .../{ retryDataKey}/data` instead. File-based adaptors (FTP, S3, etc.) store retry data as files; record-based adaptors store JSON snapshots accessible via `GET .../{ retryDataKey}/data` instead. The signed URL requires no auth headers. via GET /v1/flows/{_id}/{_stepId}/{retryDataKey}/signedURL

List open errors on a flow step -- Returns one page of currently-open (unresolved) errors for a single step (export or import) within a flow. The step id is the `_exportId` / `_importId` from the flow's `pageGenerators[]`, `pageProcessors[]`, or `routers[].branches[].pageProcessors[]`. For a flow-wide rollup (per-step counts only), use `GET /v1/flows/{_id}/errors` instead. To scope the list to one specific run, pass `_flowJobId` together with the required `occurredAt_gte`. Errors with a `retryDataKey` are retryable via `POST .../retry`; connection-level errors typically lack one and require a full flow rerun to recover. via GET /v1/flows/{_id}/{_stepId}/errors

Get a signed URL to download open errors as CSV -- Returns a pre-signed S3 URL that streams all currently-open errors for a flow step as a CSV file. The URL expires after approximately 15 minutes. The CSV always includes a header row, even when the step has zero open errors. CSV columns: `occurredAt`, `source`, `code`, `message`, `traceKey`, `exportDataURI`, `importDataURI`, `oIndex`, `retryDataKey`, `errorId`, `legacyId`, `reqAndResKey`, `purgeAt`, `tags`, `assignedTo`, `assignedBy`, `_assignedToUserId`. The signed URL requires no auth headers — do not attach your bearer token when fetching the CSV. via GET /v1/flows/{_id}/{_stepId}/errors/signedURL

List stored HTTP request/response traces for a flow step -- Returns a paginated list of HTTP request/response trace metadata for a flow step, filtered by time window, status code, method, and/or pipeline stage. Each entry contains summary metadata — use `GET .../requests/{reqAndResKey}` to fetch the full decoded request/response pair for a specific trace. **Important:** Time parameters (`time_lte`, `time_gt`) must be epoch milliseconds (integers), not ISO 8601 strings. Use `GET .../requests/{reqAndResKey}` to drill into individual request/response bodies. `statusCode` is returned as a string, not an integer. For oversized bodies stored in S3, follow up with `GET .../requests/{key}/files/signedURL`. via GET /v1/flows/{_id}/{_stepId}/requests

Get a signed URL for an oversized request/response body -- Returns a pre-signed S3 URL for downloading the full request or response body when it was too large to store inline in the trace record. Most request/response pairs have inline bodies accessible via `GET .../requests/{reqAndResKey}` — this endpoint is only needed for the subset where the body was offloaded to S3 due to size. Call `GET .../requests/{reqAndResKey}` first. If `request.body` or `response.body` is truncated or missing, use this endpoint to fetch the full payload from S3. via GET /v1/flows/{_id}/{_stepId}/requests/{key}/files/signedURL

Get the HTTP request/response for an errored record -- Returns the decoded HTTP request and response the runtime captured at the moment an error occurred, looked up by the opaque `reqAndResKey` found on each error in `GET .../errors`. Sensitive values are masked **before** storage — query-string credentials, `Authorization` headers, OAuth bearer tokens, and similar are rendered as `********`. You cannot recover the original values from this endpoint. The `time` and `response.receivedAt` fields are epoch milliseconds, useful for correlating with target-system logs. Not every error has a stored trace — record-level errors from non-HTTP adaptors (e.g. NetSuite distributed imports) lack a `reqAndResKey`. via GET /v1/flows/{_id}/{_stepId}/requests/{reqAndResKey}

List resolved errors on a flow step -- Returns one page of already-resolved errors for a flow step (same shape as the open-errors listing). Errors arrive here either because a user marked them resolved (`PUT .../resolved`) or because a successful retry auto-resolved them. The platform retains resolved errors through the account's retention window; use `DELETE .../resolved` to purge them earlier. `resolvedBy` distinguishes how each error was closed: `auto` means a system-initiated auto-retry cleared it; a user ID means the error was resolved manually or via a user-triggered retry. via GET /v1/flows/{_id}/{_stepId}/resolved

Get a signed URL to download resolved errors as CSV -- Returns a pre-signed S3 URL that streams all resolved errors for a flow step as a CSV file. The URL expires after approximately 15 minutes. The CSV always includes a header row, even when there are zero resolved errors. The CSV includes the same columns as the open-errors signed URL, plus two prepended columns: `resolvedAt` and `resolvedBy`. Full CSV columns: `resolvedAt`, `resolvedBy`, `occurredAt`, `source`, `code`, `message`, `traceKey`, `exportDataURI`, `importDataURI`, `oIndex`, `retryDataKey`, `errorId`, `legacyId`, `reqAndResKey`, `purgeAt`, `tags`, `assignedTo`, `assignedBy`, `_assignedToUserId`. For currently-open errors, use `GET .../errors/signedURL` instead. via GET /v1/flows/{_id}/{_stepId}/resolved/signedURL

Preview cloning a flow -- Returns a preview of resources that would be created by cloning this flow — the target flow and all transitive dependencies (connections, exports, imports, scripts, async helpers, lookup caches). No resources are created. Call this before `POST /v1/flows/{_id}/clone` to discover which connections need remapping in the `connectionMap` body field. via GET /v1/flows/{_id}/clone/preview

List dependencies of a flow -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. An empty object `{}` means no other resources depend on the target — this is also returned for a well-formatted but nonexistent id. via GET /v1/flows/{_id}/dependencies

Get a flow's descendant resources -- Returns the full resource objects for every import, export, and tool referenced by the flow. This is a convenience endpoint that resolves the flow's entire dependency tree in a single call — equivalent to reading the flow config and then fetching each referenced resource individually, but without the N+1 round-trips. The returned arrays mirror the full resource shapes from `GET /v1/imports/{_id}`, `GET /v1/exports/{_id}`, and `GET /v1/tools/{_id}`. via GET /v1/flows/{_id}/descendants

Summarize open errors across a flow's steps -- Returns a per-step count of currently open (unresolved) errors for the flow. Each entry carries the step id and its open-error count; entries with zero errors still appear so the caller sees the full step roster. For the full list of error records on a single step, call `GET /v1/flows/{_id}/{_stepId}/errors`. For a whole-integration rollup, use `GET /v1/integrations/{_id}/errors`. `lastErrorAt` is only populated on entries with `numError > 0`. via GET /v1/flows/{_id}/errors

List child log records for a parent record -- Returns one page of child log records for a specific parent record within a flow-run step. Child records represent sub-operations (e.g. individual batch items, lookup expansions, or retry attempts) spawned by the parent record during step processing. Use the `status` query parameter to isolate failures within a batch. via GET /v1/flows/{_id}/jobs/{_jobId}/{_stepId}/logs/{recordId}/children

List execution log entries for a flow run -- Returns one page of execution-log entries for a specific flow run — one entry per record-at-step (export or import). Entries carry the `(_expOrImpId, groupId, recordId, traceKey)` tuple needed to drill into per-stage metadata and data via the `logs/metadata/query` and `logs/data/query` endpoints. Execution logs are populated only when the flow has logging enabled (either full `logMode` or the time-bounded `logging.debugUntil` debug window). Jobs older than the flow's log retention window will return an empty `logs` array. For detailed per-stage data (HTTP request/response, script `options.logs` output), pick an entry and call `POST .../logs/data/query` with the corresponding `stage`. To stitch an export entry to its downstream imports, use the `traceKey` with `POST .../logs/metadata/query`. via GET /v1/flows/{_id}/jobs/{_jobId}/logs

Get the most recent job(s) for a flow -- Returns the most recent job record(s) for the given flow. Typically one entry (the latest flow run), though the platform may include related retry jobs depending on account configuration. For a richer parent+children view, feed the returned `_id` into `GET /v1/jobs/{_id}/family`. via GET /v1/flows/{_id}/jobs/latest

Search jobs within a flow by trace key -- Searches for flow-run jobs that contain records matching a trace key prefix. Returns up to 1000 matching job objects — there is no pagination beyond that limit. The `traceKeyPrefix` query parameter is required; the server returns `400` when it is missing. Known behavior: the `status` filter is accepted but silently ignored — the response always includes jobs of all statuses regardless of the filter value. Narrow the window with `createdAt_gte` / `createdAt_lte` when there are many runs for the flow. Because `status` is silently ignored, filter client-side if you need only completed or errored jobs. via GET /v1/flows/{_id}/jobs/search

Get the flow's delta checkpoint -- Returns the flow-level "last export date/time" checkpoint — the most recent export timestamp across all generators (exports) in the flow. This value is what gets substituted into the `{{lastExportDateTime}}` Handlebars variable on the next delta run of any export in the flow. The checkpoint advances automatically at the end of a successful delta run. It can be overridden per run by passing `export.startDate` / `export.endDate` to `POST /v1/flows/{_id}/run`. A missing or very old value means the next delta run will re-scan the full history window from the source. This is the flow-scoped checkpoint; per-export checkpoints (for flows with multiple generators that advance independently) are exposed on the export record's `delta` block. via GET /v1/flows/{_id}/lastExportDateTime

Get per-stage detail for a flow test-run step -- Returns the per-stage input, output, and errors captured for a single step of a flow test run. Each step runs through one or more named **stages** (e.g. `request`, `parse`, `input`, `router`); this endpoint returns the ordered `stages[]` for the requested step plus a top-level `errors` array aggregating any step-level errors. The `runId` is the `flowJob._id` from the `POST /v1/flows/{_id}/test/run` response — test runs keep a separate history from production Job records. `{_stepId}` is one of the step ids from that response's `metadata` map; the stage names returned here match the stage list that map recorded for the step. For each stage, `input` and `output` are arrays of record envelopes (`{record, errors, traceKey}`) and may be `null` when the stage produced no records on that side. Use `GET /v1/flows/{_id}/test/run/{runId}/{_stepId}/logs/requestAndResponse` when you need the raw outbound HTTP request/response captures instead of the staged record view. **Endpoint template applies across three resource families.** The same path shape also exists for Tools (`/v1/tools/{_id}/test/run/{runId}/{_stepId}`) and builder-mode APIs (`/v1/apis/{_id}/test/run/{runId}/{_stepId}`). Test-run state is short-lived and ephemeral — read step detail soon after the run completes. via GET /v1/flows/{_id}/test/run/{runId}/{_stepId}

Get request/response logs for a flow test-run step -- Returns the outbound HTTP request/response log pairs captured during a specific step of a flow test run. Only steps that issued outbound HTTP calls (exports, imports, lookups) produce entries — routers, filters, and other in-process stages are rejected with `req_res_logs_not_found` by design. The `runId` comes from the `POST /v1/flows/{_id}/test/run` response (not from a normal flow run Job record — test runs and regular runs are separate histories). `{_stepId}` is the export or import id of the step you want logs for; find the id among the keys in the test-run `metadata` map. **Endpoint template applies across resource families.** The same path shape also exists for Tools (`/v1/tools/{_id}/test/run/.../logs/requestAndResponse`) and builder-mode APIs (`/v1/apis/{_id}/test/run/.../logs/requestAndResponse`), but response shapes differ by family: the builder-mode **API** variant returns a `{ requests: [] }` summary envelope whose entries are resolved via `GET /v1/apis/{_id}/{_stepId}/requests/{key}`, rather than the array of `{ request, response }` pairs documented here. Refer to each family's spec for its exact response shape. Response entries may carry base64-encoded JSON in `request.body` and `response.body` fields — decode string bodies before parsing. A 404 response is expected for non-HTTP steps (routers, filters); cross-check against the test-run metadata's stage list before treating it as a failure. Test runs are short-lived ephemeral state, so capture logs soon after the run completes. via GET /v1/flows/{_id}/test/run/{runId}/{_stepId}/logs/requestAndResponse

Get a flow's trace-key patterns -- Returns the trace-key pattern for each page generator in the flow. Trace keys are used to correlate source records with their downstream results in execution logs — they let you look up "what happened to record X" without scanning the full log. Each entry in the returned array corresponds to one page generator (`pgIndex` matches the zero-based position in the flow's `pageGenerators` array). The `traceKeyPattern` describes which source-record fields and/or Handlebars templates are combined to produce the key. If both `fields` and `templates` are empty for a generator, the flow has no trace key configured and log correlation must be done by position or other means. Trace keys are especially important for fan-out flows where one source record produces many destination records. via GET /v1/flows/{_id}/traceKey

List groups -- Returns all active groups in the account. Requires account owner or administrator access. via GET /v1/groups

Get a group -- Retrieves a single group by ID. via GET /v1/groups/{_id}

Get historical monthly entitlement usage -- Returns historical monthly usage for accounts on flow-run pricing models (primarily platform licenses). Useful for month-by-month trend analysis of usage vs. allocation. via GET /v1/historicalMonthlyUsage

List HTTP connectors -- Returns all HTTP Connectors visible to the authenticated account. The list response is abridged -- it omits `published`, `baseURIs`, `supportedBy`, and other detail fields. Use the by-ID endpoint for the full object. via GET /v1/httpconnectors

Get an HTTP connector endpoint -- Retrieves the full HTTP Connector Endpoint including `method`, `relativeURI`, `queryParameters`, `pathParameters`, and `supportedBy` details omitted from the list endpoint. via GET /v1/httpconnectors/{_httpConnectorId}/{_httpConnectorResourceId}/{_id}

List HTTP Connector Endpoints for a connector resource -- Returns all endpoints defined under the given HTTP Connector Resource. The list response is abridged — only `_id`, `name`, `createdAt`, and `lastModified` are returned. Use the by-ID endpoint for the full object including `method`, `relativeURI`, and `supportedBy`. via GET /v1/httpconnectors/{_httpConnectorId}/{_httpConnectorResourceId}/httpconnectorendpoints

Get an HTTP connector resource -- Retrieves a specific HTTP Connector Resource by its unique identifier. The path uses a shortcut form: `/v1/httpconnectors/{_httpConnectorId}/{_id}` where `{_id}` is the resource ID directly under the connector. The longer form `/v1/httpconnectors/{_httpConnectorId}/httpconnectorresources/{_id}` is not supported and fails with an `invalid_ref` error. The detail response includes `published` and `_httpConnectorId` fields that are omitted from the list endpoint. via GET /v1/httpconnectors/{_httpConnectorId}/{_id}

List HTTP Connector Resources for a connector -- Returns all resources (logical API groupings) defined under the given HTTP Connector. The list response is abridged — it omits `published` and `_httpConnectorId` compared to the detail endpoint. Use `GET /v1/httpconnectors/{_httpConnectorId}/{_id}` for the full object. Each resource's `_id` doubles as the `_httpConnectorResourceId` path parameter used by the HTTP Connector Endpoints API. via GET /v1/httpconnectors/{_httpConnectorId}/httpconnectorresources

Get an HTTP connector -- Retrieves the full HTTP Connector object including `published`, `baseURIs`, `supportedBy`, and version details omitted from the list endpoint. via GET /v1/httpconnectors/{_id}

Get form metadata catalog -- Returns projected resource and endpoint summaries for one import or export plane. Import catalogs may include derived `ignoreExisting`, `ignoreMissing`, and `isIdentifierPresent` flags on endpoints. Export catalogs return endpoint `{ id, name }` only. Published-only requests may be served from the MongoDB catalog cache and include an `X-Catalog-Cache` response header. via GET /v1/httpconnectors/{_id}/catalog

Get resource and endpoint detail -- Returns scoped `httpConnectorResource` and `httpConnectorEndpoint` documents for a single export/import endpoint, or a paired import create/update batch. Lookup endpoints may be inlined when they are published and belong to the same connector. `endpointId` and `endpointIds` are mutually exclusive; `endpointIds` is only valid when `resourceType` is `import` and must contain exactly two comma-separated ObjectIds. Composite `id1+id2` values are rejected. via GET /v1/httpconnectors/{_id}/resourceEndpointDetail

List iClients -- Returns all iClients in the account. Does not paginate — all iClients are returned in a single response. via GET /v1/iclients

Get an iClient -- Retrieves a single iClient by ID. via GET /v1/iclients/{_id}

List dependencies of an iClient -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` when no dependents exist, including for well-formatted but nonexistent IDs. via GET /v1/iclients/{_id}/dependencies

List imports -- Returns a list of all imports configured in the account. If no imports exist in the account, a 204 response with no body will be returned. Celigo documents this same endpoint on 3 resource pages: imports (listImports) plus ai-agents (listAiAgents), guardrails (listGuardrails). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via GET /v1/imports

Get an import -- Returns the complete configuration of a specific import. Celigo documents this same endpoint on 3 resource pages: imports (getImportById) plus ai-agents (getAiAgentById), guardrails (getGuardrailById). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via GET /v1/imports/{_id}

Preview cloning an import -- Returns a preview of the resources that would be created by cloning the specified import. The response includes the target import and any transitive dependencies (e.g. connections, scripts). No resources are created by this endpoint. via GET /v1/imports/{_id}/clone/preview

List dependencies of an AI agent -- Returns resources that depend on this AI agent import. Keys are resource types (e.g. `flows`); values are arrays of dependency entries. Check dependencies before deleting — the DELETE endpoint is blocked if dependents exist. Returns `{}` for both zero-dependency and nonexistent IDs. Celigo documents this same endpoint on 3 resource pages: ai-agents (listAiAgentDependencies) plus guardrails (listGuardrailDependencies), imports (listImportDependencies). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via GET /v1/imports/{_id}/dependencies

List integrations -- Returns all integrations in the account. Supports field projection via `include`/`exclude`. via GET /v1/integrations

Get an integration -- Returns the full integration object. via GET /v1/integrations/{_id}

List account shares for an integration -- Returns an array of account-share (ashare) objects for the integration. Each entry describes a user who has been granted access to the integration's owning account, along with their access level and authentication metadata. Unlike other integration sub-resource list endpoints, this always returns an array (an integration with no shares returns `[]`). via GET /v1/integrations/{_id}/ashares

List async helpers belonging to an integration -- Returns a bare array of async-helper objects for every async helper registered to the integration. Each element is a complete async-helper resource, the same shape as `GET /v1/asynchelpers/{_id}`. via GET /v1/integrations/{_id}/asynchelpers

Preview cloning an integration -- Returns a preview of the resources that would be created by cloning the specified integration. The response includes the integration and all transitive dependencies — flows, connections, exports, imports, scripts, async helpers, lookup caches, and tools. No resources are created by this endpoint. via GET /v1/integrations/{_id}/clone/preview

List an integration's clone family -- Returns every member of the integration's clone family -- the original plus every clone (recursively, across environments). Used by ILM to decide which integrations can be pull/push sources or targets for the current integration. This endpoint requires the `integrator-ashareid` header to establish a shared-account context. For simpler clone-relationship lookups, the integration's own `_sourceId` field points to the parent it was cloned from, and `GET /v1/integrations?_sourceId=<id>` lists the children. via GET /v1/integrations/{_id}/clonefamily

List connections belonging to an integration -- Returns a bare array of full connection objects for every connection registered to the integration. Each element is a complete connection resource, the same shape as `GET /v1/connections/{_id}`. Unlike the flows/imports/exports sub-resource endpoints, this endpoint rejects unknown integration ids with a 404. via GET /v1/integrations/{_id}/connections

List dependencies of an integration -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. An empty object `{}` means no other resources depend on the target (also returned for a well-formatted but nonexistent id). via GET /v1/integrations/{_id}/dependencies

Summarize open errors across an integration's flows -- Returns a per-flow count of currently open (unresolved) errors for every flow in the integration. Flows with zero open errors still appear so callers see the full flow roster; `lastErrorAt` is only populated when `numError > 0`. Entries do not contain individual error ids -- to get actionable error records, drill into `GET /v1/flows/{_flowId}/{_stepId}/errors` for each flow and step. via GET /v1/integrations/{_id}/errors

List exports belonging to an integration -- Returns a bare array of full export objects for every export in the integration. Each element is a complete export resource, the same shape as `GET /v1/exports/{_id}`. via GET /v1/integrations/{_id}/exports

List flows belonging to an integration -- Returns a bare array of full flow objects for every flow in the integration. Each element is a complete flow resource, the same shape as `GET /v1/flows/{_id}`. via GET /v1/integrations/{_id}/flows

List available ILM ignore fields -- Returns the catalog of *available* fields that can be ignored when pulling changes between related integrations. Keys are lowercase resource types (`integration`, `flow`, `export`, `import`, `connection`, `script`, ...); values are arrays of dot-path field names that can be excluded from an ILM pull/revert. The key set is platform-driven — treat the response, not the example list, as the authoritative catalog. This endpoint requires the `integrator-ashareid` header to establish a shared-account context. The current ignore configuration lives on the integration's `iLMIgnore` field (readable via `GET /v1/integrations/{_id}`); this endpoint only returns the menu of what *can* be ignored. To change the configuration, PATCH the integration with `[{op:"replace", path:"/iLMIgnore", value:{...}}]`. via GET /v1/integrations/{_id}/iLMIgnore

List imports belonging to an integration -- Returns a bare array of full import objects for every import in the integration. Each element is a complete import resource, the same shape as `GET /v1/imports/{_id}`. via GET /v1/integrations/{_id}/imports

Get the most recent job(s) for an integration -- Returns the most recent job record(s) across all flows in the given integration. Useful for a top-level status check on an integration. The result is not filtered by status -- inspect each entry's `status` to distinguish success from failure. via GET /v1/integrations/{_id}/jobs/latest

List revisions for an integration -- Returns every revision entry (snapshots, pulls, reverts) for the integration, newest first. An integration with no revision history returns an empty response (204), not `[]`. via GET /v1/integrations/{_id}/revisions

Get a revision -- Returns the full revision record. The list endpoint already surfaces every field, so this is primarily useful when you have a `_revisionId` in hand (e.g. from a webhook, audit log, or external reference) and want to verify state without re-listing. via GET /v1/integrations/{_id}/revisions/{_revisionId}

Diff a pending revision -- Returns the before/after diff for a pull or revert revision. The diff is materialized on `pull` and `revert` revisions and is retained on their `completed` state -- available for both `inprogress` and `completed` pull/revert revisions. Snapshot revisions are not diffable (there is no source integration to diff against), and `canceled` revisions drop their diff. The response body is a `{before, after}` envelope where each side is a map keyed by resource type (e.g. `flow`, `export`, `connection`, `api`, `tool`) whose values are maps of resourceId to full resource snapshot. via GET /v1/integrations/{_id}/revisions/{_revisionId}/diff

Get a downloadable template for an integration -- Packages the integration as an installable template and returns a signed S3 URL where the template `.zip` can be downloaded. The URL is pre-signed and short-lived (it expires shortly after issuance), so fetch the file promptly after calling this endpoint. The downloaded `.zip` is the same artifact used to install the integration as a template into another account. via GET /v1/integrations/{_id}/template

Get integration tree metadata -- Returns structural metadata for the integration and its child integrations. The response includes install steps, flow groupings, API groupings, registered connection ids, uninstall steps, and change-edition steps, plus a `childIntegrations` array with the same structure for each child. Primarily useful for Integration App integrations that have install/uninstall steps and child integrations. via GET /v1/integrations/{_id}/tree/metadata

Get the latest sync job for each sync in an integration -- Returns the most recent sync job for each sync resource belonging to the given integration. The response is a bare JSON array with one `SyncJob` entry per sync. Returns an empty response when no sync jobs exist for any sync in the integration. Each entry in the array represents the latest run of a different sync; use `_syncId` on each returned job to correlate back to the sync resource. The response is a bare array, not wrapped in a `data` envelope. via GET /v1/integrations/{_integrationId}/syncJobs/latest

List syncs in an integration -- Returns the syncs that belong to one integration, sorted by name. Equivalent to `GET /v1/syncs?_integrationId={_integrationId}`. via GET /v1/integrations/{_integrationId}/syncs

Preview a template install from an uploaded zip -- Previews the resources that would be created by installing a template from an uploaded zip file. The `runKey` query parameter ties this request to a previously uploaded zip (obtained from `GET /v1/s3SignedURL`). via GET /v1/integrations/template/preview

List all jobs -- Returns jobs matching the given query-parameter filters, up to 1001 per page in descending `createdAt` order. Use `createdAt_lte` on the last record's `createdAt` (minus 1 ms) to page forward. There are two query modes depending on the `type` parameter: - **Parent jobs** (`type` omitted, `flow`, `retry`, or `bulk_retry`) — pass at least one of `_integrationId`, `_flowId`, `_exportId`, `_importId`, `_flowJobId`, `createdAt_gte`, or `createdAt_lte` to scope the query. Omitting all filters returns all jobs in the account. - **Child jobs** (`type=export` or `type=import`) — requires `_flowJobId` or a resource ID filter (`_exportId` / `_importId`). Returns the export/import sub-jobs within a parent flow job. Date filters accept ISO 8601, plain date, or epoch milliseconds. When combining `numError_gte`/`numError_lte` with `_integrationId`, use full ISO 8601 with millis (plain-date format may be rejected). To page forward, take the `createdAt` of the last record, subtract 1 ms, and pass it as `createdAt_lte`. Active jobs (`queued` or `running`) are pinned to the top of the first page even when they fall outside the date filters; `canceling` jobs are not pinned. Account for this when paging — the first page can contain records older filters would otherwise exclude. via GET /v1/jobs

Get a job -- Returns a single job record. Works for both parent jobs (`type=flow`, `retry`, `bulk_retry`) and child jobs (`type=export`, `type=import`). For the full parent+children view of a flow run, use `GET /v1/jobs/{_id}/family` instead. For a multi-job lookup, use `POST /v1/jobs/family`. via GET /v1/jobs/{_id}

Get a signed URL for job diagnostics -- Returns a short-lived S3 pre-signed URL pointing to a diagnostic archive (`.zip`) for the given job. The archive contains server-side traces/logs that Celigo support uses to debug execution failures. The URL is typically valid for ~15 minutes (enforced by S3). Consumers should fetch the archive immediately rather than storing the URL. This is distinct from flow execution logs -- use `GET /v1/flows/{_id}/jobs/{_jobId}/logs` for step-level execution logs. Jobs with no diagnostics (very recent, or past `purgeAt`) return 204. via GET /v1/jobs/{_id}/diagnostics

Get a job and its children -- Returns a single job record (as parent) with all of its child jobs inlined under `children`. A "job family" maps to one flow execution: the parent is a `type: "flow"` job and the children are the `export` / `import` / `retry` jobs that ran as part of it. For non-flow jobs (a standalone export run, or a retry), `children` may be empty. For fetching many families at once, batch via `POST /v1/jobs/family`. The parent's counters may not include bulk-retry jobs spawned after the initial run -- aggregate across `children` for an accurate per-run summary. via GET /v1/jobs/{_id}/family

Get license entitlement usage -- Returns entitlement usage for the current account/license -- how many resources the account is consuming vs. what is entitled. Pair with `GET /v1/licenses` for the entitlement limits. via GET /v1/licenseEntitlementUsage

Get licenses (subscription) -- Returns one account-level license (`type` is `platform`, `integrator`, or `endpoint`) plus zero or more `connector`, `integrationApp`, or `integrationAppChild` licenses. via GET /v1/licenses

List lookup caches -- Returns lookup caches in the account. via GET /v1/lookupcaches

Get a lookup cache -- Returns configuration, metadata, and current size of a lookup cache. This returns metadata only — to read the cached key-value data, use `POST /v1/lookupcaches/{_id}/getData`. via GET /v1/lookupcaches/{_id}

Preview cloning a lookup cache -- Returns resources that would be created by cloning this cache. Lookup caches have no transitive dependencies, so the response contains only the cache itself. No resources are created. Whether the clone includes cached data depends on the source cache's `includeDataInTemplatesAndCloning` setting. via GET /v1/lookupcaches/{_id}/clone/preview

List dependencies of a lookup cache -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. An empty object `{}` means no dependents exist (also returned for a well-formatted but nonexistent id). via GET /v1/lookupcaches/{_id}/dependencies

List MCP OAuth providers -- Returns all MCP OAuth providers in the account. via GET /v1/mcpoauthproviders

Get an MCP OAuth provider -- Returns the full configuration of an MCP OAuth provider. via GET /v1/mcpoauthproviders/{_id}

List MCP servers -- Returns all MCP servers in the account. via GET /v1/mcpservers

Get an MCP server -- Returns the full configuration of an MCP server including tools, APIs, prompts, resources, and OAuth settings. via GET /v1/mcpservers/{_id}

List dependencies of an MCP server -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` when no dependents exist, including for well-formatted but nonexistent IDs. via GET /v1/mcpservers/{_id}/dependencies

Get effective end-user access for an MCP server -- Server-scoped reverse lookup: finds every end user who can reach this MCP server and compiles each one's effective tool access with source attribution — the union of direct grants, group grants, role grants, and permission sets. The result is recomputed on every request rather than cached. Requires account owner or administrator access. The per-user view of the same compilation is `GET /v1/endusers/{_ashareId}/effective-access` (End Users API). via GET /v1/mcpservers/{_id}/effective-access

List record types for a NetSuite connection -- Returns an array of all record types available via SuiteScript for the given NetSuite connection. The response typically contains ~539 record type descriptors. Pass `?refreshCache=true` to bypass the server-side cache and fetch fresh metadata from NetSuite. via GET /v1/netsuite/metadata/suitescript/connections/{_id}/recordTypes

List fields for a NetSuite record type -- Returns an array of field descriptors for the specified record type on the given NetSuite connection. Fields are grouped by category (e.g. `Body Field`) and include their data types. via GET /v1/netsuite/metadata/suitescript/connections/{_id}/recordTypes/{recordType}

List sublists for a NetSuite record type -- Returns an array of sublists (line-item groups) available on the specified record type for the given NetSuite connection. via GET /v1/netsuite/metadata/suitescript/connections/{_id}/recordTypes/{recordType}/sublists

List saved searches for a NetSuite connection -- Returns an array of saved searches available on the given NetSuite connection. The `recordType` query parameter is accepted but silently ignored by the server -- all saved searches are returned regardless. via GET /v1/netsuite/metadata/suitescript/connections/{_id}/savedSearches

List notification subscriptions -- Returns notification subscriptions for flows, connections, integrations, and syncs in the account. Without the `users=all` query parameter, the response is scoped to the caller's own subscriptions. With `users=all`, every user's subscriptions in the account are returned. Returns an empty response when the caller has no subscriptions in the current scope. With `users=all`, an empty array is returned only in accounts with zero subscriptions across all users. via GET /v1/notifications

Get current user preferences -- Returns UI and account/environment preferences for the currently-authenticated user. Examples include: - date/time display formatting (`dateFormat`, `timeFormat`) - current environment selection (`environment`) - UI layout preferences (dashboard/pagination/drawer settings) via GET /v1/preferences

List available flow processor types -- Returns the catalog of processor types the flow engine supports — filter, transform, handlebars, javascript, mapper, CSV/XML parser / generator, branch filter, merge, etc. Each entry carries a label, description, and the input/output media types the processor accepts. The response is keyed by processor name (not an array). via GET /v1/processors

List published Integration Apps (Connectors) -- Returns the marketplace catalog of **Integration Apps** — the Celigo-built, fully-managed connectors that install as a single integration. Roughly 30 entries curated by Celigo. Each item is a marketplace listing, not an integration instance — `_id` is the marketplace entry id, the `applications` array enumerates the systems the connector bridges, and `numInstalls` is the live install counter across all Celigo accounts. For a combined list that also includes user-installable Templates, use `POST /v1/published/combined` instead. Entries here have no `docType` field -- that discriminator only appears in the combined endpoint's response. via GET /v1/published

List deleted resources -- Returns all resources deleted within the last 30 days, across all resource types. Files and folders deleted from Celigo Storage are included as `StorageItem` entries. Sorted by `lastModified` descending. Not paginated — the full result set is returned in a single response. via GET /v1/recycleBinTTL

List deleted resources by type -- Returns deleted resources of a specific type from the recycle bin (last 30 days). Sort order is not guaranteed. Not paginated — the full result set is returned in a single response. `storageitems` behaves differently: the request is proxied to Celigo Storage, which returns an object wrapping an `items` array (not a bare array), sorted by newest deletion first and paginated via the `Link` response header. via GET /v1/recycleBinTTL/{_resourceType}

Get a deleted resource -- Returns the full document of a specific deleted resource from the recycle bin. May include fields that the list endpoints omit (e.g. `content` on scripts, `queues` on connections). Not supported for `storageitems` — deleted storage item documents are available only from the list endpoints. via GET /v1/recycleBinTTL/{_resourceType}/{_id}

List roles -- Returns all active roles in the account. Requires account owner or administrator access. via GET /v1/roles

Get a role -- Retrieves a single role by ID. via GET /v1/roles/{_id}

List sObject types for a Salesforce connection -- Returns an array of all sObject type descriptors available on the given Salesforce connection. This is the Salesforce describe-global response, typically containing ~1058 sObject types. via GET /v1/salesforce/metadata/connections/{_id}/sObjectTypes

Get sObject type detail for a Salesforce connection -- Returns the full Salesforce sObject describe response for the specified sObject type on the given connection. This is a large payload that includes all fields, child relationships, record type info, URLs, and other metadata. via GET /v1/salesforce/metadata/connections/{_id}/sObjectTypes/{sObjectType}

List scripts -- Returns all scripts in the account. Response omits `content` to reduce payload size. via GET /v1/scripts

Get a script -- Returns a single script by ID, including the full `content` field. via GET /v1/scripts/{_id}

Get audit log for a script -- Returns the change history for a script. Each entry records a mutation event with who made the change, when, and which fields were affected. via GET /v1/scripts/{_id}/audit

List dependencies of a script -- Returns the set of resources that depend on the specified script. via GET /v1/scripts/{_id}/dependencies

Get debug logs for a script -- Returns console output captured while debug is enabled on the script (`debugUntil` set to a future timestamp). via GET /v1/scripts/{_id}/logs

List accounts shared with you -- Returns every account that other users have shared with the current user. This is the inverse of `GET /v1/ashares`, which lists users who have access to *your* account. via GET /v1/shared/ashares

List stack share invitations -- Returns stack-share records for the current user, including share status, the user who shared, and a stack summary. To list usable stacks directly, use `GET /v1/shared/stacks`. via GET /v1/shared/sshares

List available stacks -- Returns every stack the current account can use — both owned and accepted shared stacks. For share metadata (who shared, acceptance status), use `GET /v1/shared/sshares`. via GET /v1/shared/stacks

List stacks -- Returns all stacks configured in the account. via GET /v1/stacks

Get a stack -- Returns a single stack by ID. via GET /v1/stacks/{_id}

Get audit log for a stack -- Returns the change history for a stack. Each entry records a mutation event with who made the change, when, and which fields were affected. via GET /v1/stacks/{_id}/audit

List dependencies of a stack -- Returns the set of resources that depend on the specified stack. via GET /v1/stacks/{_id}/dependencies

Get stack system token (server stacks only) -- Returns the unmasked system token for a server stack. via GET /v1/stacks/{_id}/systemToken

List global state keys -- Returns all global state key names. Does not return resource-scoped keys — use `GET /v1/{resourceType}/{_id}/state` for those. Lists key names only, not values. Call `GET /v1/state/{key}` to retrieve a specific value. via GET /v1/state

Get a global state value -- Returns the JSON value stored under the given global key. Returns the raw JSON value (object or array), not wrapped in an envelope. via GET /v1/state/{key}

Get a file download URL -- Returns a short-lived presigned S3 URL for downloading a file's content, along with how many seconds it stays valid. Fetch the bytes directly from that URL — the content does not pass through this API. Files only; folders have no content to download. via GET /v1/storage/files/{_id}/download

List or search items -- Browse or search Celigo Storage. In list mode (no `search`), returns the direct children of a folder — omit `_parentId` for the account root — and includes a `breadcrumb` of the path to that folder. In search mode (with `search`), recursively matches item names across the whole account and returns each hit's `location`. Results are paginated with the `Link` response header. via GET /v1/storage/items

List dependencies of an item -- Returns the resources that reference this item — flows, exports, imports, MCP servers, and access tokens. These references are soft: they never block a delete or move, and go dangling if the item is removed. Check this before deleting or moving an item to see what may break. via GET /v1/storage/items/{_id}/dependencies

List recycle-bin items -- Lists the items currently in the recycle bin, newest deletion first. Only items deleted directly are listed — descendants removed as part of a folder deletion are hidden, since they are restored or purged with their parent. Each item carries `deletedAt` and `deletedBy`. Restore an item with `POST /v1/storage/items/{_id}/restore` or remove it for good with `DELETE /v1/storage/items/{_id}/purge`. via GET /v1/storage/items/recycleBinTTL

Get storage usage -- Returns account-wide storage usage and entitlement, aggregated across all environments: bytes in use (active and recycle bin), the licensed quota, the hard limit at which uploads are blocked, and whether the account is in overage. via GET /v1/storage/usage

Get storage usage by environment -- Returns the same account-wide totals as `GET /v1/storage/usage`, broken down per environment. Use it to see which environment is consuming the account's shared quota. via GET /v1/storage/usage/environments

Get audit log for an item -- Returns the change history for a storage item — creation, renames and description edits, moves, content replacements, downloads, deletes, restores, and purges — newest first. Each entry records who made the change, when, and which fields were affected. via GET /v1/storageitems/{_id}/audit

List errors for a sync job -- Returns an array of error records for the given parent sync job. Errors are produced during extraction or loading and are scoped to individual tables. The response includes an `x-total-count` header with the total number of errors (useful when filtering by child job). Use the `_childJobId` query parameter to filter errors to a single table's child job. Without it, errors across all tables in the run are returned. To find a child job id, call `GET /v1/syncJobs/{_syncJobId}/family` and read `tables[]._id`. Each error also carries a `tableName` field for client-side grouping. The response is a bare array, not wrapped in a `data` envelope. via GET /v1/syncJobs/{_parentJobId}/errors

Get a sync job -- Returns a single sync job record. Sync jobs are read-only records created by the platform when a sync run is triggered. The record includes status, timing, record counts, and error counts. A gap between `numExtractedRecords` and `numLoadedRecords` indicates records that failed during loading -- see `numErrors`. via GET /v1/syncJobs/{_syncJobId}

Get a sync job and its table-level children -- Returns the parent sync job with all of its per-table child jobs inlined under a `tables` array. Each table entry contains its own status, record counts, error counts, and timing. A sync job family maps to one sync execution: the parent is the overall sync job and the children represent each table that was synced as part of that run. Parent-level counters are the authoritative totals; `tables[]` provides the per-table breakdown. `tables` may be empty if the job was canceled before any table work started. via GET /v1/syncJobs/{_syncJobId}/family

List syncs -- Returns all syncs in the account, sorted by name. Filter to one integration with the `_integrationId` query parameter (equivalent to `GET /v1/integrations/{_integrationId}/syncs`). via GET /v1/syncs

Get a sync -- Returns a single sync by ID. via GET /v1/syncs/{_id}

Get audit log for a sync -- Returns the change history for a sync. Entries cover the sync itself **and** the related resources it depends on — its datasets (the tables being replicated) and the source and destination connections it uses — so a single response interleaves `sync`, `dataset`, and `connection` events. Read `resourceType` on each entry to tell them apart. via GET /v1/syncs/{_syncId}/audit

List datasets for a sync -- Returns the datasets configured on a sync — the tables/objects it replicates — sorted by name. Export-backed datasets whose export no longer uses the sync's source connection carry `mismatchSyncConnection: true`. via GET /v1/syncs/{_syncId}/datasets

Get a dataset -- Returns a single dataset of a sync by ID. via GET /v1/syncs/{_syncId}/datasets/{_id}

List sync jobs for a sync -- Returns all sync job records for the given sync, ordered by creation time (most recent first). The response wraps the array in a `data` field alongside a `totalCount`. Note: although the response shape suggests pagination (`totalCount`), the `limit`, `offset`, and `status` query parameters are silently ignored by the server as of this writing. The endpoint always returns the complete list of jobs. via GET /v1/syncs/{_syncId}/syncJobs

Get per-sync usage for the current month -- Returns the number of records each sync loaded during the current calendar month (UTC), for the current environment. Only syncs that ran this month appear. Requires account-administration permission (the same level that manages account users); accounts without a Data Ingestion entitlement get an empty `usage` array. via GET /v1/syncs/usage

Get sync usage by environment -- Returns the records loaded by syncs during the current calendar month (UTC), broken down by environment — production plus every additional environment in the account. Environments with no runs this month report a volume of 0. Requires account-administration permission (the same level that manages account users); accounts without a Data Ingestion entitlement get an empty `usage` array. via GET /v1/syncs/usage/environments

Get monthly sync usage history -- Returns account-wide sync usage by calendar month, newest first — the records loaded across all syncs and environments, alongside the account's Data Ingestion entitlement for each month. History reaches back at most 14 months. Requires account-administration permission (the same level that manages account users); accounts without a Data Ingestion entitlement get an empty array. via GET /v1/syncs/usage/summary

List the account's tag catalog -- Returns every tag defined in the account, each with its short `tagId` code and human-readable `tag` name. This is the catalog that backs the tag-picker on flow-step errors (`PUT /v1/flows/{_id}/{_stepId}/tags`). The `tagId` field is the short code used as a write-side input on flow-step tag mutations (`PUT /v1/flows/{_id}/{_stepId}/tags` accepts `tagIds: ["NjMMA", ...]`), while the human name is stored on the error record as `tags: ["Ignore", ...]`. via GET /v1/tags

Get a tag -- Returns a single tag entry by its `_id`. via GET /v1/tags/{_id}

List templates -- Returns all templates owned by the authenticated Partner account. The response is a flat JSON array with no pagination. via GET /v1/templates

Get a template -- Returns a single template by ID. via GET /v1/templates/{_id}

Preview a template's installed resource docs -- Returns the concrete resource documents a template would create if installed. The response is an envelope `{objects, stackRequired}` where `objects` is an array of `{model, doc}` entries — one per resource that the install step would materialize. `stackRequired` is `true` when the template includes NetSuite-distributed resources that need a dedicated stack — the installer prompts for one before the install proceeds. The ID must belong to a Template, not a Connector (Integration App). Connector IDs from `/v1/published` return 404 here -- pull template IDs from the `Template`-typed entries of `POST /v1/published/combined`. via GET /v1/templates/{_id}/preview

Identify the current token's owner -- Resolves a bearer token to the user it authenticates as. via GET /v1/tokenInfo

List tools -- Returns all tools in the account. Filter by `_integrationId` to scope results to a single integration. via GET /v1/tools

Get a tool -- Returns the complete configuration of a specific tool. via GET /v1/tools/{_id}

List captured debug requests for a tool step -- Lists the debug request records captured for a specific step of a tool. These are the raw outbound requests the step issued, retained for troubleshooting. Use the `key` of an entry with `GET /v1/tools/{_id}/{_stepId}/requests/{key}` to fetch the full detail of a single captured request. Returns `{requests: []}` when the step has captured no debug requests. via GET /v1/tools/{_id}/{_stepId}/requests

Get a captured debug request for a tool step -- Returns the full detail of a single captured debug request for a tool step, identified by its `key`. Obtain the `key` from `GET /v1/tools/{_id}/{_stepId}/requests`. via GET /v1/tools/{_id}/{_stepId}/requests/{key}

Preview cloning a tool -- Returns a preview of the resources that would be created by cloning this tool. No resources are created. Call this before `POST /v1/tools/{_id}/clone` to inspect what the clone would create. via GET /v1/tools/{_id}/clone/preview

List connections a tool depends on -- Returns the full Connection resources the tool references — both directly (via `_connectionId` fields on its steps) and transitively through descendant resources (inner tools, lookups, imports, exports). Useful for discovering what systems a tool talks to before cloning, moving, or evaluating the blast radius of a connection change. For the full dependency tree (imports, exports, nested tools), use `GET /v1/tools/{_id}/descendants` instead. via GET /v1/tools/{_id}/connections

List dependencies of a tool -- Returns the set of resources that depend on the specified resource. The response is an object whose keys are dependent-resource types (e.g. `flows`, `imports`) and whose values are arrays of dependency entries. Returns `{}` for both zero-dependency and nonexistent IDs. via GET /v1/tools/{_id}/dependencies

List resources a tool depends on, grouped by type -- Returns the full dependency tree of a tool as three arrays: the `imports`, `exports`, and nested `tools` it references directly or transitively. Each entry is the complete resource document, so the caller doesn't need to fan out individual GETs. Pair with `GET /v1/tools/{_id}/connections` to enumerate the full resource and connection footprint in two calls. via GET /v1/tools/{_id}/descendants

Get a downloadable template for a tool -- Packages the tool as an installable template and returns a signed S3 URL where the template `.zip` can be downloaded. The URL is pre-signed and short-lived (approximately 15 minutes), so fetch the file promptly; call the endpoint again for a fresh URL. The `.zip` contains the tool definition plus every resource it references — nested tools, exports, imports, connections, and scripts — grouped into one folder per resource type, with an `integration.json` manifest at the root. Requires the `create:tool:template` permission. via GET /v1/tools/{_id}/template

Get a tool test-run step result -- Returns the stage-by-stage result of a single step from a prior tool test run. Each entry in `stages[]` describes one stage (e.g. `request`, `parse`, `router`, `input`) with its `input`, `output`, and any `errors`. The `runId` is the `flowJob._id` returned by `POST /v1/tools/{_id}/test/run`. The `{_stepId}` is one of the step ids found in that run's `metadata` map. Test-run history is separate from normal run history and is short-lived — fetch step results soon after the run completes. via GET /v1/tools/{_id}/test/run/{runId}/{_stepId}

Get request/response logs for a tool test-run step -- Returns the outbound HTTP request/response log pairs captured during a specific step of a tool test run. Only steps that issued outbound HTTP calls (exports, imports, lookups) produce entries — routers, filters, and other in-process stages return `404` with code `req_res_logs_not_found` by design. The `runId` is the `flowJob._id` returned by `POST /v1/tools/{_id}/test/run`; the `{_stepId}` is the export or import id of the step you want logs for, found in the test-run `metadata` map. Response entries may carry base64-encoded JSON in `request.body` and `response.body` — decode string bodies before parsing. Test runs are short-lived ephemeral state, so capture logs soon after the run completes. via GET /v1/tools/{_id}/test/run/{runId}/{_stepId}/logs/requestAndResponse

List trading partner connectors -- Returns all trading partner connectors visible to the caller. Published connectors are visible to everyone; unpublished connectors are visible only to their owner. The list response is a summary shape — it includes `_id`, `name`, `_userId`, `helpURL`, timestamps, and the categorization fields (`type`, `region`, `model`, `baseName`) when set, but omits `published` and `supportedBy`. Use GET by ID to retrieve the full configuration. via GET /v1/tpconnectors

Get a trading partner connector -- Returns the complete configuration of a trading partner connector, including all `supportedBy` sections. Unpublished connectors are only visible to their owner. The list endpoint returns a summary that omits `published` and `supportedBy`. via GET /v1/tpconnectors/{_id}

Get usage records (legacy) -- Returns historical usage records for the current account (legacy usage series). The response is an array of monthly records with a duration field (`milliseconds`). via GET /v1/usage

Patch an API -- Partially updates an API using a JSON Patch document (RFC 6902). The `replace` operation is supported on the following whitelisted paths (`/logging/debugUntil` also accepts `remove`, which clears an active debug window early): | Path | Description | |------|-------------| | `/name` | API display name | | `/description` | API description | | `/disabled` | Enable or disable the API (boolean) | | `/timeoutPeriod` | Request-timeout override in seconds | | `/pagination/enabled` | Enable or disable the cursor-pagination envelope (boolean) | | `/logging/mode` | Logging level for requests handled by this API | | `/logging/debugUntil` | End of a temporary full-debug capture window | | `/traceKeyTemplate` | Handlebars template that computes each request's trace key | All other paths are rejected with `422`. This is the only way to change `logging` -- PUT silently ignores that field. Logging changes are validated against account entitlements: setting `/logging/mode` to a payload-capturing mode (`standard`, `detailed`) fails with `422` (code `payload_storage_required`) when the account does not have payload storage enabled, and `/logging/debugUntil` has the same payload-storage requirement. Accounts whose license does not include logging, or whose license caps the maximum logging mode below the requested one, are also rejected with `422`. via PATCH /v1/apis/{_id}

Patch a connection -- Partially updates a connection using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted paths: | Path | Description | |------|-------------| | `/name` | Connection display name | | `/debugDate` | Debug logging expiry (ISO-8601, max 1 hour from now) | | `/debugUntil` | Alias for `/debugDate` | All other paths are rejected with `422`. via PATCH /v1/connections/{_id}

Update part of an EDI transaction -- Partially updates one or more EDI transaction records. Commonly used to update the `faStatus` field (functional acknowledgment status). The endpoint is lenient — when the `ediTransactions` array is empty, missing, or contains IDs that don't match any existing records, the response is `200` with `{"ediTransactions": []}` rather than a 400. Callers should always supply `fileType` and a non-empty `ediTransactions` array for meaningful results. via PATCH /v1/ediTransactions

Patch an export -- Partially updates an export using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted paths: | Path | Description | |------|-------------| | `/debugUntil` | Debug logging expiry (ISO-8601, max 1 hour from now) | | `/assistantMetadata` | Assistant metadata object | All other paths are rejected with `422`. via PATCH /v1/exports/{_id}

Patch a flow -- Partially updates a flow using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted paths: | Path | Description | |------|-------------| | `/name` | Flow display name | | `/description` | Flow description | | `/disabled` | Enable or disable the flow | | `/logging/debugUntil` | Debug logging expiry (ISO-8601; the maximum window is license-dependent — 72 hours on standard licenses, 422 beyond the cap) | | `/logging/mode` | Logging mode | | `/runPageGeneratorsInParallel` | Run page generators in parallel | | `/aiDescription` | AI-generated description object | | `/schedule/frequency` | Schedule frequency | | `/schedule/startDate` | Schedule start date | | `/schedule/endDate` | Schedule end date | | `/schedule/days` | Schedule days | | `/schedule/cron` | Cron expression | All other paths are rejected with 422. PATCH is safer than PUT for toggling `disabled` or arming debug logging because it won't accidentally reset other fields. To arm debug logging, `replace` `/logging/debugUntil` with a future ISO timestamp (up to your license's cap — 72 hours on standard licenses); to disarm, set it to a past timestamp or null. via PATCH /v1/flows/{_id}

Patch an iClient -- Partially updates an iClient using JSON Patch (RFC 6902). Only `/oauth2/failPath` is patchable; use PUT for other field changes. via PATCH /v1/iclients/{_id}

Patch an import -- Partially updates an import using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted path: | Path | Description | |------|-------------| | `/debugUntil` | Debug logging expiry (ISO-8601, max 1 hour from now) | All other paths are rejected with `422`. via PATCH /v1/imports/{_id}

Patch an integration -- Partially updates an integration using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted paths: | Path | Description | |------|-------------| | `/settings` | Integration settings object | | `/flowGroupings` | Flow grouping configuration | | `/apiGroupings` | API grouping configuration | All other paths are rejected with `422`. via PATCH /v1/integrations/{_id}

Patch a lookup cache -- Partially updates a lookup cache using a JSON Patch document (RFC 6902). Only `replace` is supported, on these paths: | Path | Description | |------|-------------| | `/name` | Cache display name | | `/description` | Cache description | All other paths or operations are rejected. via PATCH /v1/lookupcaches/{_id}

Patch an MCP server -- Partially updates an MCP server using a JSON Patch document (RFC 6902). Only `/name` and `/disabled` are whitelisted paths — all other paths are rejected with `not a whitelisted property`. via PATCH /v1/mcpservers/{_id}

Patch a script -- Partially updates a script using JSON Patch (RFC 6902). Only `/debugUntil` is a supported path — all others are rejected with 422. Supported operations: `replace`, `add`, `remove`. The value must be an ISO-8601 timestamp no more than 1 hour in the future. via PATCH /v1/scripts/{_id}

Move an item -- Moves a file or folder to a different folder. Metadata only — the content stays in place, the item's `_id` is unchanged so references survive, and quota is unaffected. Moving a folder re-parents the folder immediately and re-anchors its descendants asynchronously, so the response reflects only the moved item itself. A folder cannot be moved into itself or one of its own descendants. via PATCH /v1/storage/items/{_id}/move

Replace file content -- Overwrites an existing file's content in place. Returns presigned upload URLs in the same shape as one initiate-upload file entry; transfer the new bytes to them just as for a new upload. The item's `_id`, name, and folder placement are preserved, so every reference to the file stays intact — use this instead of delete-and-recreate when a file is referenced by flows or exports. The previous content remains downloadable until the replacement finalizes. Rename with `PUT /v1/storage/items/{_id}` instead; this endpoint does not accept a name. via PATCH /v1/storage/items/{_id}/replace

Patch a tag -- Partially updates a tag using a JSON Patch document (RFC 6902). Only the `replace` operation is supported, and only on the following whitelisted path: | Path | Description | |------|-------------| | `/tag` | The human-readable tag name | All other paths are rejected with `422`. via PATCH /v1/tags/{_id}

Create an on-premise agent -- Creates a new on-premise agent. Only `name` is required. The response includes the agent record but not the access token — call `GET /v1/agents/{_id}/display-token` to retrieve the token needed for the agent installer. via POST /v1/agents

Publish OpenAPI spec to APIM API -- Publishes an OpenAPI specification to an existing APIM API. When a signed URL is not required for the resource type, the server generates the OpenAPI document from the resource. The resource must already be published to the given `apiId` (400 if not). Upstream API management errors may be returned with the upstream HTTP status. via POST /v1/apim/{apiId}/{modelPlural}/{_id}/openAPIspec

Publish resource to new APIM API -- Publishes an integrator.io resource to APIM as a new API. Requires `apim:operations` permission and an enabled APIM license. Custom webhooks (non-integrator-extension) are rejected with 400. Upstream API management errors may be returned with the upstream HTTP status. via POST /v1/apim/{modelPlural}/{_id}/manageAPI

Set up APIM account -- Provisions APIM for the account with a subdomain and service account email. Processing is asynchronous and returns `202 Accepted` with an empty body. Production environment only. Requires `apim:operations` permission. via POST /v1/apim/setup

Create an API -- Creates a new API. For `script` mode, include `script._scriptId` and `script.function` (the server also copies these to the top level in the response). For `builder` mode, `builder.request` is required (at minimum `relativeURI` and `method`). Builder-mode APIs are created with `logging: {"mode": "basic"}` when the account license has logging enabled -- the request body cannot override this (`logging` is ignored on POST and PUT; change it afterwards with `PATCH /v1/apis/{_id}`). via POST /v1/apis

Clone an API -- Clones a builder-mode API along with the resources it depends on (such as its backing import) and returns a manifest of every resource created. The request body is required: `version` must be supplied, and the cloned API's combination of `version`, `method`, and `relativeURI` must be unique. Reusing all three returns a 422 `clone_api_already_exists`. Pass `_integrationId` to create the clone inside an integration — when omitted, the clone is created standalone rather than inheriting the source API's integration. Only **builder-type** APIs can be cloned — cloning any other API type returns a 400 `clone_not_supported`. To check for a version/method/relativeURI conflict without creating anything, call `POST /v1/apis/{_id}/clone/validate` first. via POST /v1/apis/{_id}/clone

Validate an API clone -- Dry-run check for `POST /v1/apis/{_id}/clone`. Verifies that cloning the API to the target `version` would not collide with an existing API route — the clone keeps the source API's `method` and `relativeURI`, so the target `version` + `method` + `relativeURI` combination must not conflict with an API that is already registered in the account. Nothing is created or modified. Returns `canClone: true` when the route is free, `false` when it conflicts — pick a different `version` before calling `POST /v1/apis/{_id}/clone`. Only **builder-type** APIs can be validated; a script-type API returns 404, the same as an unknown id. via POST /v1/apis/{_id}/clone/validate

Query decoded log data for an API trace step -- Returns the decoded request/response payload and error metadata for a record/stage within an API request execution, identified by `_expOrImpId`, `stage`, `groupId`, and `recordId`. If the log content exceeds inline limits or is stored externally, an `externalReference` with an S3 key (and optional byte range) is returned — download it via the signed-URL endpoint. The response may be gzip-compressed. via POST /v1/apis/{_id}/requests/{executionId}/logs/data/query

Test-run an API -- Executes the API once in a sandboxed test harness without invoking its public endpoint, and returns the job tree produced by the run. Use this to validate a builder-mode API's request parsing, routing, and response mapping before exposing it externally. The response carries a `metadata` map keyed by step id (each value is the ordered list of stage names that ran for that step), the parent `flowJob`, and the per-step `childJobs[]`. Inspect a specific step's stages with `GET /v1/apis/{_id}/test/run/{runId}/{_stepId}`, where `runId` is the parent `flowJob._id`. Test-run invocations do **not** surface in `GET /v1/apis/{_id}/logs`. via POST /v1/apis/{_id}/test/run

Create an async helper -- Creates a new async helper resource. The referenced `http.status._exportId` must be an existing export resource. If `http.submit.sameAsStatus` is `false`, also set `http.submit.resourcePath` to extract the async job identifier. via POST /v1/asynchelpers

Query audit logs with multi-select filters -- The POST variant of the account-wide audit query, for filters the GET query string cannot express: each body filter is an array that matches entries with any of the listed values, and `resourceName` scopes results to an explicit list of resources. Response shape and ordering are identical to `GET /v1/audit`. Pagination, sorting, and time bounds stay in the query string — sending them in the body fails with 400 `invalid_request_body`. via POST /v1/audit

Get signed URL for audit CSV with multi-select filters -- The POST variant of the CSV signed-URL download, accepting the same multi-select filter body as `POST /v1/audit`. The response is identical to the GET variant: a signed URL valid for ~15 minutes plus `hasMore` for batching. Sorting and time bounds stay in the query string — sending `from`/`to` or pagination keys in the body fails with 400. via POST /v1/audit/signedURL

Get signed URL to download audit logs CSV (for selected resources) -- Generates a signed URL for downloading a CSV export of audit logs for specific resources and their descendants. The signed URL expires after 15 minutes. When `hasMore` is true, pass the last CSV row's timestamp as `to` in the request body to fetch the next batch. via POST /v1/{resourceType}/audit/signedURL

Query a resource's audit log with multi-select filters -- The POST variant of the resource-and-descendants audit query, accepting the same multi-select filter body as `POST /v1/audit`. Body filters apply within the resource's descendant set — e.g. filter an integration's audit trail to specific actions or sources. Response shape matches the GET variant. Pagination, sorting, and time bounds stay in the query string — sending them in the body fails with 400 `invalid_request_body`. via POST /v1/{resourceType}/{_id}/audit

Create a connection -- Creates a new connection configuration that can be used to authenticate and connect to external systems and applications. To also register the new connection on one or more integrations in the same call, pass their ids in `__integrationIds`. Invalid lists reject the whole request (see the `400`, `404`, and `422` responses); failures during the post-save registration itself do not roll back the new connection and are reported in `__failedIntegrationRegistrations` on the `201` response. via POST /v1/connections

Ping an existing connection -- Runs the adaptor's ping routine against a saved connection to verify its credentials and network configuration still work; no data is read, written, or modified. The check is adaptor-specific (HTTP runs the ping relativeURI or baseURI, RDBMS/JDBC open a driver session, MCP issues a tools/list, NetSuite/Salesforce do a token or session validation). The request body is optional and ignored. Inspect the response body, not the HTTP status, to determine the outcome: success and adaptor-level failures both return HTTP 200 — success is `{code: 200}`, failures are `{errors: [...]}`. The only non-success status is 404, when `_id` does not resolve to a connection. For a not-yet-saved connection, use `POST /v1/connections/ping` instead. via POST /v1/connections/{_id}/ping

Purge the message queue for a connection -- Purges all messages from the connection's message queue. This is a rate-limited operation — repeated calls within approximately 20 seconds are throttled. Returns an empty response on success. If the queue is already empty, the request fails with an `empty_connection_queue` error. via POST /v1/connections/{_id}/purgeMessages

Create a connector -- Creates a new connector (Integration App). **Partner-only endpoint.** via POST /v1/connectors

Install a connector (Integration App) -- Triggers the install flow for a connector (Integration App). The connector must be associated with an integration that has the install function configured. Templates are installed via `POST /v1/integrations/template/{_id}` instead. via POST /v1/connectors/{_id}/install

Create a license for a connector -- Creates a new license for a connector. Supply the target user's email address in the request body — the backend resolves it to a user account. If the email is not a registered integrator.io user, an `invalid_user` error is returned. **Partner-only endpoint.** via POST /v1/connectors/{_id}/licenses

Create an EDI profile -- Creates a new EDI profile for EDI X12 or EDIFACT document exchange. `fileType` is immutable after creation. Only `name` and `fileType` are required; all ISA/GS/UNB control fields default to safe values. via POST /v1/ediprofiles

Query the EDI transaction log -- Returns EDI documents processed through B2B Manager flows, with envelope metadata (sender/receiver IDs, control numbers), document type, direction, and functional acknowledgement status. This is the data source behind the B2B Manager "Transactions" dashboard. Results are cursor-paginated — when more records exist beyond `limit`, the response includes `pageToken.next`. Pass it back as `pageToken` in the next request to get the next page. The server caps `limit` at 1000. Use `fileType` with a dated window (`startDate`/`endDate`) to keep result sets bounded. `faStatus` must be passed as an array when filtering. Unknown filter fields are silently ignored. To fetch the raw EDI file for a returned record, use `POST /v1/jobs/{_flowJobId}/files/signedURL` with the record's `s3Key`. via POST /v1/ediTransactions/query

Invite an end user -- Finds or creates the user by email, creates an end-user access record, applies the requested group memberships and direct grants, and sends an invite email. Account owners cannot be invited as end users. Requires account owner or administrator access. via POST /v1/endusers/invite

Invite end users in bulk -- Invites 1–100 end users in one request, applying the same optional `groupIds` and `directGrants` to every invite. Processing is sequential and partial-success: a failed item never aborts the batch, so the response is HTTP 200 with a per-email result even when some items fail. Only top-level structural errors (missing or non-array `emails`, more than 100 emails, non-array `groupIds`/`directGrants`) return 400. Requires account owner or administrator access. via POST /v1/endusers/invite/bulk

Create an environment -- Creates a new environment. The environment starts disabled; use the toggle endpoint to enable it. `name` is the only required field and must be unique within the account. via POST /v1/environments

Create an event report -- Queues generation of a new event report for the specified flows and time window. The report is created in `queued` status and transitions through `running` to `completed` (or `canceled`). `startTime` must be within the last 30 days and the span to `endTime` must not exceed 3 days. If `endTime` is omitted, the server defaults it to the current time. Poll `GET /v1/eventreports/{_id}` until `status` is `completed`, then download the CSV via `GET /v1/eventreports/{_id}/signedURL`. The create response includes `_requestedByUserId`; subsequent GET responses replace this with the `requestedByUser` object (name + email). via POST /v1/eventreports

Create an export -- Creates a new export configuration that can be used to retrieve data from applications or external sources. via POST /v1/exports

Clone an export -- Creates a copy of an existing export. Supports optionally remapping referenced connections (via connectionMap). via POST /v1/exports/{_id}/clone

Invoke an export and return its data -- Runs an existing export end-to-end and returns the fetched data (or errors) synchronously. Unlike `POST /v1/flows/{_id}/run`, which starts a full flow job, this endpoint invokes a **single export** in isolation and returns the raw result directly in the response body. The request body is optional — pass `{}` or omit the body entirely for exports that require no input. Some adaptor types accept a `data` array in the body to supply input records. On success, the response contains the export's fetched data. On application-level failure (e.g. the source system is unreachable), the endpoint still returns a successful HTTP status with the errors in an `errors` array — higher-level error codes are reserved for request-level validation (bad ID, missing auth). This endpoint executes the export against the live source system. `POST /v1/exports/preview` also queries the live source (reads only, no job) — prefer it when you only need to inspect fetched records. via POST /v1/exports/{_id}/invoke

Preview the output of an export doc (no job created) -- Runs an export doc through the flow engine's preview pipeline and returns the sample data it would have emitted, along with stage-by-stage diagnostics and any errors encountered. **No Job record is created** and no flow-level state is updated — this is a stateless preview. Body is a complete export document (the shape you would POST to `/v1/exports`), typically without `_id`. The CLI uses it for two scenarios: - `ora exports invoke` with a doc on stdin → ad-hoc preview of a not-yet-saved export. - Agent-driven "preview + refine" loops where an LLM iterates on the export config and calls this endpoint to sample output each time. The scoped variant at `POST /v1/integrations/{_integrationId}/flows/{_flowId}/exports/preview` does the same thing but inherits flow + integration context (useful when the export references flow-scoped settings). Prefer the unscoped variant when previewing a standalone export. Use `test.limit` inside the body to cap the number of records returned. Configuration errors in the export doc surface in the `errors[]` and `stages[].errors[]` arrays within a 200 response; only structural validation failures (e.g. missing `_connectionId`) return 4xx. via POST /v1/exports/preview

Create a file definition -- Creates a new file definition. via POST /v1/filedefinitions

Create a flow -- Creates a new flow. Flows are created enabled (`disabled: false`) by default — set `disabled: true` on create if the flow is not ready to run. At minimum, provide `name` and `_integrationId`. Do not leave the flow enabled with a `schedule` unless it is fully configured — it will start executing on schedule. For abstract/instance patterns, create the abstract flow first, then create instances with `_abstractFlowId`. When `_integrationId` is omitted, the flow is auto-assigned to the account's "Standalone flows" integration rather than left standalone. If that migration integration does not exist on the account, the request fails with `422 standalone_flows_not_supported`. Always pass an explicit `_integrationId`. via POST /v1/flows

Retry errored records -- Re-runs the per-record data snapshots captured when the listed errors occurred. A successful retry auto-resolves the underlying open-error record. A retry that fails again stays open (and may accumulate error history, depending on the adaptor). Only errors that carry a `retryDataKey` can be retried — typically these are record-level errors from imports or transforms. Connection-level errors (`classification: connection`) don't have a `retryDataKey`; to recover from those, re-run the whole flow after fixing the connection. **Response behavior splits on whether anything matched:** - At least one record matched — a supplied `retryDataKey`, or (in `selectAll` mode) a retriable open error on or before `lastErrorAt` → **200** with a `type: "retry"` Job record (the queued retry job; poll it via `GET /v1/jobs/{_id}`). A successful retry clears the original error from `GET .../errors` and moves it into `/resolved` with `resolvedBy` set to the user who triggered the retry. System-initiated auto-retries set `resolvedBy` to `"auto"` instead. - Nothing matched → **204** silent no-op. There is no per-key validation: the endpoint does not 400 on bogus keys; callers must poll `GET .../errors` to confirm any change. **Retry outcome semantics.** A retry that still fails generates a **new** error record with a new `errorId` (the original one is auto-resolved when the retry ultimately succeeds, or stays open pending next retry). Building a UI on top of this endpoint needs to reconcile the "before" and "after" error lists by `retryDataKey`, not `errorId`. To modify a record before retrying, call `GET .../{ retryDataKey}/data`, mutate the payload, `PUT` it back, then call this endpoint. Retried records go through the same page-processor pipeline as new records with no ordering guarantees. To retry the whole open-error queue without listing keys, send `selectAll: true` with a `lastErrorAt` high-water mark instead of `retryDataKeys` — one call retries every matching error, no matter how many (errors without a `retryDataKey` are skipped). via POST /v1/flows/{_id}/{_stepId}/retry

Retry errored records with exponential back-off -- Re-runs errored record snapshots using an exponential decay (back-off) strategy. Behaves like `POST .../retry` but schedules retries with increasing delays between attempts, reducing load on the target system during transient outages. **Response behavior splits on whether anything matched:** - At least one record matched — a supplied `retryDataKey`, or (in `selectAll` mode) a retriable open error on or before `lastErrorAt` → **200** with a full `type: "retry"` Job record. - Nothing matched → **204** silent no-op. The flow must be enabled (not disabled). Prefer this over `POST .../retry` when errors are caused by rate-limiting or transient target-system issues. Only errors with a `retryDataKey` can be retried — connection-level errors lack one and require a full flow rerun to recover. To retry the whole open-error queue without listing keys, send `selectAll: true` with a `lastErrorAt` high-water mark instead of `retryDataKeys`. via POST /v1/flows/{_id}/{_stepId}/retry_with_exponential_decay

Clone a flow -- Creates a copy of a flow along with all transitive dependencies (exports, imports, scripts). `_integrationId` is required, and `connectionMap` is required when the flow references connections — map a connection id to itself to reuse it, or to a different id to remap. Use `GET /v1/flows/{_id}/clone/preview` first to see what resources will be created and which connections need remapping. The cloned flow is always created `disabled: true`. via POST /v1/flows/{_id}/clone

Get per-stage execution log data for a record -- Returns the decoded log data (typically request/response bodies, transform input/output, or script `options.logs` entries) for a single `(step, stage)` tuple within a flow run. Stages are bubble-kind specific. The most useful values: - **Export / Lookup:** `apiCall` (HTTP request+response for HTTP exports), `transformation`, `outputFilter`, `responseMapping`. - **Import:** `apiCall`, `mapping`, `inputFilter`, `responseTransformation`. - **Router:** `routing` (branching decision). - **Any:** the `function` name from a configured script hook (e.g. `preMap`, `postMap`, `postSubmit`, `postResponseMap`, `preSavePage`) — populated only when the hook explicitly calls `options.logs.push(...)`. This is typically the terminal call in the drill-down sequence: `execution-logs` then `metadata/query` then `data/query`. For HTTP traces, set `stage: apiCall`. A 200 with `logs: []` means the stage ran but produced no log entry — usually because a script did not call `options.logs.push()`, or the stage is not instrumented for that adaptor. via POST /v1/flows/{_id}/jobs/{_jobId}/logs/data/query

Query execution-log metadata for a record-at-step -- Returns per-step timing and outcome metadata for a single record as it traveled through a flow run. When the request includes `traceKey`, the response spans every step that shared that trace — typically the source export plus its downstream imports. Pull the `_expOrImpId`, `groupId`, `recordId`, and (optionally) `traceKey` values from a `GET /v1/flows/{_id}/jobs/{_jobId}/logs` entry. Pair this with `logs/data/query` to build a full per-record trace: this endpoint shows which steps were touched and timing; the data endpoint returns actual payloads. When `duplicateTraceKey` is `true`, the traceKey was seen on more than one record in the job, so results may mix records from retries or fan-out. Without `traceKey` in the request, `traceView` is `false` and only the single queried step is returned. via POST /v1/flows/{_id}/jobs/{_jobId}/logs/metadata/query

Cancel all running jobs for a flow -- Cancels every currently running job for the specified flow. This is the flow-scoped equivalent of cancelling individual jobs via `PUT /v1/jobs/{_id}` — it finds all in-progress jobs for the flow and requests cancellation in a single call. No request body is required. The response is an empty 204 on success. Cancellation is asynchronous — jobs may take a few seconds to fully stop after the 204 is returned. via POST /v1/flows/{_id}/jobs/cancel

Trigger a flow run -- Queues an on-demand run of the flow and returns the parent job id. The run is **asynchronous**: the response returns as soon as the job is queued; use `GET /v1/jobs/{_id}` (with the returned `_jobId`) or `GET /v1/flows/{_id}/jobs/latest` to poll for terminal status. The request body is optional. When omitted, the flow runs with its configured schedule behavior — for delta flows this means using the current `lastExportDateTime` as the lower bound. Pass `export.startDate` / `export.endDate` to override the delta window for this run only (the flow's checkpoint still advances on success). Pass `_exportIds` to limit execution to a subset of the flow's generators (useful for flows with many independent sources). Flow-level preconditions enforced by the platform: - The flow must not be `disabled`. - The flow must be in an enabled integration (when part of one). To trace a run end-to-end, arm debug logging before calling this, then use the returned `_jobId` with the execution-log endpoints. For delta backfills, prefer passing explicit `startDate`/`endDate` over editing the export's `lastExportDateTime` — the override is scoped to one run. A 200 with `_jobId` absent means the request was accepted but no job was queued, usually because another run is already in progress. via POST /v1/flows/{_id}/run

Test-run a flow -- Executes the flow in **test mode** and returns the test-run metadata synchronously. Unlike `POST /v1/flows/{_id}/run` (which queues an asynchronous production job), a test run executes inline against the flow's current configuration and records the per-step stages it produced. Test runs are kept in a **separate history** from production runs — the `flowJob` and `childJobs` returned here are test artifacts, not records you'll find via `GET /v1/jobs`. The top-level `metadata` map is keyed by step id; each value is the ordered list of stage names that step produced (e.g. `request`, `parse`, `router`, `input`). Use those step ids with `GET /v1/flows/{_id}/test/run/{runId}/{_stepId}` to inspect per-stage input/output and errors, or with `GET /v1/flows/{_id}/test/run/{runId}/{_stepId}/logs/requestAndResponse` for raw outbound HTTP captures. **Endpoint template applies across three resource families.** The same test-run shape also exists for Tools (`/v1/tools/{_id}/test/run`) and builder-mode APIs (`/v1/apis/{_id}/test/run`). Test-run state is short-lived and ephemeral — capture the `runId` (the `flowJob._id`) and read back any step detail soon after the run returns. via POST /v1/flows/{_id}/test/run

Get per-flow run statistics (dashboard aggregates) -- Returns **per-flow aggregate** run statistics — one element of `stats[]` per flow that has at least one run matching the request filter. Each aggregate carries totals (`numRuns`, `numSuccess`, `numError`, `numIgnore`), the currently-open error count (`numOpenError`), resolution attribution (`numResolvedByAuto` / `numResolvedByUser`), average runtime (`avgRuntime`), and timestamps (`lastExecutedAt`, `lastErrorAt`) plus a minimal inlined `flow{}` object for rendering. The Celigo dashboard uses this to paint its "All flows" summary in one call. Filters (`_flowIds`, `_integrationIds`, `time_gt`, `time_lte`, …) narrow which runs are rolled up into each aggregate — they do **not** filter which flows appear; flows with zero matching runs are simply omitted. **The window is the contract.** When `time_gt` is omitted the endpoint applies its default window (approximately the last 24 hours) rather than aggregating all history — runs older than the window silently drop out of every aggregate. Send `time_gt` explicitly for any other range. For individual job records rather than aggregates, use `GET /v1/jobs?_flowId=...`. For in-progress jobs, use `POST /v1/jobs/current`. via POST /v1/flows/runs/stats

Create a group -- Creates a group for end-user access management. Group names must be unique within the account (case-insensitive), and any `_roleIds` or `resourceGrants._resourceId` values must reference resources owned by the same account. Requires account owner or administrator access. via POST /v1/groups

Add end users to a group -- Bulk-adds up to 100 end users to the group as manual memberships. The operation is idempotent for end users already in the group. Requires account owner or administrator access. via POST /v1/groups/{_groupId}/members

Remove end users from a group -- Bulk-removes manual memberships from the group. Only manual memberships can be removed this way — attempting to remove an IdP-synced membership returns 409; change the IdP group mapping instead. Uses POST rather than DELETE so the request body survives proxies and CDNs. Requires account owner or administrator access. via POST /v1/groups/{_groupId}/members/remove

Create an HTTP connector -- Creates a new HTTP Connector framework definition. `name` is required, along with either `versions` (flat connector) or `apis` (grouped connector). via POST /v1/httpconnectors

Create an iClient -- Creates a new iClient. The `provider` field is required and determines which credential sub-object must be populated. via POST /v1/iclients

Create an import -- Creates a new import configuration that can be used to send data to applications or external destinations. Celigo documents this same endpoint on 3 resource pages: imports (createImport) plus ai-agents (createAiAgent), guardrails (createGuardrail). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via POST /v1/imports

Clone an import -- Creates a copy of an existing import. Supports optionally remapping referenced connections (via connectionMap). via POST /v1/imports/{_id}/clone

Invoke an import with data and return per-record results -- Runs an existing import against the destination system with the supplied data records and returns per-record results synchronously. The request body should contain a `data` array of records to import. Each record is processed through the import's mappings, transformations, and hooks before being sent to the destination. The response is an **array** of per-record result objects, each containing a `statusCode`, the transformed `_json` payload, and any `errors` encountered during processing. This endpoint writes to the destination system — and so does `POST /v1/imports/preview` (verified to execute the composed request), so neither is a dry run against a production destination. A 200 response may still contain per-record failures in each element's `errors` array. via POST /v1/imports/{_id}/invoke

Preview the output of an import doc (no job created) -- Runs an import doc through the flow engine's preview pipeline against supplied sample data and returns the per-stage output. **The composed request IS executed against the live destination** — previewing a create/update import against a production system writes real records (a saved `mockResponse` does NOT protect this surface; it substitutes only in flow test runs and flow-builder previews), so point previews at sandbox destinations when a live write is not acceptable. There is no request option that disables the send: flags such as `preview`, `sendAndPreview`, or `send` — top level, inside an `options` object, or on the import doc — are silently ignored and the request executes regardless. For a compose-only preview of the destination request, use `POST /v1/pageProcessors/preview` with `{preview: true}` on the target entry (requires a flow context). No Job record is created and no flow-level state is updated. The integrator.io UI never calls this path — the import editor's "Preview" and "Send" buttons both go through `POST /v1/pageProcessors/preview`. This endpoint is the API-only, unscoped counterpart to `POST /v1/integrations/{_integrationId}/flows/{_flowId}/imports/preview` — prefer this variant when previewing a standalone import that is not yet associated with a flow. via POST /v1/imports/preview

Preview and compare AI agent configurations -- Runs one or more AI agent import configurations against the same input data and returns the LLM response, token usage, and timing for each. No job is created and no state is updated — this is a stateless preview. The UI uses this to compare model or prompt variations side-by-side before saving. Each entry in `imports` is a full import object (the same shape returned by `GET /v1/imports/{_id}`) with the `aiAgent` block configured for the variant being tested. Each entry in `imports` must include `adaptorType: "AiAgentImport"` and a valid `aiAgent` configuration. A `_connectionId` is required unless the agent uses platform-managed credentials. The response array is positional — `response[i]` corresponds to `imports[i]`. A per-entry `statusCode: 422` with `errors` means that specific configuration failed, not that the overall request failed. via POST /v1/imports/preview/compare

Create an integration -- Creates a new integration. Only `name` is required — the server populates all other fields with defaults. Do not include Integration App fields (`_connectorId`, `_templateId`, `install`, `installSteps`, etc.) unless you are creating an IA installation. via POST /v1/integrations

Change the edition of an Integration App integration -- Triggers an edition change for an Integration App integration that has a `changeEdition` function configured. Requires the integration to belong to an Integration App with edition support. via POST /v1/integrations/{_id}/changeEdition

Clone an integration -- Creates a copy of an existing integration. Supports optionally remapping referenced connections (via connectionMap). via POST /v1/integrations/{_id}/clone

Initialize a child integration -- Initializes a child integration under an Integration App parent. Requires the parent integration to belong to an Integration App with an init script configured. via POST /v1/integrations/{_id}/initChild

Create a snapshot revision -- Takes a point-in-time snapshot of the integration's current state and writes it to the revision history. The returned revision has `type: snapshot` and `status: completed` immediately -- snapshots are synchronous and do not require an apply step. This is the only revision type that can be created via the public API; `pull` and `revert` revisions require the Celigo UI. via POST /v1/integrations/{_id}/revisions/create

Preview export data -- Preview export data from a specific export within a flow. This endpoint allows you to preview the data that would be exported, including the exported data, URIs to the data in the source app, and processing stages information. via POST /v1/integrations/{_integrationId}/flows/{_flowId}/exports/preview

Preview import data -- Runs the import pipeline — field mappings, transformations, and hooks — against the supplied sample data and returns the per-record results. Treat the preview as capable of executing the composed destination request: its unscoped sibling (`POST /v1/imports/preview`) is verified to write real records to live destinations and offers no option to disable the send, so do not preview create/update imports against production systems with data you do not want written. For a compose-only preview of the destination request, use `POST /v1/pageProcessors/preview` with `{preview: true}` on the target entry. via POST /v1/integrations/{_integrationId}/flows/{_flowId}/imports/preview

Install a template from an uploaded zip -- Installs a template from a previously uploaded zip file. The `runKey` in the request body ties this request to the zip upload (obtained from `GET /v1/s3SignedURL`). via POST /v1/integrations/template

Install an integration from a template -- Installs an integration from a published template. The caller provides a `connectionMap` that maps each template-defined connection ID to an actual connection ID in the caller's account. Every template connection must appear as a key in `connectionMap`. via POST /v1/integrations/template/{_id}

Invite users to the account -- Invite one or more users by email. Each entry in the response array corresponds to the email at the same index — check `statusCode` per entry for partial failures. via POST /v1/invite/multiple

Get signed URL(s) to download job files -- Returns short-lived S3 pre-signed URLs for downloading files produced by the job (e.g. the rows exported to a CSV, an error-record dump, or a page-processor artifact). The URLs are typically valid for ~15 minutes. If `fileIds` is omitted in the request body, all of the job's current file artifacts are returned. If provided, only the matching files are included. Inspect the job's `files[]` array first (via `GET /v1/jobs/{_id}`) to discover available file IDs. Jobs with no files (common for `import` child jobs or jobs past `purgeAt`) return `204 No Content`. File ids are registered per job: if none of the requested `fileIds` are registered to this job (e.g. the file id belongs to a different job's run), the endpoint also returns `204 No Content` with an empty body rather than an error. The URLs expire after approximately 15 minutes -- fetch immediately, do not persist. via POST /v1/jobs/{_id}/files/signedURL

List in-progress jobs (dashboard) -- Returns a paginated list of currently in-progress jobs for the dashboard -- jobs whose `status` is one of `queued`, `running`, or `canceling`. Jobs that have reached a terminal state (`completed`, `failed`, `canceled`, `retried`) are not returned; use `POST /v1/flows/runs/stats` for run history. The request body contains all filters -- there are no query-string parameters. Narrow to a specific flow or integration with `_flowIds` / `_integrationIds` (AND-combined). via POST /v1/jobs/current

Batch-fetch job families -- Returns job families for an array of job ids, in one request. Each item in the response array has the same shape as a single `GET /v1/jobs/{_id}/family` call (a parent job with inlined `children`). **Size limit: 1000 ids per request.** The server rejects requests with more than 1000 entries with HTTP **403** (not 400) and `{code: "invalid_request", message: "Number of objects in the request exceeds maximum allowed limit 1000"}`. The Celigo UI chunks at 50 for its own UX reasons, but the API ceiling is 1000. **Mixed-id behavior (asymmetric):** - Valid + unknown 24-hex ids in the same array → **200** with only the resolved entries; unknown ids are silently dropped (no `errors[]` alongside). - All ids unknown → **404** with `{errors: [{code: "invalid_ref", source: "internal", message: "Job not found: <id>"}]}`. - Any id that isn't a 24-char hex string anywhere in the array → **400** `invalid_ref "Please provide a valid _id."` — the whole request fails. - Duplicate ids are **deduped** server-side (same id ×N → one entry). - Empty array `[]` or non-array body (e.g. `{}`) → **400** `invalid_request "Request body should be an ObjectID array."`. - Missing `Content-Type: application/json` → **415** `{message: "Content-Type should equal application/json"}`. The response array has no guaranteed ordering; match items by `_id` rather than by index. Unknown ids are silently dropped -- callers that need to detect missing ids must diff the request and response id sets. via POST /v1/jobs/family

Create a lookup cache -- Creates a new empty lookup cache. Only `name` is required. Populate it afterwards via `POST /v1/lookupcaches/{_id}/data`. via POST /v1/lookupcaches

Upsert entries into a lookup cache -- Writes key-value entries to a lookup cache. Keys that already exist are overwritten; new keys are created. Keys are strings; values may be strings or objects — arrays at the top level are rejected (wrap them in an object). One invalid value fails the entire batch with `400 invalid_value`. The service rejects batches larger than ~1000 entries or ~5 MB of JSON. Callers uploading more than that should split their payload; the Celigo CLI auto-batches at 1000 entries / 5 MB and concatenates the per-key results. Each cache is capped at 50 MB and the per-environment aggregate is 1 GB. via POST /v1/lookupcaches/{_id}/data

Read entries from a lookup cache -- Returns entries stored in a lookup cache. Called as `POST` (not `GET`) so the query — explicit keys or a prefix — can travel in the request body. Body variants: - omitted or `{}` → first page of all entries (up to ~1000, unordered). - `{keys: [...]}` → one entry per requested key. Hits carry `value`; misses carry `error: {message}` — missing keys are **reported**, not silently omitted. Branch on `error` vs `value` when consuming the response. - `{startsWith: "prefix"}` → every entry whose key begins with `prefix` (case-sensitive). `keys` and `startsWith` are treated as mutually exclusive client-side; if both are supplied the server honors `keys` and ignores `startsWith`. Keys are case-sensitive. There is no pagination cursor for unfiltered reads; for caches larger than ~1000 entries, use a prefix scheme with `startsWith`. via POST /v1/lookupcaches/{_id}/getData

Create an MCP OAuth provider -- Creates a reusable OAuth provider that MCP servers can reference via `_mcpOAuthProviderId`. `name`, `issuerURL`, and `audience` are required. Set `useIntrospection: true` with `clientId`/`clientSecret` to support opaque (non-JWT) tokens. via POST /v1/mcpoauthproviders

Create an MCP server -- Creates an MCP server. The server is created disabled by default. `name` and `relativeURI` are the only required fields; `relativeURI` must be unique per account. via POST /v1/mcpservers

Preview the output of a flow's page processor -- Runs a flow's page generators and page processors through the preview pipeline and returns the record arriving at a specific page-processor node, with the whole upstream chain applied server-side: the source export executes live (its transform, output filter, and preSavePage hook are applied), router branch filters and step input filters gate the records, upstream lookups execute live unless a saved `mockOutput` is present (a saved mock always wins), and upstream imports are NEVER executed — each substitutes its saved `mockResponse`, or a platform placeholder when none is saved, before its response mapping and postResponseMap hook run. A target IMPORT obeys its map entry's options flag: `{preview: true}` composes the request and returns it without sending, while `{sendAndPreview: true}` (the import editor's "Send" button) executes it against the live destination — a real write. A target LOOKUP executes its live query (even when it carries a saved `mockOutput` — the mock substitutes only when the lookup is upstream of the target). With `includeStages: false` the response is the bare result object rather than the `{data, stages}` envelope. Body carries the flow shape plus resolved maps of page-generator and page-processor docs keyed by `_id`. The server uses those maps as the source of truth for the preview — it does not read the persisted flow doc, so callers can pass modified versions to "what-if" iterate. The body field is `flow` (the API's error message referencing `flowDoc` is stale). Every entry referenced by `flow.pageGenerators[]._exportId` must exist in `pageGeneratorMap` keyed by that id, wrapped as `{doc, options}`; same for `pageProcessorMap`. Set `includeStages: true` to get the stage-by-stage diagnostic array. No job is created and no flow state changes; live calls are limited to the source export, un-mocked upstream lookups, the target lookup, and — only under `sendAndPreview` — the target import. Upstream imports never call out. via POST /v1/pageProcessors/preview

Generate CSV from JSON -- Generates CSV output from JSON records using the specified delimiter and formatting rules. The response always has `mediaType: "text"` and does not include `dataRecordTraceKeys` or `traceKeysDuplicate`. This is a stateless transformation. via POST /v1/processors/csvDataGenerator

Convert CSV to JSON -- Parses CSV data into JSON records using the specified delimiter and formatting rules. Both `data` and `rules` are technically optional — omitting either returns an empty result rather than an error. When `hasHeaderRow` is false, columns are named `Column0`, `Column1`, etc. When `includeEmptyValues` is true, missing values become JSON `null` instead of being omitted from the record. When `groupByFields` is used the response shape changes: `data` becomes an array of arrays (grouped records) and the `dataRecordTraceKeys` / `traceKeysDuplicate` fields are omitted. This is a stateless transformation. All values are returned as strings, even numeric CSV columns. via POST /v1/processors/csvParser

Generate structured file (EDI) from JSON -- Generates EDI or other structured/delimited file content from JSON records using a file definition (generation rules). Commonly used for producing X12 and EDIFACT documents. Unlike the parser endpoint, the generator places file definition fields directly in `rules` (no `fileDefinition` wrapper). Each element in the definition must include a `value` property containing the literal text to output for that field. The `data` field must be an array of objects. Each object in the array represents one document to generate. The response has `mediaType: "text"` and does not include `dataRecordTraceKeys` or `traceKeysDuplicate`. **Required file definition fields** — `name`, `version` (string `"1"` or `"2"`), `format`, the format sub-object with `rowDelimiter` + `colDelimiter` (and optionally `rowSuffix`), and `rules` defining segments with elements that each have `name` and `value`. This is a stateless transformation. File definition fields go directly in `rules` (no `fileDefinition` wrapper, unlike the parser endpoint). via POST /v1/processors/structuredFileGenerator

Parse structured file (EDI) to JSON -- Parses EDI or other structured/delimited file data into JSON using a file definition (parsing rules). Commonly used for X12 and EDIFACT documents. The file definition must be provided inside a `rules.fileDefinition` wrapper object, or referenced by ID via `rules._fileDefinitionId`. This differs from the generator endpoint which places definition fields directly in `rules`. The response includes a `recordLevelErrors` array not present on other processor responses. This is a stateless transformation. Provide the file definition inline via `rules.fileDefinition` or reference an existing one via `rules._fileDefinitionId` (not both). The generator endpoint places definition fields directly in `rules` (no `fileDefinition` wrapper). **Required file definition fields** — `name`, `version` (string `"1"` or `"2"`), `format` (`delimited`, `delimited/x12`, `delimited/edifact`, or `fixed`), and the corresponding format sub-object (`delimited` or `fixed`) with at least `rowDelimiter` and `colDelimiter` (for delimited) or `rowDelimiter` and `paddingChar` (for fixed). The `rules` property defines the segment/element hierarchy. via POST /v1/processors/structuredFileParser

Convert XML to JSON -- Parses XML data into JSON records using the specified parsing rules and resource path. **Resource path format** — Use XPath-style slash-separated paths (e.g. `/root/item`). Dot-separated paths (e.g. `root.item`) do not work. **Legacy vs modern output** — Without `doc.parsers` configured, or with `V0_json: true`, the parser produces a legacy format where element text appears as `[{"_": "value"}]` arrays and attributes appear under a `$` key. Setting `V0_json: false` produces clean key-value pairs and flattens attributes into the record. When `groupByFields` is used the response shape changes: `data` becomes an array of arrays and `dataRecordTraceKeys` / `traceKeysDuplicate` are omitted. Invalid XML returns a 422 with code `cannot_parse_xml`. Namespaced XPath expressions (e.g. `ns:element`) return a 422 with code `invalid_xpath`. via POST /v1/processors/xmlParser

List Integration Apps and Templates together -- Returns a unified array of **all** marketplace content — both Integration Apps (`docType: Connector`) and Templates (`docType: Template`). Each entry carries the `docType` discriminator so callers can partition. Despite being a POST, this is a **read-only, safe** endpoint — the body is an empty `{}` in the default CLI invocation. POST is used purely to carry sort and filter parameters that don't fit cleanly in a query string. The route is POST-only. Always send `Content-Type: application/json` with at least `{}` as the body. For Connector-only listings, `GET /v1/published` is lighter. via POST /v1/published/combined

Restore a deleted resource -- Restores a single resource from the recycle bin back to the account's active resources. Any request body is ignored. Standalone restore is blocked if a child resource is still in the recycle bin. To restore a resource along with all of its dependents (child flows, exports, imports, etc.), use the cascade-restore endpoint instead. via POST /v1/recycleBinTTL/{_resourceType}/{_id}

Cascade-restore a deleted resource -- Restores a resource from the recycle bin along with all of its dependent resources (child flows, exports, imports, connections, scripts, etc.). Any request body is ignored. Prefer this over standalone restore when restoring integrations or flows. This path uses `resourceType` (no leading underscore), unlike the other recycle bin paths which use `_resourceType`. via POST /v1/recycleBinTTL/{resourceType}/{_id}/doCascadeRestore

Create a role -- Creates a role. Role names must be unique within the account (case-insensitive), and `resourceGrants._resourceId` values must reference resources owned by the same account. Requires account owner or administrator access. via POST /v1/roles

Create a script -- Creates a new script. via POST /v1/scripts

Create a stack -- Creates a new stack. For server stacks, retrieve the system token after creation via `GET /v1/stacks/{_id}/systemToken`. via POST /v1/stacks

Cancel a multipart upload -- Aborts an in-progress multipart upload, discarding any uploaded parts and releasing the reserved quota. Use this to abandon a multipart upload started with `POST /v1/storage/files/initiateUpload`; single PUT uploads do not need canceling. If the upload has in fact already completed in S3, the item is activated instead and the request is rejected as not pending. via POST /v1/storage/files/{_id}/cancel

Initiate file upload -- Starts one or more file uploads. For each file, reserves quota, creates a pending item, and returns presigned S3 URLs to transfer the bytes to: a single PUT URL for files up to 5 GB, or a multipart `uploadId`, `partUrls`, and `completeUrl` for larger files. Upload the bytes directly to those URLs, then the item flips to active once S3 confirms it — no further API call is needed. URLs expire after one hour; reissue them with `POST /v1/storage/files/refresh-urls`. Each file is validated independently, so the response can mix per-file successes and failures while the request itself returns 200. via POST /v1/storage/files/initiateUpload

Refresh upload URLs -- Reissues presigned upload URLs for pending uploads whose URLs have expired (URLs last one hour). For a single PUT, returns a fresh upload URL; for multipart, returns fresh URLs for the requested part numbers plus the complete URL. Already-uploaded parts are preserved. Each item is processed independently. via POST /v1/storage/files/refresh-urls

Create a folder -- Creates an empty folder. Folders are organizational only — they hold no content and do not count against storage quota. To create files, use `POST /v1/storage/files/initiateUpload`. via POST /v1/storage/items

Look up items in batch -- Returns metadata for up to 100 items in one call. Send the item ids and optionally a `fields` projection; by default each result carries only `_id`. Requesting `path` adds a breadcrumb path built from the item's ancestor folder names. With `failFast: true` (the default), the first unknown id fails the whole request with `422 STORAGE_BATCH_ITEM_NOT_FOUND`. With `failFast: false`, unknown ids come back inline as `{_id, notFound: true, reason: "STORAGE_BATCH_ITEM_NOT_FOUND"}` entries alongside the found items. via POST /v1/storage/items/batch

Copy a file -- Creates an independent copy of a file in a destination folder, with a new `_id` and its own copy of the content. Consumes quota equal to the source file's size. Files only — folder copy is not supported. Names are not deduplicated, so copying into the source's own folder without a new name produces a second file with the same name. via POST /v1/storage/items/{_id}/copy

Merge a folder into another -- Merges the contents of a source folder into an existing destination folder, then removes the source. Runs asynchronously: the request is validated and queued, and the endpoint immediately returns `202` with a job receipt — contents move in the background and the source folder disappears once the merge completes. A soft-deleted source folder may be merged, which restores its contents into the destination. Folders only — move individual files with the move endpoint. Requires delete access on the source folder and write access on the destination. via POST /v1/storage/items/{_id}/merge

Restore an item -- Restores a soft-deleted item from the recycle bin back to its original location. Restoring a folder also restores the descendants that were removed with it; the folder comes back immediately and its descendants follow asynchronously. Only items deleted directly can be restored — a descendant removed by its parent's deletion comes back only when that parent folder is restored. via POST /v1/storage/items/{_id}/restore

Move items in bulk -- Moves up to 100 files or folders into one destination folder (or the account root) in a single call. Metadata only — content stays in place, ids are unchanged, and quota is unaffected. Folders re-parent immediately and re-anchor their descendants asynchronously. The destination is validated once up front — a bad destination rejects the whole batch. Each source id is then processed best-effort: the response is `200` when every item moved, or `207` when results are mixed, with a per-id `status` of `success` or `error`. An optional `name` renames the item as it lands (single-id requests only) so a destination name collision can be resolved without a second call. via POST /v1/storage/items/move

Create a sync -- Creates a sync inside an integration. Only `_integrationId` and `source._connectionId` are required — new syncs start as disabled drafts, so the destination, datasets, and schedule can be configured with later requests. Creating a sync also registers its connections for the platform's replication runtime. via POST /v1/syncs

Trigger a sync run -- Queues an on-demand run of a sync and returns identifiers for the new sync job. The run is **asynchronous**: the response returns as soon as the job is queued. Use `GET /v1/syncJobs/{_syncJobId}` or `GET /v1/syncs/{_syncId}/syncJobs` to poll for terminal status. By default the run type is `"normal"` (incremental delta). Pass `runType: "resync"` to force a full re-extraction from the source, which drops the delta checkpoint and reloads all data. Preconditions enforced by the platform: - The sync must not be disabled (`422 invalid_sync`). - There must not be a job already queued for this sync (`409 sync_job_already_queued`). The returned `flowExecutionGroupId` is a correlation key across jobs and errors. For multi-table syncs, a single run creates one parent job with per-table children visible via `GET /v1/syncJobs/{_syncJobId}/family`. via POST /v1/syncs/{_syncId}/run

Create a tag -- Creates a new tag in the account's tag catalog. The server generates an immutable short `tagId` code automatically. Tag names are case-insensitively unique within the account — a case-variant duplicate is rejected with HTTP 422 `[create_not_allowed]` "A tag with this name already exists." Per Celigo's documentation, the catalog holds at most 1,000 unique tags per account. Note the per-error limit is separate and much smaller: a single error carries at most 3 tags (see `PUT /v1/flows/{_id}/{_stepId}/tags`). via POST /v1/tags

Create a template -- Creates a new integration template. Only `name` is required; all other fields are optional. Upload a zip via `GET /v1/s3SignedURL` before attempting to publish. via POST /v1/templates

Create a tool -- Creates a new tool within an integration. `name` and `_integrationId` are required. Routers use `first_matching_branch` strategy only, and each branch's `nextRouterId` must point to another router's `id` or `"outputRouter"` to exit the tool. via POST /v1/tools

Clone a tool -- Creates a copy of a tool in the target integration and returns a manifest of the resources the clone created. The clone records its lineage in `_sourceId`, which places it in the source tool's clone family. The target integration is never inferred from the source tool — pass the source tool's own integration id to clone in place. Use `GET /v1/tools/{_id}/clone/preview` first to see what the clone would create. via POST /v1/tools/{_id}/clone

Invoke a Tool synchronously -- Executes a Tool synchronously and returns the mapped output (or errors). Optional `x-log-mode` enables enterprise invocation logging. When logging is active for the run, the response includes `invocationId` — use that value as `{executionId}` with `GET /v1/tools/{_id}/invocations/{executionId}`. Sandbox Tools return `403` when logging is attempted. via POST /v1/tools/{_id}/invoke

Run a tool in test mode -- Synchronously executes a tool in test mode and returns the run metadata together with the resulting flow job and its child jobs. Use this to validate a tool's routing and step configuration before referencing it from a flow, API, agent, or MCP server. The request body is optional. When supplied, wrap the test input in an `input` key (`{"input": {...}}`) matching the tool's input contract. The run does not read the tool's saved `input.mockInput` — without a wrapped `input` the tool executes against an empty input record. The `metadata` object in the response maps each step id to the ordered list of stage names that ran for that step; use those ids with `GET /v1/tools/{_id}/test/run/{runId}/{_stepId}` to inspect stage-by-stage results. The run id for follow-up calls is the `flowJob._id` value. Test runs are a separate, short-lived history from normal runs — capture any follow-up step or log details soon after the run completes. via POST /v1/tools/{_id}/test/run

Create a trading partner connector -- Creates a new trading partner connector. Only `name` is required. Setting `published: true` requires the `allowedToPublishTPConnectors` permission; without it the field is silently ignored. via POST /v1/tpconnectors

Update an on-premise agent -- Replaces an on-premise agent's mutable fields. Only `name` and `description` are mutable — system-managed fields (`version`, `offline`, `port`, etc.) are ignored on PUT. via PUT /v1/agents/{_id}

Rotate on-premise agent access token -- Regenerates the access token and returns the new value. The previous token is immediately invalidated — the running agent process will disconnect, so update the agent's configuration with the new token before it attempts to reconnect. This is irreversible. via PUT /v1/agents/{_id}/change-token

Publish resource to existing APIM API -- Publishes an integrator.io resource to an existing APIM API. Requires `apim:operations` permission and an enabled APIM license. Upstream API management errors may be returned with the upstream HTTP status. via PUT /v1/apim/{modelPlural}/{_id}/manageAPI

Validate APIM environment HRID -- Checks whether an environment HRID is available for APIM configuration. Production environment only. via PUT /v1/apim/hrid/validate

Update APIM account settings -- Updates the service account email for an existing APIM account configuration. Production environment only. Requires `apim:operations` permission. via PUT /v1/apim/setup

Validate APIM subdomain -- Checks whether a subdomain is available for APIM account setup. Production environment only. via PUT /v1/apim/validate

Update an API -- Replaces the full API configuration. Send the complete object -- omitted fields revert to defaults, not their prior values. Read-only fields (`_id`, `createdAt`, `lastModified`) in the request body are ignored. `logging` is also ignored -- silently: a PUT that includes `logging` succeeds with the stored value unchanged, and no error reveals that the change was dropped. Use `PATCH /v1/apis/{_id}` (paths `/logging/mode`, `/logging/debugUntil`) to change logging settings. via PUT /v1/apis/{_id}

Convert a JSON object to JSON Schema -- Accepts a sample JSON object and returns its inferred JSON Schema definition. Useful for bootstrapping `bodySchema` in builder-mode APIs from real payload samples. Input must be a non-empty JSON object -- arrays and primitives are rejected. The generated schema is shallow (one level of `properties`); nested objects become `type: "object"` without further property inference. via PUT /v1/apis/schema

Update the grouping for one or more APIs -- Assigns or removes an API grouping for the specified API resources. Pass `_apiGroupingId: null` to ungroup. Nonexistent API IDs are silently accepted. via PUT /v1/apis/updateApiGrouping

Update a user -- Update a user's access level, integration permissions, or account settings. The user's email cannot be changed after invite. To disable a user without deleting, use `PUT /v1/ashares/{_id}/disable` instead. via PUT /v1/ashares/{_id}

Reinvite a user who dismissed their invite -- Re-sends the invitation to a user who previously dismissed it. Only works on users with `dismissed: true` in the user record. After reinviting, the user returns to a pending state awaiting acceptance. via PUT /v1/ashares/{_id}/reinvite

Toggle a user's account access (disable or re-enable) -- Toggles the `disabled` flag on a user's access record. Call again to re-enable — there is no separate `/enable` path. Only works on users with `accepted: true`. via PUT /v1/ashares/{_userId}/disable

Update an async helper -- Updates an existing async helper with the provided data. This is a full replacement — all required fields must be included in the request body. via PUT /v1/asynchelpers/{_id}

Create or update a resource-scoped state value -- Sets the value for a state key under a specific resource. Creates the key if it does not exist; replaces the value if it does. The request body must be a non-empty JSON object or array. Bare JSON primitives (strings, numbers, booleans, `null`) and empty containers (`{}`, `[]`) are rejected. Only `exports`, `imports`, and `integrations` support resource-scoped state. This is an upsert — check the status code to distinguish create (201) from update (200). The response body is plain text, not JSON. via PUT /v1/{resourceType}/{_resourceId}/state/{key}

Update a connection -- Updates an existing connection configuration. This is a full-replace operation — send the complete connection document, not just the fields you want to change. via PUT /v1/connections/{_id}

Query metadata for a connection (RDBMS catalog or HTTP passthrough) -- Fetches metadata from the system behind the connection. The request and response are bimodal, chosen by the connection's type: - rdbms / jdbc — runs a live catalog lookup. Send the `rdbms` wrapper (`type: tables` or `columns`). `type: rdbms` returns a `{results: [...]}` envelope of `{database, schema, table}` items, with a `columns[]` array of driver type metadata for column queries; `type: jdbc` returns a bare array with leaner column metadata and a `primaryKeys[]` sibling. Results are cached — pass `refreshCache: true` to bypass and repopulate (use sparingly). - http — signs and forwards an HTTP request through the connection's auth and `baseURI` (send the `http` wrapper with a `body`), returning the target's raw, opaque response. Used for GraphQL introspection and REST endpoint discovery. Send the wrapper that matches the connection type; the wrong wrapper is a validation error. Empty RDBMS results are legitimate — empty cache, missing catalog permissions, or no columns. via PUT /v1/connections/{_id}/metadata

Update a connector -- Full-replaces a connector resource. **Partner-only endpoint.** via PUT /v1/connectors/{_id}

Update a license -- Updates an existing license for a connector (e.g. change expiry or edition). **Partner-only endpoint.** via PUT /v1/connectors/{_id}/licenses/{_licenseId}

Push update to connector installations -- Pushes an update to all (or specified) installations of this connector. Triggers the connector's `updateFunction` on each target integration. **Partner-only endpoint.** via PUT /v1/connectors/{_id}/update

Update an EDI profile -- Updates an existing EDI profile. `fileType` cannot be changed after creation. Omitted fields are cleared to defaults. via PUT /v1/ediprofiles/{_id}

Update an environment -- Replaces an environment's mutable fields (`name`, `description`, `apim`). To enable or disable an environment, use the toggle endpoint instead. via PUT /v1/environments/{_id}

Toggle an environment on or off -- Toggles the enabled state of an environment -- a disabled environment becomes enabled and vice versa. The Production environment cannot be disabled, and pending user invitations must be resolved before disabling any environment. Requires a `Content-Type: application/json` header even though no request body is needed. via PUT /v1/environments/{_id}/enable

Cancel an event report -- Cancels a queued or running event report. The report's `status` transitions to `canceled`. No request body is needed. Idempotent for reports already in `canceled` status. A `completed` report cannot be canceled, and canceled reports cannot be resumed -- create a new one instead. via PUT /v1/eventreports/{_id}/cancel

Update an export -- Updates an existing export with the provided configuration. This is used for major updates to an export's structure or behavior. via PUT /v1/exports/{_id}

Replace connection on export present in a flow -- Replaces the connection used by an export in a flow and cancels any running jobs. This is useful when migrating flows between environments or updating to newer connection versions. via PUT /v1/exports/{_id}/replaceConnection

Update a file definition -- Replaces the file definition with the provided configuration. This is a full replace -- include all fields you want to keep. `format` cannot be changed between `fixed` and `delimited` families after creation, and `globalId` is immutable for EDI formats. via PUT /v1/filedefinitions/{_id}

Cancel a flow execution group -- Cancels all remaining jobs in a flow execution group. Execution groups are created when multiple flows are triggered together (e.g. via integration-level run or chained flows) and share a common group identifier. The response varies depending on whether there were jobs left to cancel: - **200** with `{"message": "No more jobs to cancel"}` when no in-progress jobs remain. - **204** with no body when cancellation was successfully requested. This endpoint is not scoped to a specific flow — the `_id` parameter is the execution group id, not a flow id. Any string is accepted as the id (the server does not validate that the group exists before responding). Unknown or already-completed group ids return 404 `resource_not_found` — only groups with cancellable (queued/running) jobs are accepted. via PUT /v1/flowExecutionGroups/{_id}/cancel

Update a flow -- Replaces the entire flow configuration. All fields not included in the request body are reset to defaults — this is a full replace, not a merge. Always `GET` the flow first, modify the response, and `PUT` back — sending a partial body erases omitted fields. To change a single field (e.g. `disabled`, `schedule`), prefer `PATCH` over `PUT`. Read-only fields (`_id`, `createdAt`, `lastModified`) in the request body are silently ignored. via PUT /v1/flows/{_id}

Update the stored retry-data snapshot for an error -- **Full-replace** of the stored per-record snapshot. The body becomes the new payload that `POST .../retry` will feed back into the pipeline. Same envelope shape as the matching GET — send the whole object (not just `data`), optionally mutated. The typical workflow is: `GET .../{retryDataKey}/data`, mutate `data` locally, `PUT` the whole envelope back, then `POST .../retry` with the same `retryDataKey`. Send the complete envelope — omitted fields are lost, and `retryDataKey`, `stage`, `pgExportId` must match the original GET. Editing the snapshot does not clear the error; it stays open until a subsequent retry or manual resolve. via PUT /v1/flows/{_id}/{_stepId}/{retryDataKey}/data

Assign open errors to a user -- Tags a batch of open errors with an assignee for triage workflows. The errors stay open — this does not resolve or retry them — they simply appear in the assignee's "my errors" view until another action moves them. The `email` value is accepted verbatim and is not validated against the account's user list. Re-assigning the same batch to a different user overwrites the prior assignment. Use `PUT .../errors/unassign` to remove assignments entirely. via PUT /v1/flows/{_id}/{_stepId}/errors/assign

Remove assignment from open errors -- Removes the assignee from a batch of open errors. The errors remain open — this is the inverse of `PUT .../errors/assign`. Non-existent error ids are silently ignored (no error raised). The response's `errorsToReturn` contains only ids that were actually unassigned — ids that were already unassigned or don't exist are omitted. via PUT /v1/flows/{_id}/{_stepId}/errors/unassign

Mark open errors as resolved -- Moves a batch of currently-open errors to the resolved list. The underlying records are unchanged — no retry happens; this is purely an administrative state change used to clear the open-errors queue after a user has reviewed the failures and decided they're not actionable. To actually re-run the failed records, use `POST .../retry` instead. The request body field is named `errors` (carrying error ids), not `errorIds`. To clear the whole open-error queue in one call without listing ids, send `selectAll: true` with a `lastErrorAt` high-water mark instead of `errors`. via PUT /v1/flows/{_id}/{_stepId}/resolved

Set tags on a batch of errors -- **Full-replace** per-error: for each `(errorId, retryDataKey)` in the body, the stored tag set is replaced with `tagIds`. Pass `tagIds: []` to clear all tags from the listed errors. Tags are account-scoped short codes (from `GET /v1/tags`) — not free-form strings. The `tagId` you send here is the short code (e.g. `F3ZBQ`), **not** the tag document's Mongo `_id`. The errors batch uses short keys (`id` = errorId, `rdk` = retryDataKey) to minimize body size. Use `rdk: ""` for errors without a `retryDataKey` (connection-class errors). This endpoint replaces the full tag set per error — to add a tag without removing existing ones, merge client-side first. via PUT /v1/flows/{_id}/{_stepId}/tags

Replace a connection across a flow -- Replaces every occurrence of one connection with another across all exports, imports, and lookups in the flow. This is the recommended way to swap connections during environment promotion (e.g. credential rotation) — it updates all references atomically instead of requiring per-resource PUTs. The replacement connection must exist and be of the same adaptor type as the original. If the types do not match, the request is rejected with a 422. Use `GET /v1/flows/{_id}/descendants` to verify which resources use a given connection before replacing. via PUT /v1/flows/{_id}/replaceConnection

Assign flows to a flow group -- Assigns one or more flows to a flow-grouping (section) within their integration. This is the collection-level endpoint used by the UI's "move to section" action — it updates multiple flows in a single call rather than requiring a per-flow `PUT /v1/flows/{_id}` with a modified `_flowGroupingId`. The flows referenced in `_flowIds` must all belong to the same integration as the target `_flowGroupingId`. Pass `_flowGroupingId: null` (or an empty string, depending on platform version) to remove the flows from their current group back to the integration's default section. Flow groupings are managed on the parent integration (`PUT /v1/integrations/{_id}` with a modified `flowGroupings[]` array) — create the group first, then call this to populate it. via PUT /v1/flows/updateFlowGrouping

Update a group -- Replaces the group's writable fields. Prefer resending the complete object — omitted fields are not preserved. Requires account owner or administrator access. via PUT /v1/groups/{_id}

Update an HTTP connector -- Replaces the HTTP Connector with the provided fields. via PUT /v1/httpconnectors/{_id}

Update an iClient -- Replaces an iClient. All mutable fields must be provided — omitted fields are reset to defaults. Secrets returned as `"******"` can be sent back as-is to keep the existing value. via PUT /v1/iclients/{_id}

Update an import -- Updates an existing import with the provided configuration. This is used for major updates to an import's structure or behavior. Celigo documents this same endpoint on 3 resource pages: imports (updateImport) plus ai-agents (updateAiAgent), guardrails (updateGuardrail). They are one HTTP operation -- the resource kind is selected by the request body, not by a distinct path. via PUT /v1/imports/{_id}

Replace connection on import for a branched flow -- Replaces the connection used by an import in a flow and cancels any related running jobs. This is useful when migrating flows between environments or updating to newer connection versions. via PUT /v1/imports/{_id}/replaceConnection

Update an integration -- Replaces the integration's mutable fields. Send the full object -- omitted fields revert to defaults. GET the integration first, modify the fields you need, then PUT back. For partial updates to `settings`, `flowGroupings`, or `apiGroupings`, prefer PATCH with JSON Patch instead. via PUT /v1/integrations/{_id}

Register a connection to an integration (by path) -- Registers a single connection to the integration by specifying the connection id in the URL path. No request body is needed. To unregister, use `DELETE` on the same path. Alternatively, use `PUT /v1/integrations/{_id}/connections/register` to register by request body. via PUT /v1/integrations/{_id}/connections/{_connectionId}/register

Register a connection to an integration (by body) -- Registers a single connection to the integration by passing the connection id in the request body. Alternatively, use `PUT /v1/integrations/{_id}/connections/{_connectionId}/register` to register by path parameter. via PUT /v1/integrations/{_id}/connections/register

Detach the license from an integration -- Detaches the license from an integration. Idempotent -- calling it on an integration that already has no license attached is a no-op. No request body is needed. via PUT /v1/integrations/{_id}/detachLicense

(Legacy) Assign open errors to a user across an integration -- Tags a batch of open errors with an assignee. Errors stay open; this does not resolve or retry them. The `email` must resolve to a user with access to the account. Prefer `PUT /v1/flows/{_flowId}/{_stepId}/errors/assign` instead -- it works with a plain bearer token and requires no extra headers. This integration-level endpoint requires an `integrator-ashareid` header, and account-owner PATs have no ashare pointing at themselves, so they cannot call it directly. via PUT /v1/integrations/{_id}/errors/assign

Register a lookup cache to an integration (by path) -- Registers a single lookup cache to the integration by specifying the lookup cache id in the URL path. No request body is needed. To unregister, use `DELETE` on the same path. Alternatively, use `PUT /v1/integrations/{_id}/lookupcaches/register` to register several caches at once by request body. Registration also adds an entry to the integration's `aliases[]` when the cache does not already have one: `alias` is a slug of the cache name (lowercased, whitespace and special characters stripped, `_2`/`_3`/… appended on collision) and `_lookupCacheId` points at the cache. Scripts and hooks use the alias as a stable handle for the cache, and deregistering the cache is blocked until the alias is removed. via PUT /v1/integrations/{_id}/lookupcaches/{_lookupCacheId}/register

Register lookup caches to an integration (by body) -- Registers one or more lookup caches to the integration, adding them to its `_registeredLookupCacheIds` list. The request body is a bare JSON array of lookup cache ids; duplicates are collapsed. Alternatively, use `PUT /v1/integrations/{_id}/lookupcaches/{_lookupCacheId}/register` to register a single cache by path parameter. Registration also adds an entry to the integration's `aliases[]` for each newly registered cache that does not already have one: `alias` is a slug of the cache name (lowercased, whitespace and special characters stripped, `_2`/`_3`/… appended on collision) and `_lookupCacheId` points at the cache. Scripts and hooks use the alias as a stable handle for the cache, and deregistering the cache is blocked until the alias is removed. via PUT /v1/integrations/{_id}/lookupcaches/register

Resume an Integration App integration -- Resumes a paused Integration App integration. Requires that the integration belongs to an Integration App. No request body is needed. via PUT /v1/integrations/{_id}/resume

Cancel a job -- Requests cancellation of a running or queued job. The job's `status` transitions to `canceling` and, once the platform has stopped in-flight work, to `canceled`. This is **not** synchronous — the response returns the updated job record with `status: "canceling"`; consumers should poll (e.g. `GET /v1/jobs/{_id}`) to observe the final `canceled` state. Only jobs that are still in progress (`queued`, `running`, `retrying`) can be canceled. Canceling a job that is already terminal returns an error. Cancel at the flow-run (parent) level rather than individual export/import children -- child cancellations can leave the parent in an inconsistent state. via PUT /v1/jobs/{_id}/cancel

Update a lookup cache -- Replaces the cache's writable fields. Read-only fields (`_id`, `_userId`, `size`, `sizeInMB`, timestamps) are silently ignored. To write cached data, use `POST /v1/lookupcaches/{_id}/data`. via PUT /v1/lookupcaches/{_id}

Update an MCP OAuth provider -- Full replacement of an MCP OAuth provider's configuration -- include all fields, not just the ones you want to change. Send `clientSecret: "******"` to preserve the existing secret. Changes propagate to all MCP servers referencing this provider. via PUT /v1/mcpoauthproviders/{_id}

Update an MCP server -- Full replacement of an MCP server's configuration. Omitted arrays (`tools`, `apis`, `prompts`, `resources`, `permissionSets`) are cleared, so include the complete arrays — clearing `permissionSets` this way also rewrites the `pset:` grants that referenced the erased sets. `relativeURI` can be changed but must remain unique per account. via PUT /v1/mcpservers/{_id}

Bulk assign MCP server access to end users -- Assigns this server's capabilities to up to 100 end users in one request. For each end user, the grant for this server is replaced with the supplied capabilities; grants for other MCP servers and wildcard grants are preserved. End users whose grants already match are counted as processed without a save. Processing stops at the first failure — the response then carries the entries completed before it, plus `errors`. Requires account owner or administrator access. via PUT /v1/mcpservers/{_id}/endusers

Bulk assign MCP server access to groups -- Assigns this server's capabilities to up to 100 groups in one request. For each group, the grant for this server is replaced with the supplied capabilities; grants for other MCP servers and wildcard grants are preserved, and the group's roles and members are not changed. Groups are updated in batches of five; processing stops at the first failure — the response then carries the groups completed before it, plus `errors`. Requires account owner or administrator access. via PUT /v1/mcpservers/{_id}/groups

Preview NetSuite import field mappings against sample data -- Resolves a NetSuite import's Mapper 1.0 field mappings against supplied sample records and returns the mapped NetSuite record — the body fields (`nlobjFieldIds`) and sublists (`nlobjSublistIds`) that *would* be sent — without writing anything to NetSuite. Handlebars expressions in the mapping are evaluated, so this is the way to confirm how a mapping resolves before running it live. This is a stateless dry-run of the mapping engine: no Job is created and no NetSuite record is touched. It is the NetSuite-mapping counterpart to `POST /v1/imports/preview`, which previews the full import pipeline; use this operation when you specifically want the resolved NetSuite field values. via PUT /v1/netsuiteDA/previewImportMappingFields

Subscribe / unsubscribe users to resource notifications -- Upserts a batch of notification subscriptions. Each item targets exactly one resource (`_flowId`, `_connectionId`, or `_integrationId`) plus a `subscribedByUserEmail`. `subscribed: true` creates (or keeps) the subscription; `subscribed: false` removes it. Returns a parallel array of per-item results — one entry per request item, in the same order. Each result carries `statusCode` (**201** when a subscription was created, **200** when updated or removed, 422 when a referenced resource doesn't exist) plus an `errors[]` array on failures. An empty request body returns an empty array. The body is a bare array (maximum 500 items). Each item must carry exactly one of `_flowId` / `_connectionId` / `_integrationId` / `_syncId`. The response is a per-item status array; referencing a non-existent resource fails that item with `statusCode: 422` but does not fail the whole request. via PUT /v1/notifications

Update current user preferences -- Updates user preferences for the currently-authenticated user. Only include fields you intend to change. via PUT /v1/preferences

Resume APIM -- Resumes APIM for the account after it has been paused or suspended. Production environment only. Requires `manage:license` permission (not `apim:operations`). Returns `204` even when APIM is not yet provisioned (no `orgId` on the user). via PUT /v1/resumeAPIM

Update a role -- Replaces the role's writable fields. Prefer resending the complete object — omitted fields are not preserved. Requires account owner or administrator access. via PUT /v1/roles/{_id}

Update a script -- Replaces a script's mutable fields. via PUT /v1/scripts/{_id}

Update a stack -- Updates a stack. Omitting the config object clears optional fields like `framework`. To rotate a server stack's system token, use `DELETE /v1/stacks/{_id}/systemToken` instead. via PUT /v1/stacks/{_id}

Create or update a global state value -- Sets the value for a global state key. Creates the key if it does not exist; replaces the value if it does. The request body must be a non-empty JSON object or array. Bare JSON primitives (strings, numbers, booleans, `null`) and empty containers (`{}`, `[]`) are rejected. This is an upsert — check the status code to distinguish create (201) from update (200). The response body is plain text, not JSON. If the state belongs to a specific export, import, or integration, use the resource-scoped endpoint instead. via PUT /v1/state/{key}

Rename or describe an item -- Updates an item's `name` and/or `description`. Renaming keeps the item's `_id` stable, so references from flows, exports, imports, and tokens survive. To move an item to a different folder, use `PATCH /v1/storage/items/{_id}/move`; to replace a file's content, use `PATCH /v1/storage/items/{_id}/replace`. via PUT /v1/storage/items/{_id}

Cancel a single sync job -- Cancels a specific sync job by id. Only jobs that are still in progress (`running`) can be canceled. Jobs already in a terminal state (`completed`, `failed`, `canceled`) cannot be canceled. To cancel all running jobs for a sync at once, use `PUT /v1/syncs/{_syncId}/syncJobs/cancel` instead. via PUT /v1/syncJobs/{_syncJobId}/cancel

Update a sync -- Replaces a sync's configuration. Send the complete desired state: omitted optional fields (`schedule`, `timezone`, destination details, `driftPolicy`) are cleared, not preserved. `_integrationId` cannot be sent — the integration is fixed at creation. Set `disabled: false` to enable the sync once its source, destination, datasets, and `historicDateTime` are configured; enabling an incomplete sync fails with `422 sync_not_enabled`. via PUT /v1/syncs/{_id}

Create or update datasets for a sync -- Creates and updates a sync's datasets in one batch. Each array item either creates a dataset (identified by `externalId`) or updates one (identified by `_id`); a single request can mix both. Updates fully replace each dataset's writable fields. The response body is empty — read back the saved datasets with `GET /v1/syncs/{_syncId}/datasets`. via PUT /v1/syncs/{_syncId}/datasets

Cancel all running sync jobs for a sync -- Cancels all currently running or queued sync jobs for the given sync. This is a bulk cancel that affects every in-progress job associated with the sync. If there are no cancellable jobs (all jobs are already in a terminal state), the request is rejected. To cancel a single specific job instead, use `PUT /v1/syncJobs/{_syncJobId}/cancel`. via PUT /v1/syncs/{_syncId}/syncJobs/cancel

Update a tag -- Updates the human-readable `tag` name for an existing tag entry. The short `tagId` code is immutable and cannot be changed. via PUT /v1/tags/{_id}

Update a template -- Replaces the template's fields with the values in the request body. Omitted optional fields retain their current values. `name` is required on every PUT, even if unchanged. via PUT /v1/templates/{_id}

Update a tool -- Replaces the tool configuration. This is a full replacement — GET the tool first, modify the fields you need, then PUT the full object back. Omitting a field removes it. `name` and `_integrationId` are required on every PUT. via PUT /v1/tools/{_id}

Update a trading partner connector -- Replaces a trading partner connector. This is a full replace and an upsert -- if no connector exists for the given ID, one is created. When `published` is set to `true`, the `supportedBy` sections are validated for required fields. via PUT /v1/tpconnectors/{_id}