Two integration platforms. Both promise depth, autonomy and AI. This page compares what each one actually requires of your team, across thirty-nine jobs.
Each line opens the row it came from, with the scenario and the documentation behind it. Read them sceptically: that is what the rest of this page is for.
Why the promises tell you nothing, in one analogy:
Two cars, both advertised as self-driving. One parks itself in your driveway. The other drives Philadelphia to Denver while you sleep. Same words on the brochure. Not the same product.
Same two words on both brochures. Two completely different products.
Integration platforms are harder: there is no test drive. Every vendor writes the same words: deep, autonomous, AI-powered, enterprise-grade. Words are free. You find out what you bought in month nine, when a customer reports a failed sync and you need to know exactly what happened. Or in year two, when the engineer who built it is gone.
So this is not a page of claims. It is a page of jobs. A real thing that has to happen. What happens on APIANT, step by step. What the same job requires on Celigo, in its own documentation's words.
Apply the same scepticism to us. Read the architecture, not the adjectives. And take three questions with you into every vendor conversation you have after this one:
After the AI has done the work, is there a representation a non-developer can open, read, and judge? Building something and being able to look at it afterwards are two different capabilities.
Jump to Capability 01, where it bites hardest → TEST 02Never accept a depth claim. Test it against the specific API you need: the private endpoint no catalog lists, the forty custom fields, the rate limit, the pagination quirk.
Jump to Capability 05, the uncatalogued endpoint → TEST 03Every AI gets something wrong eventually. The question is what, in the architecture, is positioned to catch a wrong result before your customer sees it.
Jump to Capability 18, the answer to it →These three tests run on every one of the thirty-nine capabilities on this page. By the third section you will be asking them yourself.
Integration work is where your roadmap goes to wait. Deals stall on a connector that does not exist yet, engineers get pulled off product to fix a sync, and a single "it didn't work for one customer last Tuesday" can absorb a week of senior time. Whichever platform you choose, you will live inside its architecture for years. This page shows you what each one actually requires of your team, job by job.
A note on method. Every vendor in this category claims depth, autonomy, and reliability, and you have no way to adjudicate competing claims. So this page does something else: it takes concrete jobs and shows what each platform's architecture requires to get them done. APIANT's side is a walkthrough of shipping capabilities. Celigo's side is derived from Celigo's own documentation, repositories, and pricing page, quoted where a quote beats a paraphrase. Where their design handles a job well, we say so.
How to read this page. Every row is one capability. Bright text is what you get on APIANT; muted text after the dot is what the same job costs on Celigo. Skim the thirty-nine takeaways and open any row that matters. Inside each: the problem that forced the capability to exist, a concrete scenario, how it goes on APIANT, and what the same outcome requires on Celigo. Skim the bold lines first. The argument is the pile, not any single row.
The reading is fine and we concede it. The cost sits on the agent surface, where the unit of change is the whole document: "upsert_* with an _id is a full replace ... omitted fields are cleared", their delete pre-flight is advisory by their own reference, and a single API response stops at 25 MB with the pagination left to you.
Everything on this page traces back to one design decision made years before AI could build integrations: what is an integration made of? On APIANT the answer is structured data, all the way down. That choice looked like an implementation detail for a decade. It is now the whole ballgame.
A new hire asks the AI to rework invoice mapping, or does it herself in twenty minutes. Either way, no engineer. Elsewhere, the reading is fine; on the agent surface the edit rewrites the whole document
Open the scenarioCode cannot be safely edited by a machine, inspected by a non-developer, or replayed with its state intact.
And that holds at every layer: the flow, the connectors inside it, each API operation, every mapping, every setting. All of it is structured data. That one choice is why a machine can edit it safely, a person can always inspect it, and a saved run can be replayed with its state intact.
Meridian, a field-services SaaS with 4,100 customers. In March, an AI built their QuickBooks invoice sync in a working session. In September, the engineer who supervised that session has left, and Dana, the new integrations lead (sharp, technical, not a developer), needs to change how invoice line items map for a segment of customers. The question that decides Dana's week: what did the AI actually hand Meridian in March?
Elapsed: about twenty minutes. No engineer involved. The March artifact and the September artifact are the same living thing.
What this costs you is not the reading. Dana can open a Celigo integration: flows, exports, imports and mappings are JSON resources, edited in place in the UI with no build or redeploy step in between, and their AI does not regenerate them either. Concede that plainly, because it is real: "When Ora makes a change, it stages it as a draft in Celigo for your review. Nothing is applied until you explicitly approve it. You can ask Ora, 'Show me exactly what will change' at any point to get a summary before approving" (docs.celigo.com/hc/en-us/articles/25951095481755-Celigo-Ora-overview, re-verified live 2026-08-26). Before you touch a piece used in several places, the editor tells you the blast radius: "a Proceed with caution banner appears at the top of the editor showing how many places use it."
The cost sits one layer down, in what a machine writes when it makes Dana's edit. Their agent reference states the unit: "upsert_* with an _id is a full replace. Read the resource first, change the fields you want, and send the whole document back, or omitted fields are cleared." The one element-level write verb is patch_flow, and its whitelist is five path families, /disabled, /name, /description, /schedule/*, /logging/*, which their own reference explains exists "so the agent can enable a flow or arm debug logging without the full-replace risk of upsert_flow. Unlisted paths return 422 Unprocessable Entity" (developer.celigo.com/mcp/tools, seen 2026-08-26). A field mapping is not among those five, so remapping invoice line items round-trips the whole import document, and a field the agent forgets to send back is a field that is cleared.
That write also leaves nothing behind to compare against. "integrator.io creates a revision when you perform a pull, revert or snapshot operation in an integration", so an ordinary save, an approved Ora change and an API upsert each create none, and their own best-practice page assigns the discipline to you: "Always take snapshots before making changes to critical integrations or set an automated backup frequency using the APIs." Where someone did take one, Celigo keeps it well: "All snapshots are saved indefinitely in integrator.io. You can revert to any snapshot you've ever created, regardless of its age." The line-by-line comparison against March exists when March was captured on purpose.
Both let an AI build the integration. The difference is what the AI hands you afterwards.
Quarter-end's 80MB file clears by 4am on the same path as a normal night. Elsewhere, eDI and fixed-width parsing stops at 50 MB, and a single API response stops at 25 MB with the pagination left to you
Open the scenarioIntegrations died on large payloads, and on formats the platform had not anticipated.
Every record, file, and API response flows through a single engine with a small memory footprint. The platform does not care what shape your data arrives in or how much of it there is.
Caldera Health, a 38-clinic group. Every night at 1am, their practice-management system exports the day's claims and inventory as one file. On a normal Tuesday it is 12MB. At end of quarter it is 80MB. The integration has to parse it, reconcile it against the billing platform, and post corrections before clinics open at 7am. Nobody is awake to babysit it, which is the point.
Corrections post by 4am. Quarter end is not an incident category.
The file half of Caldera's night is fine on Celigo and should be conceded in their words: "integrator.io generally imposes no practical limits to the size of the file you can process". Their exception table then cuts both ways around an 80MB nightly export. EDI and fixed-width parsing is capped below it, "Parsing individual EDI and fixed width files: The maximum limit is 50 MB", while XLSX and XML parse at "The maximum limit is 100 MB" each and generation of EDI and fixed width runs "up to 1 GB" (docs.celigo.com, seen 2026-08-25). Which of those a file meets is decided by the format it arrives in. Format breadth is real too: their webhook listeners accept XML, CSV, JSON, text, form-urlencoded, HTML, markdown and TSV, and their pricing page claims RESTful, SOAP, GraphQL and WebSocket APIs.
The ceiling that binds everywhere is on the API path, and it is a hard stop rather than a slowdown: "For HTTP-based exports in the Celigo platform (integrator.io), each API response is subject to a maximum payload size limit of 25MB (26,214,400 bytes). If this limit is exceeded, then a flow will fail with this error at the export step and stop any further processing of data." The documented remedy is work your team does against the source vendor's API: "Review the API documentation of your source application for pagination details... Add query parameters, for example, limit, pageSize." Underneath that, page size "default system value is 20" and "a page of data is automatically capped when it exceeds 5 MB", and for grouped records, "If a single group exceeds the page size, that group is discarded from the export, and an error indicating this issue is reported."
Reconciliation lookups carry their own number: "As a standard, integrator.io does not support lookup responses greater than 5 MB." Their documented route around it stages the oversized response as a file and pares it down in a second flow, and it is written for JSON lookups under 25 MB rather than as a general bypass. Credit the newest piece here, because it changes who supplies that staging store: their 2026.8.1 release shipped Celigo Storage, "a platform-managed place to store, organize, and browse files without external SFTP servers or S3 buckets", usable "directly inside flows, APIs, and tools as a built-in file provider" (seen 2026-08-25). The hop is still a hop, but it no longer has to be your FTP server.
Your syncs queue behind your own traffic, at your own domain, on a dedicated server pair from the entry paid plan. Elsewhere, the isolated instance and the custom domain are a separate offering, and a non-production environment starts at Professional
Open the scenarioShared infrastructure means shared rate limits, shared incidents, and commingled customer data.
A 41-branch credit union circles one line in its security review: confirm member data is not commingled with other tenants, and name the domain traffic terminates on. The board votes in nine days.
Your integrations run on servers that are yours, addressed at your domain, with nobody else's traffic in the queue. You can even shut them down.
Priya can get both answers from Celigo, from a different product than the one on the standard price list. Celigo documents the isolated instance: "Celigo Private Cloud provides you with fully private, isolated instances of the Celigo platform... You can set up a private cloud instance in your preferred data center", and it carries the hostname answer her committee circled: "Custom domain: You can define the custom domain for your Celigo Private Cloud dedicated instance." Concede that outright. What the same article says about the platform she would otherwise be buying is the cost. Its comparison table describes the shared offering as "Securely partitioned multi-tenant architecture" with "Resources shared across tenants", against Private Cloud's "Private data environment" with "Resources dedicated to your workloads", and Private Cloud is a separate engagement, "Fully managed by Celigo's experts". So the answer to the commingling line is a separate procurement with its own timeline, nine days out from a board vote. The dev-and-production half is an edition entitlement rather than a default. Their editions table meters enabled environments as "Environments: Production: 1" on Standard, "Production: 1, Non-production: 1" on Professional, and "Production: 1, Non-production: 2" on Enterprise, while their environments article says you can "Create up to 100 environments that you can switch between, enable, or disable as you need" (both seen 2026-08-25). Both sentences are Celigo's; the one that governs how many run at once is the table. Concede what the entitlement is not: Celigo's own recipe for changing a production flow safely does not require a second environment. It starts "1. Clone the integration you want to modify", with no environment named, and their open-sourced agent skill maps a backup before risky changes to a same-environment clone (Ora overview and celigo/ai, seen 2026-08-26).
Structurally invalid work is refused at build time, instead of surfacing later in production logs. Elsewhere, the checks are steps somebody chooses to run, and their own pre-flight is advisory by their reference
Open the scenarioA generated integration that is syntactically fine and semantically wrong reaches production, and nobody knows until customer data is wrong.
After a hail week, 6,200 claims queue up. The integration pushing approved amounts into payments compiled and deployed cleanly. Farmers on the phone tell the claims supervisor which field it wrote.
The AI's intent passes through a constrained schema, and the compiler rejects invalid structures at the door. Ask for something malformed and watch the platform say no.
What this costs Dee is that every documented check between a generated flow and the payment field is a step somebody chooses to take. Give Celigo the checks first, because there are several and they are good. Ora's changes never apply themselves: "When Ora makes a change, it stages it as a draft in Celigo for your review. Nothing is applied until you explicitly approve it." Their reusable tools carry typed contracts and "can be validated using mock input data before deployment." Their CLI runs static analysis "before you push to production", starts a test run and returns "stage-by-stage results", and pings a connection. Each of those is a human deciding to run it. Their Platform MCP guidance for a new flow is written as a convention rather than a gate: "New flows start disabled. Create flows with `disabled: true` and enable them only after the mappings and connections check out" (developer.celigo.com/mcp/tools, seen 2026-08-26). That is advice to the agent, enforced by the agent. Halvorsen's build compiled cleanly and deployed cleanly, which is exactly the case these mechanisms do not catch: a flow that is structurally valid and writes the estimate into the payment field. Where their reference does describe an automatic pre-flight, it says what the pre-flight will not do. On a delete, "the dependency pre-flight reports dependents only as advisory warnings[] and never stops the delete." The refusal their agent surface does document guards the shape of a write rather than the correctness of a build: patch_flow's "Unlisted paths return 422 Unprocessable Entity."
The asset your company accumulates is a library of inspectable building blocks that any successor can open, not a portfolio of codebases that each had exactly one fluent reader, who has since changed jobs.
Reaching an API their catalog does not carry is authored work: the universal HTTP connector, or a custom connector definition written as raw JSON through their API or CLI. Their own comparison table answers No on that route for automatic latest API version and prefilled query parameters, and live field discovery is documented for the named native adapters while HTTP-framework apps map from sample data.
Connector catalogs are where integration platforms compete in public, and it is the wrong contest. The integration a deal depends on is reliably the one no catalog lists. The real questions are time-to-new-connector, and how deep the connector goes once it exists.
A niche partner API becomes a working connector in one session, and the renewal survives. Elsewhere it arrives as a Node project, times forty clients. Elsewhere, an API outside the catalog means the universal connector or raw connector JSON, written from the vendor's docs
Open the scenarioThe integration the deal depended on was never in anyone's catalog, and the catalog vendor had no incentive to add it.
Northgate, a systems integrator with forty managed clients. Their largest client runs bookings on a regional platform nobody has heard of outside its niche. The endpoints that matter, membership holds and multi-site transfers, live in the partner API, behind an NDA, in no catalog anywhere. The client's renewal is conditioned on this integration existing within the month.
The connector exists in a working session. The renewal conversation changes subject.
When the API a deal depends on is absent from their catalog, closing that gap is your project, run against that vendor's API documentation. Celigo's catalog is "hundreds of application connectors, one universal HTTP connector, and one universal GraphQL connector" (docs.celigo.com/hc/en-us/articles/10841316566043-Choose-between-an-application-or-a-universal-connector, seen 2026-08-25). Two routes to an uncatalogued system are documented, and the second is worth conceding plainly: configure the universal connector by hand, or author a custom connector definition of your own as a raw JSON document through their API or CLI, "Create a custom HTTP connector definition from a JSON body (--file <path> or stdin). Celigo-managed connectors cannot be created this way; this is for your own custom definitions" (developer.celigo.com/cli/commands/http-connectors, seen 2026-08-26). What stays Celigo's is the shared catalog: the 550-plus Celigo-managed entries are read-only to customers, new entries in it arrive in Celigo's monthly release notes, we found no help-centre article documenting a workflow or a UI for authoring a definition of your own, and publishing one into the shared Marketplace runs through their 3rd Party developer program.
Their AI writes flows rather than connectors. Ora, in beta, can "Build real flows from plain language, with exports, imports, mappings, and schedules wired to your connections" (docs.celigo.com/hc/en-us/articles/47114270888475-Celigo-agentic-automation-2026-release-notes, seen 2026-08-25). Those artifacts are exports, imports, mappings, scripts and schedules built against connections that already exist, so an API the catalog does not carry is still authored rather than generated: by hand on the universal connector, or as that raw JSON definition.
What the generic path costs is printed in Celigo's own comparison table. "Automatic latest API version of resources and endpoints" reads Yes for the prebuilt Simple form and No for the universal HTTP and GraphQL connectors, and prefilled "Query parameters (export and import)" reads Yes then No the same way (same article, 10841316566043, seen 2026-08-25). The credentials carry over either way. Versioning, parameters, pagination and response paths come back to your team out of the vendor's API documentation, which is the work a connector exists to remove.
Five integrations clear their vendor portal paperwork in one afternoon, with the credentials landing straight in the vault instead of a spreadsheet. Elsewhere, the consent step asks your customer to allow Celigo access, in Celigo's own words
Open the scenarioOnboarding stalled for days on OAuth paperwork before a single record moved.
Brightline, a B2B SaaS company, is launching integrations with five systems this quarter. Each of the five requires Brightline to register an application on that vendor's developer portal first: create the account, fill the forms, describe the use case, set callback URLs, wait, copy the credentials somewhere safe. It is nobody's job, so it becomes the bottleneck for everybody's job.
Five portals, one afternoon, zero credentials in a spreadsheet.
Credential onboarding can start inside your product, and the consent moment introduces your customer to your supplier. Concede the storage and the API route plainly: "Celigo securely stores the customer's authentication token in an encrypted iClient", secrets come back masked as "******" on API reads, and a partner's customer-facing app can drive the whole flow, fetching an authorizationURL through "GET /v1/connection/:_connectionId/oauth2" and "passing the alternate URL of your choosing in the oauth2RedirectUrl field" (docs.celigo.com/hc/en-us/articles/16770326386971-Create-an-OAuth-2-0-connection-in-Celigo-via-a-third-party-portal, seen 2026-08-25). Their 2026.3.1 release notes ship this for exactly this audience: merchants are "redirected back to the partner's application after completing third-party authorization, instead of landing at the Celigo platform sign-in page", a change "designed specifically for embedded and customer-facing OAuth flows" (docs.celigo.com/hc/en-us/articles/47059564417947-Celigo-platform-2026-3-1-release-notes, seen 2026-08-25).
What the same article documents mid-flow is the part a partner does not word: "The customer enters their credentials and is then asked to allow Celigo to access their account and related data" (same article, 16770326386971, seen 2026-08-25). That sentence arrives at the moment your customer is deciding whether to trust the connection.
The paperwork ahead of that screen is also yours. On the custom OAuth path, their iClient schema describes the client ID as coming "from the provider's app registration" and the client secret as a value you re-send to keep (developer.celigo.com API reference, seen 2026-08-25), so registering an app with each vendor, and holding its secret, is work done in that vendor's developer portal before the first record moves.
An onboarding call maps forty-one custom fields and a dropdown their admin invented, because the connector reads the customer's live tenant. Elsewhere, live field discovery is documented for the named native adapters; HTTP-framework apps map from sample data
Open the scenarioField mappings built against documentation break on contact with a customer who renamed things and added forty custom fields.
A 60-store outdoor retailer is onboarding onto a loyalty integration. Their CRM has been customized for nine years: forty-one custom fields, two renamed objects, and a "member tier" dropdown whose values exist nowhere in any documentation, because their admin invented them. The mapping screen has to show their CRM, not the CRM in the manual.
The onboarding call maps forty-one custom fields without a single "we'll get back to you."
Whether the mapper reads your customer's live system depends on which class of connector their app landed in, so the answer changes app by app. On the named native adapters it is documented and real, and we concede it: on a Salesforce import, "In the drop-down list, you can see all of the standard and custom sObjects. Click the Refresh button to fetch the latest record types in your Salesforce account" (docs.celigo.com/hc/en-us/articles/360052223752-Import-data-into-Salesforce, seen 2026-08-25), and their Platform MCP get_schema returns "native application metadata (record types and fields)" when given "a NetSuite or Salesforce connection" (developer.celigo.com/mcp/tools, seen 2026-08-25).
For the HTTP-framework majority of the catalog, Mapper 2.0 documents a different source of truth. The source side is "Input - source records: The full sample data from your source application", with a Refresh button that exists "to display recent changes to your source sample data" (docs.celigo.com/hc/en-us/articles/4536629083035-Mapper-2-0, seen 2026-08-25). On the destination side of "an HTTP/REST-based connector", the documented action is "Auto-populate destination fields to automatically generate the destination JSON structure with the destination app's expected field names"; where those names are read from is not stated on the page.
We found no article documenting enumeration of a customer's live custom fields for an arbitrary HTTP-framework app, having searched the connector-choice article, the HTTP export and import articles, Mapper 2.0, the multi-field mapping article and the Platform MCP tool reference. So for the customer who renamed things and added forty custom fields, on those apps the mapping is built and maintained from sample payloads your team supplies rather than from a read of that customer's account.
Every API gets a vetted way of announcing changes, so records stop going missing or arriving twice. Elsewhere, registering and retiring each subscription stays work in the vendor's own control panel
Open the scenarioEvery vendor's API announces change differently, and picking the wrong mechanism means missed or duplicated records.
Nine carrier systems, 1,400 load tenders a night. One feed replayed a status it had already sent and two trucks went to the same dock, so the night dispatcher now reconciles the tender log by hand.
Polling for new records, polling for new-or-updated, manual webhooks, self-registering webhooks, service webhooks with event filtering, and long-lived protocol listeners. Six vetted patterns; the AI picks the right one per API.
Every vendor announces change its own way, and on Celigo the vendor-side half of each subscription stays a hand-run task in someone else's control panel. Their setup article is explicit about the split: "Setting up webhooks requires two steps: 1. Configure a webhook in the source application... 2. Create a webhook listener in the Celigo platform...", and the listener's address travels by hand, "You can then share this URL with the webhook provider by entering it in the provider's user interface or API. Each webhook provider has a methodology to configure a destination URL where the webhook will send data" (docs.celigo.com/hc/en-us/articles/360015827372-Create-webhooks, seen 2026-08-25). Turning one off is the same trip in reverse: their webhook listener introduction puts stopping the data "by disabling the webhook within your source application" (docs.celigo.com/hc/en-us/articles/49753735918747-Introduction-to-webhook-listeners, seen 2026-08-25). The listening side is current and hardened, and we concede it. Their 2026.4.1 release added "Set rules for detecting a webhook challenge", "Handlebars AFE available for building HMAC webhook verification" and "Flexible token verification in body, headers, and query parameters" (docs.celigo.com article 47794963679131, seen 2026-08-25), and scheduled delta exports carry agent-callable backfills, "export.startDate / export.endDate override the delta window for backfills" (developer.celigo.com Platform MCP reference, seen 2026-08-25). Ingestion is bounded and published: a leaky-bucket limiter "with a capacity of 1,000 tokens and a refill rate of 300 tokens per second, supporting up to 1,080,000 requests per hour" (docs.celigo.com article 49753735918747, seen 2026-08-25). So the mechanism per vendor is there. What accumulates across a fleet is the bookkeeping around it: one subscription per vendor per customer to register, verify and later retire, each in a different vendor's admin screen, and each a place where a missed step shows up later as records that never arrived.
Ask the AI to set the vendor's limit, or type it once yourself, and every account sharing that API queues against one 185-calls-per-10-seconds budget. Elsewhere, the concurrency ceiling is your edition's number, not the vendor's
Open the scenarioA vendor's rate limit is the real constraint on a multi-location sync, and hitting it corrupts a run.
310 branches sync to one supplier API that allows 120 calls per 10 seconds. A rate-limit rejection killed the nightly refill batch partway through, and branch queues opened at 8am short of data.
Type a vendor's limit once and the platform enforces it across every automation and every account that touches that API, with queueing and backoff. One deployment runs 232 locations against a single 185-calls-per-10-seconds budget with the platform queueing and backing off rather than each flow deciding on its own.
How hard you may drive a vendor's API on Celigo is a number set by your edition, and it governs one connection inside one account. Within that connection the engineering is good and we concede it plainly: "every connection resource is backed by its own dedicated FIFO queue... The number of messages in the FIFO queue that can be processed in parallel is controlled by the Concurrency level setting of each connection," and their worked example is the multi-location case itself, "You can precisely match the governance dictated by the ERP... by simply setting the concurrency level on the connection to 25." Recovery is automatic as well: "When rate limits are hit, the platform lowers concurrency to 1 and retries with a delay that doubles after every attempt (1 min, 2 mins, 4 mins, up to 1024 mins) until the Target concurrency level is reached again" (docs.celigo.com, seen 2026-08-25). The ceiling on that queue is not set by the API you are calling. "The maximum concurrency level varies by Celigo edition", and their editions table sets the number per edition: 25 on Standard, 50 on Professional as an add-on only, and 50 on Enterprise, beside base entitlements of 20 flows and 3 endpoints on Standard and Professional (Celigo platform editions, article 43232045459611, seen 2026-08-25). Their capacity terms describe those entitlements as base capacity a customer can increase, and flows have been counted on actual usage since late 2025, but the concurrency number stays the edition's. Enforcement follows the connection resource. Sharing one vendor's budget across several flows means routing those flows through the same connection, which is their documented pattern; the unit of governance is a connection inside an account.
Time-to-new-connector is measured in working sessions, not sprints, and every connector you add, however obscure the API, joins the same inspectable library instead of adding one more codebase to the pile someone must maintain.
Most of the logic act is parity and we say so, including shared logic that propagates everywhere it is referenced when it is fixed once. What their documentation bounds is narrower: hook code runs on a 4-second clock per invocation at every tier, with longer work moved to a server you host, and each new Ora chat starts with no memory of the last.
Field-to-field mapping is the demo. The business is nested rules, parallel work, digests, approvals, waits, and the awkward requirement that makes your operation yours. The question for any platform: does that logic fit inside the model, where it stays visible and testable, or does it spill into code and patterns your team hand-builds?
214 stores get overnight prices in minutes, and the 6am report fires once. Elsewhere, the completion join is bookkeeping you keep yourself
Open the scenarioProcessing two hundred locations in series took hours. In parallel, nothing knew when all of them had finished.
Launch N child runs in parallel, and the platform itself knows when the last one completes, so the "everything is done, now reconcile" step is a primitive, not a science project.
A 214-location convenience chain pushes overnight price updates. Every store must be updated in parallel (serially it takes past opening), and when the last store finishes, one reconciliation report must go to the merchandising director, listing any store that failed. The hard part was never the fan-out. It is knowing, reliably, that all 214 are done.
Prices land in minutes, the report is on the director's desk at 6am, and nobody wrote coordination logic.
Two hundred runs going out at once is achievable. Knowing the moment the last one came back is bookkeeping you keep yourself.
What their material documents is per-connection parallelism, the Concurrency level setting covered in the rate-limit row, and sequencing one flow after another: "If you want a flow to run immediately after another flow is complete... select the flow you want to run next from the Next integration flow list" (Daisy-chain flows, seen 2026-08-25). That is a chain, not a fan-out with a join.
Celigo does not document this. We searched the Flow Builder branching articles (7287177264795 and 8431287283995), Daisy-chain flows (5926335821211) and the multi-instance flow documentation (39669671915291). On that basis a hundreds-wide parallel run with a completion join is manual work rather than a platform behaviour.
Contact changes flow both ways on day one, without the overnight loop that rewrites one record 4,000 times. Elsewhere, loop prevention is flow design you write and maintain
Open the scenarioTwo systems updating each other trigger each other, forever.
Arrowe Physio, 22 clinics. Patient contact details must stay identical in the practice-management system and the marketing CRM, editable from either side. The failure mode is famous: the CRM update fires a webhook, the integration writes to practice management, which fires its webhook, which writes to the CRM, which fires again. By morning one patient record has been "updated" four thousand times and both APIs have rate-limited the clinic.
The sync runs both directions on day one, and "infinite loop" is not in the runbook.
Two systems that write to each other will re-trigger each other unless something stops them, and on Celigo that something is flow design you write and maintain.
One adjacent mechanism deserves credit and is not this. Their error engine "Uses trace keys... to find duplicates. When a record is successfully processed or a newer error occurs for the same record in a flow step, older errors are marked as Auto-resolved" (seen 2026-08-25). That collapses duplicate errors after a failure. It does not keep system A's write from firing system B's trigger.
Celigo does not document this. We searched their documentation for bidirectional-sync and loop-prevention material, the Create custom flows article (360025919171), the branching articles and Daisy-chain flows. On that basis, preventing an update loop between two systems is manual work, filters and hooks the customer writes, rather than a platform behaviour.
Customers get one 5pm summary instead of 400 pings, and nothing is lost when two runs land at once. Elsewhere, the digest is a template, an FTP endpoint and a run you remember to start
Open the scenarioCustomers wanted one daily digest, not four hundred notifications.
One Tuesday produced roughly 400 emails, and two of the largest accounts asked to be removed from notifications. The operations manager assembles the 5pm digest by hand, and she is away next week.
Four hundred events land all day; one clean summary goes out at 5pm. A dedicated primitive, safe under concurrency.
One digest a day is not a setting on Celigo. The built-in cadence is theirs: "Integrator.io checks for new, open errors and newly resolved errors every 15 minutes, then sends any necessary email notifications with a summary of new, resolved, and total open errors" (seen 2026-08-25), and their error-notification documentation describes no control over that cycle. A cross-flow consolidated report does exist, and their own article says how it runs: "This is a custom flow and needs to be run manually... The consolidated errors report will be saved to an FTP server," with the guidance "We recommend that you run this flow with a time duration of 2 to 3 days each time you run the flow" (seen 2026-08-25). So the digest is reachable, at the price of a marketplace template you install, an FTP endpoint you supply, and a run somebody remembers to start each period.
A three-day follow-up needs one system, not a separate scheduler for somebody to own. Elsewhere, a deliberate multi-day pause is scheduling you solve outside the flow
Open the scenario"Follow up in three days" required an external scheduler and a second system to maintain.
If the adjuster has not followed up within three days, the claim ages into a regulatory bucket with a penalty. The scheduler holding that wait missed 34 follow-ups, and the audit is in November.
A run can suspend itself for three days, or until next quarter, and resume with its state intact. One system, one place to look.
"Follow up in three days" stays a scheduling problem you solve outside the flow. The pause Celigo documents is involuntary, and it is well built: "An offline connection will automatically pause all flows using the connection... As soon as the connection starts working, all paused flows will automatically resume processing right where they left off" (seen 2026-08-25). What triggers it is a connection that has stopped working, not a step you place in a flow. Celigo does not document this. We searched their documentation for delay, wait and timer step material, the Flow Builder articles and the flow schedule documentation. On that basis a deliberate multi-day pause with automatic resume is manual work rather than a platform behaviour.
Refunds over $500 wait for a manager's approval while everything else keeps moving. Elsewhere, a per-record approval hold is a process you assemble yourself
Open the scenarioSome records must not sync until a person says yes, and the wait cannot block the platform.
After £48,000 of refunds in one night, anything over £500 needs a venue manager to say yes. Those requests now sit in a shared inbox chased by text, while every small refund queues behind them.
A run pauses on a queue; a person approves or denies from a link; the run resumes. Refunds over $500 wait for a manager, everything else flows.
A record that must not move until a person says yes waits in a process you assemble around the flow. Two nearby mechanisms will come up and neither is this. Their errors workspace lets you "manage error assignments" and the Platform MCP triage tool can "assign (by email)", which is triage of records that already failed. Ora's staged edits are approval-gated as well ("Nothing is applied until you explicitly approve it"), but that approves a configuration change, not a pending business record. Both seen 2026-08-25. Celigo does not document this. We searched their documentation for approval and human-review material, the "Handling custom form decisions within a flow" tutorial (360058898631), which is a settings-form pattern, and the error assignment documentation (10080012410651). On that basis a per-record hold that resumes on a person's decision is manual work rather than a platform behaviour.
A customer's 300-row mapping sheet becomes the configuration directly, with unresolved rows flagged, instead of a week of error-prone typing. Elsewhere, a mapping spreadsheet is hand-keyed, AI-assisted at best
Open the scenarioA customer's mapping requirements arrived as a 300-row spreadsheet, and hand-entering it was a week of error-prone work.
The field map arrived as a 300-row spreadsheet, and hand-keying it eats most of week one of four. Every keying slip surfaces later as a subscriber billed twice, and renewal season opens 1 October.
The 300-row file becomes the mapping, directly. The AI reads it, applies it, and flags the rows that do not resolve.
A 300-row mapping spreadsheet gets keyed in. Their material has two adjacent things and we should name both. Ora accepts files as chat context ("Select +, then choose Upload file, or drag and drop a file into the text area"), and "Auto-map destination fields using Celigo Ora" exists as an assist inside the mapper (both seen 2026-08-25; Ora is beta). Neither article documents turning a customer's mapping definition into working mappings. Celigo does not document this. We searched their documentation for spreadsheet and CSV mapping-import material, the Data loader documentation (226949488, which loads data records rather than mapping definitions) and the Mapper 2.0 articles (4536629083035). On that basis converting a mapping spreadsheet is manual work in the mapper, AI-assisted at best, rather than a platform behaviour.
Turnover stops costing you the same debugging twice: a quirk solved once stays solved after its author leaves. Elsewhere, a new Ora chat starts with no memory of the last, and your own lessons have no store it reads
Open the scenarioThe same API quirk was rediscovered every time, by whoever drew the short straw.
The engineer who holds the loan-status lookup table in his head has given notice. 11 live integrations rest on knowledge that was never written down, and his replacement starts in three weeks.
Mappings, transforms, gotchas, and templates are saved and searchable. The AI checks the library before building, so the Mindbody pagination quirk gets solved once, ever.
The reference material their AI reads is Celigo's, about Celigo. What your team learned about your customer's API last quarter has no documented place to live where that AI will find it. Their half of this is well done and we credit it. The Platform MCP server ships an "Error pattern reference: Common error codes, their causes, and typical resolutions", a "Product glossary", a "Tool usage guide" and an "Account architecture model: How to read an account as a dependency graph: resource hierarchy, blast radius, and risk", and both the MCP server and the CLI answer questions against their documentation ("search_knowledge_base", "docs search"), seen 2026-08-25. On continuity, their Ora documentation states: "Each Ora chat session is independent. When you start a new chat, Ora has no memory of previous sessions" (seen 2026-08-25; Ora is beta on a monthly release cadence). Concede the part of the same page that softens it, because a reader will find it: past conversations are browsable and resumable, "All conversations are available according to your data retention plan (calculated from each conversation's last used date), and you can continue querying Ora from any of them" (docs.celigo.com/hc/en-us/articles/25951095481755-Celigo-Ora-overview, re-verified live 2026-08-26), and Ora "draws on context from your Celigo account" on every turn. What we found no article documenting is a customer-writable knowledge store their AI consults. We searched the Platform MCP resources list and the Ora overview. On that basis the quirk your engineer solved last quarter is recorded outside the platform, manual work rather than a platform behaviour.
A genuinely odd requirement ships without waiting on a vendor release, and everything around it stays readable. Elsewhere, hook code runs on a 4-second clock at every tier, and longer work moves to a server you host
Open the scenarioOccasionally a requirement is genuinely outside any data model, and waiting for a platform release is not an answer.
A 1987 mainframe demands a check digit no mapping tool expresses. The systems analyst has a 30 September council deadline and a $140,000 quote for middleware to cover that one field.
When you truly need arbitrary logic, a script slots in as one node of the structured document. Code is an optional leaf inside a data document, never the foundation. Everything around that leaf stays visible, testable, and machine-editable.
When a requirement falls outside the data model, the code you write to cover it runs against a stopwatch, and their own page says no edition lifts it: "Hook scripts run under a 4-second processing limit per invocation and a 120-second cumulative API call limit per flow run. These limits apply regardless of subscription tier and can't be adjusted." [docs.celigo.com article 20228312523931, seen 2026-08-25] Configurable timeouts do exist elsewhere on the platform, and the same page scopes them away from this code: "Configurable API timeouts apply to API Builder only and don't affect hook or transformation scripts." The documented route past the clock is infrastructure your team runs. Their text, in the same note on that same article: "If you need a longer execution time, consider using a stack (a server-side Node.js hook) instead of a script", and their CLI reference describes stacks as on-premise bridge runtimes that "run data-residency-sensitive flows inside your own network", where "Stacks host the execution environment (server or AWS Lambda) that integrator.io invokes for custom code, hooks, and wrappers" [developer.celigo.com/cli/commands/stacks, seen 2026-08-26]. So the exception path is code on a 4-second clock, or a server your team hosts, secures and patches.
Logic complexity does not convert into code ownership. The awkward rules that make your business yours stay inside a model that your people can read, your tests can cover, and your AI can safely change.
Their test and debug surface is real, including stage-by-stage test runs from the CLI. The remainder is narrow: the rare branch is reached by hand-authored mock records, a test run sees one page of data, a backfill re-queries the source through export.startDate and export.endDate so what comes back is the state the source holds today, retry eligibility runs to "the default last 30 days or upto 180 days based on your subscription", and CLI and MCP writes default to full access on the token.
"It worked when I tried it" tests one path out of eleven. The other ten are where customers live. This act is the answer to the third standing test: when the AI, or a person, gets something wrong, what in the architecture catches it before production data does?
Prove a path that fires once a year works today, not in nine months. Elsewhere, the rare branch is reached by hand-authored mock records, and a test run sees one page of data
Open the scenarioThe branch nobody could trigger on demand was the branch that broke.
United Harvest, a federation of 90 food banks. Their donation pipeline has a branch that fires only for tribute gifts carrying a matching-gift employer code, which in practice happens in the last week of December. It is March. The integration was just modified. The question: how do you prove the December branch still works, in March, without waiting nine months or faking an entire donation flow end to end?
The branch that used to be tested by December is tested by lunch.
Forcing a rare branch to run is data authorship, done by hand, per branch. Their test mode is real and worth crediting: "Enter mock data manually or make calls to your source and destination apps to retrieve live source data and response data to use for testing purposes", and you can "review the processing behavior of each flow step option (transformation, mapping, filter, or hook)" [docs.celigo.com article 16837144477339, seen 2026-08-25]. Starting one is agent-callable on their CLI: "test-run <id>: Start a test run and return stage-by-stage results" [developer.celigo.com/cli/commands/flows, seen 2026-08-26].
What steers a run down a given path is the input you supply, and supplying it is a stated prerequisite on that same article: "Before you can perform accurate test runs, you must first provide mock output data for the source flow step(s) and any lookup flow step you want to test. You must also provide mock response data for each destination import flow step." Filling that from the live system is a real call, in their words, on the Populate with > Live data option: "Clicking this button makes a live call to the import application and creates a record in the destination app."
One published bound sits on the run itself: "Test runs process only the first page of data." A branch that shows up on the second page of a source is therefore reached by composing the record that reaches it, not by selecting the path.
The AI tests every branch before it ships. Not the branches somebody thought to write payloads for. Every branch.
Ship a one-line fix across 300 accounts knowing exactly which customers it touches. Elsewhere, impact analysis stops at the account boundary, and a fleet push answers 200 with no per-account outcome
Open the scenarioA one-line connector fix silently changed behaviour for three hundred accounts.
Beacon, a B2B SaaS vendor with 300 customer accounts live. A date-format bug is found in a shared connector operation. The fix is one line. The question that separates a routine Tuesday from an incident: which automations call this operation, on which customers' accounts, and which of them are relying on the buggy behaviour without knowing it?
The one-line fix ships with a printed list of everyone it touches, so the dependents are known before the edit rather than after it.
Inside one account, the question of what a change touches is answered well. Across a base of installed customers, the push goes out and the report does not come back.
Credit the within-account half in their words: Ora can "Map blast radius across your entire account before you make a change" [docs.celigo.com article 47114270888475, seen 2026-08-25], a documented prompt runs "If I delete the connection '<connectionName>', what breaks? Simulate the impact and list affected resources", and their CLI carries "dependencies <id> (alias used-by): List resources that depend on this integration" [developer.celigo.com/cli/commands/integrations, seen 2026-08-26]. Credit the fleet push too. For a partner shipping an Integration App one call reaches every installation, PUT /v1/connectors/{_id}/update, which "Pushes an update to all (or specified) installations of this connector. Triggers the connector's updateFunction on each target integration", and the base is enumerable through GET /v1/connectors/{_id}/installBase, which "Returns the list of accounts that have installed this connector."
What that call hands back is a status line. The documented success response is "200: Update pushed." with no content schema, and the surface is gated: "These endpoints are only available to Celigo Partners." We searched all eight documented Connectors paths and their response schemas, the CLI connectors command page, and the publish article (docs 360048995431). On that basis, learning what a shared fix did inside each customer account is re-inspection account by account, manual work rather than a report the push produces. [developer.celigo.com/api/api-reference/connectors, seen 2026-08-25, re-verified 2026-08-26]
You know a change is fully tested because the platform counts untested paths, not because someone felt confident. Elsewhere, path coverage is not measured, so what was tested is a record your team keeps
Open the scenario"It worked when I tried it" tested one path out of eleven.
The claim-intake automation has eleven branches. The claims supervisor signed off on a mapping change because the hail path ran clean in test. Harvest starts in five weeks and ten were never walked.
The platform knows every branch an automation has and tracks which ones testing has actually exercised. Coverage is measured, not assumed. A change ships when the walk is complete.
Whether every path in a flow has ever been exercised is a question the platform does not answer, so the evidence that the rare branch was tested is whatever your team wrote down and remembered. Celigo does not document this. We searched Debug a flow in test mode (article 16837144477339), Debug flow steps (4416800334235), Test and debug your tool using tool builder (47489785915803), Test and debug your API using API builder (33739112410011), both branching articles (7287177264795 and 8431287283995), and the CLI flows and account command references. On that basis it is manual work rather than a platform behaviour. The nearest published mechanism checks configuration rather than coverage: their CLI's account lint "Runs anomaly-detection rules against the index and prints issues with severity, rule, resourceType, resourceName, and message" [developer.celigo.com/cli/commands/account, seen 2026-08-26]. That reports rule violations in what is built, not which branches have run.
Answer a month-old complaint by re-firing the exact message that failed. Elsewhere, backfills re-query the source, and replaying stored webhook deliveries is not documented
Open the scenarioTesting a webhook-triggered flow meant asking a customer to go and click something in their system.
An undocumented rate-confirmation payload began dropping accessorial charges worth 18,000 euros a week. The fix is written. Validating it means asking a shipper to re-tender loads they already moved.
Every webhook ever received is a test case. Re-fire last month's payload against the fixed automation and watch it process, without asking a customer to reproduce anything.
Re-running a month of traffic means asking the source system for it again, and for the records that failed there is a clock on how far back you can reach. The backfill itself is documented and agent-callable, and we credit it: run_flow takes an optional body that "targets the run: export.startDate / export.endDate override the delta window for backfills, and _exportIds runs only specific source exports". Failed records keep an editable payload, get_flow_error_retry_data returning "The stored retry snapshot for one error (retryDataKey)" and update_flow_error_retry_data able to "Full-replace that snapshot to fix a staged payload before retrying" [developer.celigo.com/mcp/tools, seen 2026-08-25, re-verified 2026-08-26]. Two consequences follow from their own text. A backfill re-queries the source, so what comes back is the state the source holds today, not the payload that arrived then. And the retry path is windowed: "You can retry open errors if the record timestamp is within the default last 30 days or upto 180 days based on your subscription" [docs.celigo.com article 16182564553371, seen 2026-08-25], which puts last month at the edge of the default. For a webhook-triggered flow the delivery is the thing that cannot be re-queried, and Celigo does not document replaying stored webhook deliveries. We searched Introduction to webhook listeners (49753735918747), Debug a webhook (49753774182555) and Manage webhook export for bulk requests (15230882523931). On that basis, re-running last month's webhook traffic is manual work, asking the source system to send the events again, rather than a platform behaviour.
An agent works production with full read, and the actions that reach a fleet return a plan a human approves. Elsewhere, ora's gate is in-product, while CLI and MCP writes default to full access on the token
Open the scenarioThe fastest way to an outage is a confident agent with production credentials.
An AI agent is to work directly on production integrations posting 2,600 ACH transactions a night. One mis-sequenced deploy at 11pm is a reportable incident by the time branches open.
The AI inspects production freely and changes nothing without an explicit, human-confirmed deploy step. Autonomy without the blast radius.
The approval gate lives in the chat window and in a profile on the operator's machine, not in the platform's standing posture toward production. In product, Ora is genuinely gated and we credit it: "Ora draws on context from your Celigo account, proposes changes as reviewable drafts, and applies them only after you explicitly approve", with automatic application an opt-in per integration, "On the cloned integration's Admin tab, enable Allow Ora to apply changes automatically" [docs.celigo.com article 25951095481755, seen 2026-08-25, re-verified 2026-08-26]. Their CLI publishes three permission modes, and they should be conceded: "full (default)" can "create/update/set/delete all resources", "operate" is "read + edit a narrow allow-list of fields (disabled, debugUntil, schedule, autoResolveAt)", and "read" is "read only", where "any mutation is rejected before the request leaves your machine" [developer.celigo.com/cli/getting-started/profiles, seen 2026-08-26]. Two things follow from their own text: the default is full, and read mode is enforced where the command is typed. The MCP surface documents no equivalent mode. Their reference states "Writes act on your real account, and delete_resource never blocks", that "the dependency pre-flight reports dependents only as advisory warnings[] and never stops the delete", and puts the instruction on the caller, "Confirm the agent's plan before any write", with tool annotations so clients "can ask for confirmation before destructive calls" [developer.celigo.com/mcp/tools, seen 2026-08-25, re-verified 2026-08-26]. Scoping is the credential's job, and custom-scoped tokens are documented, but so is the warning: "A full-access token can read, change, and delete everything in your account. The server acts with your token's permissions." [developer.celigo.com/mcp/connect, seen 2026-08-26]
Test coverage is a property of the platform, not of your team's imagination for payloads. Across months of daily production builds on APIANT, no hallucinated mapping, structure, or logic has been observed reaching production. That is what the compiler and the branch walk are for.
Concede the fleet push up front: PUT /v1/connectors/{_id}/update pushes to every installation of a connector, or to a named subset. What their reference leaves with you is the outcome, since the documented success response is "200: Update pushed." with no body; the one-build-many-variants mechanism is gated to Professional and Enterprise inside a single account, and ILM snapshots are kept indefinitely with applying the revert a person's job in the UI.
Building the integration once is the demo. Running it for three hundred customers, each configured differently, each on their own credentials, all needing the same fix on the same day, is the business. This act is where per-customer platforms and per-fleet platforms part ways.
Ask the AI to ship the fix and it deploys to 232 linked accounts on your confirmation of the plan it returns. Elsewhere, one build, many variants, on Professional or Enterprise and inside one account
Open the scenarioEvery customer wants the same integration configured differently, and cloning it per customer creates hundreds of divergent copies.
One codebase carries the logic. Settings (which fields sync, which features are on, time zones, branding) vary per customer. The same automation serves a single-location studio and a 232-location franchise.
A fitness franchise with 232 locations runs a booking-system-to-CRM integration at every site. Each location has its own booking credentials and its own quirks (time zones, membership names, feature toggles), but the logic is identical everywhere. Today, a fix needs to reach all 232 before the evening class rush. This is a real deployment shape running on APIANT now.
Fix at 2pm, fleet-wide by 2:15, evening classes uneventful.
If your customers hold their own accounts, the mechanism Celigo markets for this exact problem does not reach them, and inside one account it is an edition feature. Their multi-instance article is pitched at the scenario in the row: "Traditionally, you'd need to create one integration and clone it 500 times. With multi-instance flows, you can create one integration, add 500 instances, and customize each instance quickly... each instance can be uniquely tailored to match each customer's specific needs" (docs.celigo.com/hc/en-us/articles/39669671915291-Learn-more-about-multi-instance-flows, seen 2026-08-25). Concede how much an instance may vary, because their page is generous about it: "You can override connections, exports, import properties and mappings, branching configurations, and flows", and where an import or lookup cannot be swapped outright, "you can edit various fields within these resources" (same article, 39669671915291).
The same article carries the gate, "This feature is only available in Professional and Enterprise editions," and instances are generated from a base flow inside a single account. One published constraint on the base flow itself: "Multi-instance base flows cannot be run manually or scheduled."
When the customers live in accounts of their own, the product changes: the documented route is an Integration App, and publishing one requires acceptance into a program. "Contact your Celigo account executive or partner manager to sign up for our 3rd Party developer program... If accepted into the program, you will be granted permission to publish templates and integration apps" (docs.celigo.com/hc/en-us/articles/360048995431-Publish-or-unpublish-templates-and-integration-apps, seen 2026-08-25), followed by a demo to the Celigo product team before a Marketplace listing.
One incoming request lands in the right location's account, on that location's own credentials, with hundreds of accounts behind the curtain. Elsewhere, no documented parent-to-child routing; each customer account is entered on its own
Open the scenarioThree hundred locations cannot each hold their own credentials and configuration.
Kestrel Pharmacy Group's 178 branches share one refill endpoint, with the store code buried in the payload. The first batch lands at 6:40am, and every message has to reach the branch that can fill it.
A parent account governs hundreds of children. A webhook hits the master, which routes by location to the right child, which processes with its own credentials. The caller never knows there are 232 accounts behind the curtain.
A parent that dispatches work into three hundred child locations is something you would assemble and then maintain yourself. What Celigo publishes is a flatter model: accounts, environments, and per-integration user grants, with "three types of user roles in the Celigo platform: account owner, administrators, and users" and Manage all, Monitor all or Custom access grantable account-wide or per integration (docs.celigo.com, seen 2026-08-25). Integration Apps do carry an "integration child" unit, but it appears as a subscription line item: "you can request an upgrade to your integration application subscription, edition, or integration child" (seen 2026-08-25). Celigo does not document this. We searched the Manage accounts documentation category (5914252754331), the invite-users article (360053966912), the environments articles, the user-roles article (115003929872) and the Integration App upgrade article (11432858485659). On that basis, a parent account routing work into child locations is manual work rather than a platform behaviour: each account is entered on its own, and the credentials and configuration sit where the sign-in is.
A week of hand-updating becomes one confirmed action, staged if you prefer, with every prior version kept for a redeploy. Elsewhere, one call reaches the install base; what landed where is not reported back
Open the scenarioShipping a fix to two hundred customers by hand takes a week and misses some.
A payment provider renamed a field overnight and refunds have been failing since 05:00. The head of support has the fix in hand and 186 venue environments to get it into before Friday's 10am on-sale.
Deploy or upgrade a codebase group across the fleet in one action, atomically, with staged rollouts when you want caution and instant rollback when you need it.
Celigo partners have a genuine one-call fleet push, and it belongs in the first line rather than the small print: "Pushes an update to all (or specified) installations of this connector. Triggers the connector's updateFunction on each target integration. Partner-only endpoint" (developer.celigo.com API reference, seen 2026-08-25), with "_integrationIds... Optional list of specific integration IDs to update. Omit to push to all installations" for canarying, the same verb on the CLI ("push-update <id>: Push an update to a connector's install base"), and the install base enumerable beforehand ("Returns the list of accounts that have installed this connector"). What comes back is where the confirmation stops. The documented success response is "200: Update pushed." with no content, so the rollout reports no per-account outcome, and what the update does on each install is code you write and host: "updateFunction... Function invoked to apply connector updates to existing installations", running on "_stackId... Stack that hosts the connector's installer and lifecycle functions" (seen 2026-08-25). Reversing a bad push means writing the reversal into that function and pushing again; the Connectors API's eight paths include no rollback, downgrade or version registry. The surface is also gated rather than sold: "These endpoints are only available to Celigo Partners" (seen 2026-08-25), reached through the 3rd Party developer program and a product-team demo. Outside it, upgrades arrive per account and the customer starts them: Admin tab, then Subscription, then Upgrade, where "integrator.io walks you through any manual upgrades required by the integration app developer", with the prerequisite "Ensure that all connections are online for the version upgrade to push through" (seen 2026-08-25).
Ask the AI what changed and it diffs the bad version against the last good one; the reversal is a redeploy of that kept version to the fleet. Elsewhere, snapshots kept indefinitely, and applying a revert stays a person's job in the UI
Open the scenarioA change made things worse, and there was no way back.
The night before enrolment week, the integrations lead changed how guardian contacts are matched. Registrars in six districts are seeing siblings collapsed into one record, and offices open at 07:30.
Every committed version is kept, any two versions diff against each other, and rollback restores a known-good state fleet-wide in one action.
The history is strong and the undo is a person's job. Concede the history plainly: "All snapshots are saved indefinitely in integrator.io. You can revert to any snapshot you've ever created, regardless of its age" (docs.celigo.com, seen 2026-08-25), reviewed on a diff screen where, for APIs, "individual fields are highlighted as added, updated, or removed, rather than showing the entire API as a delete-and-add pair", and deletions are recoverable by an agent for 30 days through the recycle bin API. A version exists where somebody deliberately made one. "integrator.io creates a revision when you perform a pull, revert or snapshot operation", ordinary saves and API writes create none, and their best-practice page assigns the discipline to you: "Always take snapshots before making changes to critical integrations." Their AI sits outside that net, in their words: "Ora does not take a snapshot before modifying a resource, and there is no built-in rollback", and "If Ora modifies a production flow and the result isn't what you intended, there is no built-in way to revert the changes" (Ora overview, re-verified 2026-08-26). Applying the rewind is where the machine surfaces stop. Their API reference states that a snapshot "is the only revision type that can be created via the public API; pull and revert revisions require the Celigo UI"; their CLI reference states "ILM commands are UI-only. revision-apply, revision-cancel, revert-*, pull-*... are intentionally not exposed as CLI commands. Use the UI for those"; and the Platform MCP catalog carries no revision or revert tool (all three re-verified 2026-08-26), while their headless page markets "complete feature parity with the UI". An agent can lay the restore point down and can undo its own deletion; rewinding a modified production integration is done by a person in the Revisions tab.
A new account is created, linked, and inheriting shared logins, settings and automations in one operation, with no onboarding checklist to work through. Elsewhere, one guided install, performed by the customer inside their own integrator.io account
Open the scenarioOnboarding a customer was a manual checklist.
Twelve newly acquired hotels each need their management system talking to the group's revenue and CRM stack before the 1 October rebrand. The onboarding checklist runs 31 steps per property.
A new customer account is created, linked into the hierarchy, and inherits shared connections, settings, and automations immediately. Provisioning is an operation, not a project, and the AI can run it.
Onboarding is one guided operation, and the customer runs it inside Celigo's product, in an account they hold with Celigo. Credit the install experience as documented: "Once published, navigate to the integrator.io Marketplace to see your new listing with your company's name as the author. The customer experience will be the same as when installing any Celigo-published template or integration app from the Marketplace" (docs.celigo.com/hc/en-us/articles/360048995431-Publish-or-unpublish-templates-and-integration-apps, seen 2026-08-25), and trials are self-serve: "Clicking Start free trial initiates the integration app's setup... Once the term has ended, the flows are disabled." What the operation is not is a call you make on the customer's behalf. The install runs in their integrator.io account, the entitlement is provisioned per account ("you can add, edit, or delete a license for each user account"), and the agent-side install verb acts on the account whose token you hold. Their catalog entry for deploy_template reads: "Install a template into a new integration. Requires a connectionMap pairing each connection in the template's preview with a real connection _id in your account" (developer.celigo.com/mcp/tools, seen 2026-08-26). So onboarding at the hundredth customer is the hundredth account that signs in to integrator.io, installs from the Marketplace, and gets a license row added to it. That is a smooth wizard, and it is a per-account sequence with your customer at the keyboard and Celigo's product around it.
You ask the AI who is exposed and get the list in minutes. Elsewhere, blast radius across one account; across the install base, a list of accounts
Open the scenarioAn API deprecation notice arrived, and nobody knew who was exposed.
A carrier emails that v1 of its claims API retires in 90 days. By Friday the claims systems manager must name which of 74 connected systems touch that endpoint. That list does not exist.
The vendor emails "v1 of our API sunsets in 90 days." One query returns every automation and every account affected, which becomes the migration worklist.
Inside one account, this is answered well and it is answered from the agent surface, which we credit in full. Ora can "Map blast radius across your entire account before you make a change", with a documented prompt, "If I delete the connection '<connectionName>', what breaks? Simulate the impact and list affected resources"; the CLI has "dependencies <id> (alias used-by): List resources that depend on this integration"; and the editor warns before a shared resource is saved, showing "how many places use it" with a Used by list (all seen 2026-08-25). Across the customers who installed your work, the documented answer is a roster rather than an exposure report. The install-base endpoint "Returns the list of accounts that have installed this connector", the connector carries "numInstalls... Number of active installations of this connector", and the publish article describes "viewing summaries of your licensees and install base" (seen 2026-08-25). Which flows, in which of those accounts, a deprecated vendor endpoint touches is not published: we searched the Connectors API reference (all eight paths and response schemas), the publish article (360048995431), the upgrade article (11432858485659) and the CLI connectors page. On that basis, turning an API deprecation notice into a per-customer exposure list is manual work, account by account, rather than a platform behaviour. The dependency list is also advisory where it counts most: on the MCP surface, the pre-flight "reports dependents only as advisory warnings[] and never stops the delete" (developer.celigo.com, seen 2026-08-25), so what exists is visibility rather than a gate.
Customer three hundred costs what customer three cost. Growth in breadth, more customers, more locations, does not multiply your operational surface, and does not show up as a per-deployment line item on the platform bill.
Support over years is bought by edition: "Log retention: 30 days | 60 days | 180 days", where a longer window does not reach backwards, and with alert subscriptions delivered on a 15-minute cycle. Concede the field-level audit trail at one to three years. Retry eligibility stays a read-only classification rather than a rule you set, and usage comes back in full for one account, as a roster for the rest.
Nobody buys an integration platform for month one. The purchase is really years two through five: the customer reports, the API drift, the 2am incidents, the person who left. Every platform demos the build. This act is about everything after the demo, which is where the money is, and where architectures stop being interchangeable.
Answer a three-week-old customer complaint before standup: find the run, fix it, prove it, ship to all 90 sites. Elsewhere, log and error retention runs 30 to 180 days by edition, and a longer window does not reach backwards
Open the scenario"It did not work for this one customer last Tuesday" was a multi-day archaeology project, and often unanswerable.
6:51am, a support inbox. One location of a 90-site franchise writes: "A member signed up on June 30 and she never showed up in our CRM. She's furious. What happened?" It is July 21. Three weeks ago. The platform has run hundreds of thousands of executions since. Somewhere in there is one run that did something wrong to one record, and a customer is waiting to find out whether you are the kind of vendor who can answer.
All of it directed conversationally, by one person, before the 9:30 standup. The reply to the location: what happened, why, fixed, and here are the other three members we caught and restored.
How far back you can answer a customer's question is set by the edition you bought. Their retention article, titled "Retain your log and error data for more than 30 days", reads: "The default retention period is 30 days. Based on your subscription, you can opt for a longer retention period of up to 60, 90, or 180 days", and the editions table prints it as "Log retention | 30 days | 60 days | 180 days" for Standard, Professional and Enterprise (docs.celigo.com/hc/en-us/articles/6359380074779-Retain-your-log-and-error-data-for-more-than-30-days and docs.celigo.com/hc/en-us/articles/43232045459611-Celigo-platform-editions, seen 2026-08-25). Past the window it is the log and error data behind the run that is gone, and buying a longer window does not reach backwards: "Any data processed before your upgrade will be deleted at the original limit you had."
Inside the window the retrieval is good and agent-callable, and we say so. Their MCP reader returns a run with "the parent plus per-step children[]", and step-level logs go down to "the actual request and response payloads at that stage"; errors carry a traceKey, and the CLI adds query-execution-logs alongside an error reader their reference describes as "One open error by id. --request-detail adds the captured HTTP request/response; --retry-data adds the editable retry data." (developer.celigo.com/cli/commands/flows, seen 2026-08-26).
Two conditions attach to that detail. The editions table lists execution logs as "Basic, Detailed - Available as an add-on, Debug" on Standard and Professional against "Basic, Detailed, Debug" on Enterprise, and the deep logs have to be turned on before the run happens, not after: "enable-execution-logs <id>: Arm debug execution logging on a flow", and the MCP log reader requires that the flow "needs debug logging armed" (developer.celigo.com/cli/commands/flows and developer.celigo.com/mcp/tools, seen 2026-08-26). The customer's question about last Tuesday arrives after the fact.
"It didn't work for one customer last Tuesday" stops being a week of archaeology. It becomes a conversation.
A real deployment went from 140 alerts a day to 3. Elsewhere, subscriptions on a 15-minute cycle; thresholds and suppression are not in the documentation
Open the scenarioAlerting was either silent or so noisy that everyone stopped reading it, which is the same thing.
A platform team's alert channel gets 140 integration alerts a day. A hundred and thirty-eight are a flaky sandbox and a vendor's nightly maintenance window. Two are real. The humans did the rational thing months ago: they muted the channel. Last Thursday, one of the two real ones sat unread for nine hours while a customer's orders silently queued.
Three alerts a day, each one real, each one read. The channel gets unmuted.
Celigo does real noise reduction, and it happens to the errors rather than to the alerts. Duplicate errors collapse automatically: the platform "Uses trace keys... to find duplicates. When a record is successfully processed or a newer error occurs for the same record in a flow step, older errors are marked as Auto-resolved." Rate limiting recovers itself on a connection setting: "When rate limits are hit, the platform lowers concurrency to 1 and retries with a delay that doubles after every attempt (1 min, 2 mins, 4 mins, up to 1024 mins)" (docs.celigo.com, seen 2026-08-25). Subscriptions are agent-reachable too, on flows, connections, integrations and syncs, with the CLI managing "the email and webhook alerts routed on flow, connection, and integration events" (developer.celigo.com, seen 2026-08-25).
What the alerting itself is, in their words, is a subscription list on a fixed clock: "Integrator.io checks for new, open errors and newly resolved errors every 15 minutes... Only users who are subscribed receive email notifications. Two types of subscriptions are available: Flow error... Connection offline", with a user subscribing separately in each environment (seen 2026-08-25). The classification that decides how an error is treated is not yours to set: "Errors are automatically placed into one of the following read-only classifications."
Their error-notification documentation describes no thresholds, suppression windows, escalation, or routing rules for those emails. We searched the notification-timing article (8864920211355), the email notifications section (24220424434971), the error classification article (4403697564429), the Notifications API reference and the CLI notifications page. On that basis, turning four hundred error emails into the handful worth reading is subscription management and flow building rather than a platform behaviour. Their separately subscribed API Management module documents its own alert configuration, for gateway events.
Ask once and 180 automations across a parent and 60 children are snapshotted and disabled, then restored exactly as they were. Elsewhere, stopping is documented, the list of what to restore stays yours
Open the scenarioWhen an upstream vendor breaks, the choice was between flooding a broken API and losing track of what to turn back on.
Tuesday, 11:40am: a CRM platform your customers depend on goes down hard. Across one parent account and its 60 child accounts, 180 automations are hammering a dead API, burning retries, and generating an alert storm. Every minute they keep running makes the eventual recovery messier. But some of those automations were off already, on purpose, and when the vendor recovers you must restore exactly the previous state, not "turn everything on" and reawaken the three that were disabled for good reasons.
Total human attention: minutes at the start, minutes at the end. No flood, no amnesia.
When an upstream vendor breaks, the stopping is documented and the remembering is yours. Concede the automatic case plainly, because it is favourable to Celigo: "An offline connection will automatically pause all flows using the connection... As soon as the connection starts working, all paused flows will automatically resume processing right where they left off" (docs.celigo.com, seen 2026-08-25). Where the trigger is an authentication failure, pause and resume take care of themselves.
A deliberate shutdown is a different set of verbs, all agent-callable and all documented: patch_flow against "/disabled" per flow, environments enable and disable on the CLI, which "read current state before toggling, so the verbs are honest and idempotent", and Ora can "Perform bulk actions across flows and steps in one shot". The environment lever is blunt by their own description, since disabling one is documented to "halt flows, revoke access tokens".
What none of them writes down is the restore set. Celigo does not document a bulk disable that records which flows were running so the same set can be turned back on. We searched the environments articles, the flow management documentation, the Platform MCP tool catalog and the CLI flows and environments command references. On that basis, separating the flows you turned off during the incident from the flows that were deliberately off already is manual work rather than a platform behaviour.
Transient blips retry themselves while broken credentials stop instead of hammering a customer's API, set once for the whole tenant. Elsewhere, retry eligibility is a read-only classification, not a rule you set
Open the scenarioTransient failures were treated as fatal, and genuine auth failures were retried forever.
At 03:10 transient 502s marked 340 overnight freight tenders fatal, while an expired token retried until that carrier's account locked. Trucks unassigned past 07:00 come off the contract rate.
Retryable error classes are tunable tenant-wide, auth failures on named domains get carve-outs, and automatic shutoff behaviour is a policy you set, not a surprise you discover.
Which failures are worth another attempt is decided by Celigo's classifier, and their documented recourse when it decides wrongly is a support ticket. Their error documentation reads: "Errors are automatically placed into one of the following read-only classifications; the value is blank if none of them applies" (Value, Missing, Connection, Intermittent, Rate limit, Too large, Parse, Duplicate), and "Contact support if the classification appears to be incorrect" (docs.celigo.com/hc/en-us/articles/4403697564429-Error-classifications, seen 2026-08-25). Two automatic retry mechanisms are documented, and the second is a real control we concede. The platform "performs up to four retry attempts for intermittent errors" on a fixed schedule, at 00:30, 01:30, 03:30 and 07:30 elapsed. Separately, every connection carries a rate-limit auto-recovery setting, on by default for new connections: "When rate limits are hit, the platform lowers concurrency to 1 and retries with a delay that doubles after every attempt (1 min, 2 mins, 4 mins, up to 1024 mins) until the Target concurrency level is reached again" (seen 2026-08-25), and their 2026.8.1 release made those rate-limit settings patchable through the API. What is not a setting is a rule of your own. Their error-management documentation describes no user-editable list of which errors are retryable and no per-step retry schedule; the documented route to retry these codes and stop on those is a marketplace template you install, connect and maintain, which works by retrieving "open errors using the error API" and acting on them "based on optional filter criteria (flow id, flow step id, error message, or error code)" against an integrator.io API connection you configure yourself.
Catch a silent backlog before the customer calls: work that arrived but never ran has its own screen. Elsewhere, queue counts are visible, an unprocessed-event inventory is not
Open the scenarioSilent backlogs: everything looks healthy, and nothing is moving.
At 08:10 the dispatcher finds 430 missed-pickup webhooks arrived overnight and never moved past the door. Every status board was green, and the trucks left the yard without the reroutes.
The queue of arrived-but-unprocessed events is a first-class view. "Received but stuck" is visible before a customer notices the gap.
Queue depth is visible on Celigo; what is sitting in the backlog is not. Their concurrency documentation gives a per-connection count, "the total number of messages in each connection's queue is displayed in the Queue size column", and an agent can see work in motion through "list_current_jobs: Jobs in flight right now - queued, running, or canceling" (seen 2026-08-25). Both are counts of things that are moving, which is the healthy half of this problem. For the silent half, events that arrived and then went nowhere, Celigo does not document this. We searched their webhook listener introduction, the Debug a webhook article, and Manage webhook export for bulk requests. On that basis an inventory of received-but-unprocessed events is manual work rather than a platform behaviour: matching what the source system says it sent against the jobs that actually ran.
Type a customer's email or order number and land on the runs that touched it across every account. An hour of log reading becomes a minute. Elsewhere, deep search inside one account, account by account across the fleet
Open the scenarioCorrelating a failure across accounts meant reading logs by hand.
Claim AV-2291884 was acknowledged to the policyholder but never reached the loss adjuster, and the regulator's clock runs out Monday. Nobody knows which of 74 broker accounts it passed through.
Search every account at once for a value, a client ID, an email, an order number, and land on the runs that touched it. Correlation is a query, not a shift.
Inside one account their search is genuinely good, and we credit it: "When you search, sort, or filter errors, the operation is performed for the entire list across pages", an account-wide error summary from a single call ("No arguments: account-wide summary (totalErrors, affected flows and steps)"), and execution logs that filter down to one record, "add _stepId, recordId, and groupId for one record's step timeline" (seen 2026-08-25). The difficulty is the shape of a fleet. Each end customer of a partner app holds an integrator.io account and installs into it: "The customer experience will be the same as when installing any Celigo-published template or integration app from the Marketplace" (seen 2026-08-25), and every verb quoted above answers for the account whose token made the call, since "the agent or developer can only do what the token allows". For searching across those accounts by the data itself, a record id or an order number, Celigo does not document this. We searched the errors page article, the full Platform MCP tool catalog, the CLI flows and jobs command references, and the Manage accounts documentation category. On that basis correlating one record's failure across customer accounts is manual work rather than a platform behaviour, one sign-in at a time.
Know which customers are heavy, erroring, or growing before renewal talks and capacity planning, per account, on demand. Elsewhere, full numbers for one account, a roster for the rest
Open the scenarioCapacity and billing questions had no ground truth.
The controller is closing the quarter with two customers disputing invoices and one that grew fourfold on its entry plan. The numbers came from three hand-built exports; sign-off is Thursday.
Which customers are heavy, which are erroring, which are growing: per-account ground truth, queryable by your team and your AI, exportable to your monitoring stack.
For the account you are signed into, the numbers are there and we credit them. Their CLI reports usage as one object: "subscriptions usage returns one combined object covering account, API, entitlement, historical monthly, EDI label-printing, storage, and syncs usage" (CLI 2026.8.7, shipped 2026-08-23, seen 2026-08-25), alongside jobs run-stats, an account-wide error summary from a single call, and lookup caches carrying a "per-cache usage breakdown, up to 14 months of usage history". Across a customer base, what their documentation describes is the roster rather than the telemetry. An Integration App developer gets "summaries of your licensees and install base"; the API returns "the list of accounts that have installed this connector"; the connector resource carries "numInstalls ... Number of active installations of this connector" (seen 2026-08-25). Because each customer installs into an integrator.io account of their own, the usage, run-stats and error verbs above answer for the calling account. A per-customer picture of health and volume is therefore assembled by working through the install base account by account, and it is a picture your team maintains rather than a page the platform keeps.
Support stops being the silent tax on your margin. The question every vendor dreads, "what happened for this one customer three weeks ago," has a fixed cost of minutes, answered by one person, with the evidence still there.
This is Celigo's ground, stated in their words: end customers hold integrator.io accounts and install from the integrator.io Marketplace, where "the customer experience will be the same as when installing any Celigo-published template or integration app from the Marketplace". Their oauth2RedirectUrl, which returns the customer to your site after auth, is a real improvement and we concede it; the hostnames stay Celigo's short of a dedicated instance.
Your customer never sees the engine. They see a setup screen, a connect button, a status page, and increasingly, a tool their own AI can call. Whether those surfaces feel like your product or like someone else's is a brand decision you are making when you pick the platform.
Customers set up the integration inside your product, on your domain, with no second settings screen to build. Elsewhere, setup runs inside Celigo's product, not yours
Open the scenarioCustomers were being sent to a third-party integration UI that broke the product experience and advertised the vendor's supplier.
The settings that drive the integration are the interface the customer configures it with. No translation layer, no second UI to build and keep in sync. Your customers never see the platform. They think it is you.
Lumen, a veterinary-practice SaaS, is shipping a bookkeeping integration inside their product. The bar: a practice manager clicks "Connect accounting" in Lumen's settings, authorizes, maps two fields, done, without ever leaving Lumen, seeing another company's name, or touching a URL that is not lumen-branded. Because the practice manager is not buying an integration platform. She is trusting Lumen.
The customer's takeaway: "Lumen's integrations are great." Which is the entire point.
Your customer signs up with Celigo. They hold an integrator.io account, they install from Celigo's Marketplace, and the settings form they fill in renders on Celigo's hostname rather than inside your application.
Celigo's publishing documentation is explicit about whose product that is: "Once published, navigate to the integrator.io Marketplace to see your new listing with your company's name as the author. The customer experience will be the same as when installing any Celigo-published template or integration app from the Marketplace." Getting there is gated: "Contact your Celigo account executive or partner manager to sign up for our 3rd Party developer program... If accepted into the program, you will be granted permission to publish templates and integration apps" (seen 2026-08-25). The documented route that skips the program is a file handoff: "You can send a ZIP file to another user for them to install in another account." Celigo's own comparison blog states the position plainly: "Not a white-label embedded iPaaS."
Concede the credential step, which they improved in the 2026.3.1 release. A partner can now redirect merchants "back to the partner's application after completing third-party authorization, instead of landing at the Celigo platform sign-in page", an enhancement "designed specifically for embedded and customer-facing OAuth flows". That covers connecting an account. For rendering configuration inside your own product we searched articles 16770326386971, 360048995431 and 360002978111, the celigo.com/platform pages and the partner pages, and found no embeddable component, SDK or iframe documented (seen 2026-08-26).
The assistant you ship resolves requests instead of deflecting them: real lookups, real writes, an approval gate before anything destructive, full logs. Elsewhere, the chat interface they document sits in the builder's configuration screen
Open the scenarioA chatbot that cannot act is a deflection tool, not an integration.
Aldergate's chat agent handled 6,400 conversations and 2,100 ended as after-hours callbacks. A tenant asks at 11pm to move Thursday's plumbing visit, and all the agent can offer is an on-call number.
Agents you ship to customers carry explicit goals and scoped tools, and act through the same governed execution engine as everything else: real lookups, real writes, approval gates, full logging.
You can build an agent on Celigo that does real work. What their documentation does not give you is a place to put that agent in front of your own customer. Concede the build, in their words: "Agent builder lets you build low-code AI agents that are attached to a model, given a clear set of instructions, and empowered to use their own judgement to invoke tools and APIs", and agents also run as a flow step, "An LLM-powered import step that classifies, extracts, or generates data inside a flow". There is a chat surface, and their release notes place it precisely: "AI Agents now include a built-in chat interface for real-time testing inside the configuration screen" (2026.8.1, seen 2026-08-25). That is the builder's screen. Celigo does not document an end-customer chat surface. We searched the Agent builder article (45255381685915), the agentic automation release notes (47114270888475), the 2026.8.1 platform release notes (34008231810587) and the celigo.com/platform AI agents page. On that basis it is manual work rather than a platform behaviour. The documented path that does reach a customer's own agent is the MCP server, which answers on api.integrator.io.
Every surface a customer's IT team inspects, screens, addresses, callbacks, carries your name on every plan. Elsewhere, short of a dedicated instance, the domain under every customer-facing URL is Celigo's
Open the scenarioAn integration layer that shows a supplier's name tells your customer who really built it.
Fenmark is 48 hours from signing a carrier worth 1.4 million a year. Question 41 asks for every hostname claim data touches, and its webhook receiver answers on a domain carrying someone else's name.
Every surface a customer or their IT team can inspect, the UI, the webhook URLs, the authorization callbacks, carries your name, at every tier.
The hostname list you hand a security reviewer is Celigo's. Sign-in is integrator.io or eu.integrator.io. Their API reference lists api.integrator.io with regional variants api.eu, api.au and api.ca. Webhook receivers are generated on that same host: their Google Forms walkthrough builds the destination as an api.integrator.io/v1/exports/<URL-ID-for-webhook>/data address (docs.celigo.com/hc/en-us/articles/10769977254299, re-fetched live 2026-08-26), and MCP servers are documented as "https://api.integrator.io/mcp/<accountaliases>/<relativeURI>" (docs.celigo.com article 47114270888475, seen 2026-08-25). Transactional mail comes from them: "Password reset emails are sent from noreply@celigo.com. To ensure you receive these messages, you or your IT team may need to add @celigo.com to your allow list." On the partner-run OAuth route the consent step names them, with the customer "asked to allow Celigo to access their account and related data." A custom domain is documented for a separate offering: "Custom domain: You can define the custom domain for your Celigo Private Cloud dedicated instance", a dedicated instance the same article's comparison table marks "Fully managed by Celigo". We searched that article (31449555282459) for whether the domain also covers the OAuth callback, the webhook receivers and the API host the browser talks to, and found no statement of scope (seen 2026-08-26). Three partner-controllable pieces deserve conceding. Marketplace listings carry "your company's name as the author". The oauth2RedirectUrl field sends the customer back to your application after authorisation. And API Management takes a subdomain you choose: "This subdomain will be used for the APIM console, API Developer portal, and Gateway URLs... The subdomain has a 200-character limit (alphanumeric only)... To reconfigure your subdomain, you must create a support ticket." That subdomain sits on Celigo's gateway domain. Their own comparison blog sums the position up: "Not a white-label embedded iPaaS."
The integration experience compounds into your brand instead of your supplier's. Every setup flow, every status page, every AI tool call is a moment your product looks finished, in your customer's language, on your domain.
The spine of the page, and its most perishable part. On Celigo a restore point exists only where somebody deliberately made one: "integrator.io creates a revision when you perform a pull, revert or snapshot operation", and Ora "does not take a snapshot before modifying a resource, and there is no built-in rollback". Applying the rewind is UI-only by their own reference: "ILM commands are UI-only. revision-apply, revision-cancel, revert-*, pull-* ... are intentionally not exposed as CLI commands", while their headless page markets "complete feature parity with the UI". Both halves verified 2026-08-26, against a beta on a monthly release cadence.
Everything on this page is exposed to AI, but "AI-powered" is the emptiest phrase in the category. The question with teeth: which phases of the integration lifecycle does the AI have real tooling for? Building is one phase. There are seven more.
One person and the AI cover an integration's whole life, launch through incidents. Elsewhere the AI diagnoses, then a developer does the fixing. Elsewhere, the rewind of a configuration change on a live integration is the step that goes back to a person in the Revisions tab
Open the scenarioAn AI with raw API access improvises. An AI with encoded procedures repeats what works.
Day two. The integration is built and live; both platforms' AI tooling got you here, and both did it well. Now the real career of an integration begins: a customer reports a discrepancy, an API starts rate-limiting, an alert needs tuning, a fix needs to reach the fleet. The question for the AI is no longer "can you build it." It is "how much of what happens next can you handle?"
One person and the AI cover the lifecycle. Day two looks like day one.
What this costs a reader is not the build. It is the undo. Celigo's agent surface runs a live account forward with real depth, and that belongs at the top of the row. Their Platform MCP server reached GA on 18 June 2026 so agents can "read, run, and troubleshoot your integrator.io account", and their changelog states the day-two loop in one sentence: "Trigger a flow, wait for the job, inspect per-step results, then retry, resolve, tag, or assign failed records, all in one conversation." It ships guided playbooks for troubleshooting a flow, diagnosing a connection, reviewing a flow config and auditing account health, open-sourced in celigo/ai, and their CLI installs those skills for whatever assistant is driving it, "at most once every 24 hours", with no manual step. Ora does the same conversationally inside the product. An agent on that surface can cancel a running job including its children, bulk retry to their published caps of 1,000 errors a page and 20,000 a step, edit a staged error payload before it retries, run a backfill window, and swap a connection under a live flow.
Where it stops is the rewind, and Celigo writes that boundary themselves on every surface. Their REST API reference, on the snapshot endpoint, says: "This is the only revision type that can be created via the public API; pull and revert revisions require the Celigo UI." Their CLI reference says it again for the headless layer: "revision-apply, revision-cancel, revert-*, pull-*, clonefamily, and ilm-ignore* are session-auth only and are intentionally not exposed as CLI commands. Use the UI for those." The Platform MCP catalog lists no revision or revert tool. And their Ora documentation states: "Ora does not take a snapshot before modifying a resource, and there is no built-in rollback." All four re-checked 2026-08-26. Their headless product page describes that same layer as having "complete feature parity with the UI", and the exception is written in their own CLI reference.
The narrower reading is the fair one and it is the one to hold. Reading history is agent work: revisions, element-level diffs, and an audit trail whose entries carry the old and the new value of every changed field. Laying down the restore point is agent work too, by snapshot on that same API call, by a same-environment clone, which is what Celigo's own published agent skill prescribes as the backup before risky changes, or by exporting the integration as an installable template. Undoing a deletion is agent work, through a recycle bin that restores sixteen resource types with their dependents for 30 days. What no agent surface carries is the revert verb itself, so rewinding a configuration change on a live integration is either a person in the Revisions tab, where "you can always revert to a previous revision at any time", or an agent writing prior values back field by field without a revert's all-or-nothing guarantee. The other half of it is where the restore point comes from: on Celigo a revision exists only where somebody deliberately made one, since "integrator.io creates a revision when you perform a pull, revert or snapshot operation", and Ora "does not take a snapshot before modifying a resource". Ora is in beta on a monthly release cadence, so this is the shortest-dated row on the page.
The AI is not a build accelerator bolted to the front of the lifecycle. It is a colleague with a runbook for all of it, which is why one person can run what used to take a team.
Every row on this page reduced to the same fork. On APIANT, the job was a walkthrough: find it, see it, change one node, prove it, ship it everywhere. On Celigo, the same outcome was reachable, usually, and it was a project: a code artifact to edit, a pattern to hand-build, a script to write against their API, a window that had already closed. Not because their team built a careless product. They built a serious one. But their platform is made of code at the layer that matters, and their AI's output is code, so every question on this page eventually hit the same wall: the thing that runs your business is an artifact only developers can safely touch, and the AI that builds it cannot fully operate it afterwards. On APIANT the integration is a structured document at every layer, which is why the AI can build it, a compiler can refuse the invalid version of it, a test can force every branch of it, a person can read it, and one command can ship it to a fleet. That is not thirty-nine features. It is one architecture, showing up thirty-nine ways.
Then you write code, in the one place code belongs: a scripting escape hatch that slots in as a single node of the structured document. Code is an optional leaf inside a data document, never the foundation. The loop, the branches, the mappings, the tests around that leaf all remain visible, machine-editable, and compiler-checked; the custom logic is contained to the one spot that genuinely needed it.
Compare the shape of the same answer elsewhere: when the model runs out, the escape hatch is more code on a foundation that is already code. The exception and the rule are indistinguishable. Here, the exception stays the exception, and a decade of production has kept it rare.
Own the outcome, and be precise about what owning the artifact costs. A code integration is cheap on day one and priced like a liability thereafter: it is reviewed by whoever has time, it carries a dependency tree that ages, every API drift re-opens it, and its real documentation is the memory of whoever wrote it. Multiply by every integration you will ever ship, then by the years you will run them, then subtract the engineers who will have moved on. That is the asset you would own.
What you own on APIANT is the thing you actually wanted: integrations that run, on your domain, inspectable by your team, provable before they ship, and operable by AI for as long as you run them. The buildings your company works in are owned this way too: you own the use of something built and maintained by people whose whole business is that it never falls down.
The API with no catalog entry, the forty custom fields, the sync that loops, the customer report from three weeks ago. One working session, on your systems, and you watch it built, tested on every branch, and running. Judge the architecture with your own scenario, which is what this page has been asking you to do all along.
Book a working session See the AI operate the platformScenario companies on this page are composite illustrations drawn from real deployment shapes. Company names are fictional and are not customer references. Where a figure comes from a live APIANT deployment it is identified as such and the customer is not named. Every statement about Celigo on this page derives from Celigo's public documentation, public repositories, blog, and pricing page as reviewed in August 2026. Direct quotes are reproduced verbatim for comparison purposes. Celigo is a trademark of Celigo; all product names belong to their owners. Platform capabilities evolve; verify anything decision-critical against the current versions of the linked pages.
