Two integration platforms. One has a catalogue of prebuilt apps; the other builds any API into a connector in hours, not quarters, and turns that depth into a product: one build carries the logic, and each customer’s differences live in settings. This page compares what each actually requires of your team, across forty-six 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.
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 Workato, 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. Then ask the half that goes with it: when the hundredth account needs that depth configured differently, is it one build with settings, or a copy per customer?
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 20, the answer to it →These three tests run on every one of the forty-six 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. Workato's side is derived from Workato's own documentation, help centre 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 Workato. Skim the forty-six 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 Workato. Skim the bold lines first. The argument is the pile, not any single row.
Recipes read clearly on both platforms. Below the recipe the ownership differs: "The Workato SDK platform only allows you to edit the latest version of a custom connector's source code", and putting an earlier one back "restores the version by creating a copy of the version's source code as a new latest version".
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. On Workato, the AI reads the recipe; diffing and restoring are buttons.
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.
In March an AI built Meridian's QuickBooks invoice sync. In September the supervising engineer is gone, and Dana, the new integrations lead, not a developer, must remap line items for one segment.
Elapsed: about twenty minutes. No engineer involved. The March artifact and the September artifact are the same living thing.
Their AI reads the current recipe fine. It cannot diff or put a version back: the version detail response carries metadata and no recipe code, so Compare and Restore this version are buttons a person clicks. Its own working sessions sit outside version history.
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. On Workato, the AI builds the parse; the ceiling is a commercial conversation.
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.
The nightly claims and inventory export lands at 1am as one file. At quarter end it is 80MB, and it has to be parsed, reconciled and posted before clinics open at 7am. Nobody is awake to babysit it.
Corrections post by 4am. Quarter end is not an incident category.
Their AI can author the parse, and transfer streams with no configuration. Raising the ceiling that parse meets cannot be asked for in words: each format has its own published default, and lifting one is a request to a Customer Success Representative, held per format and per plan.
Structurally invalid work is refused at build time, instead of surfacing later in production logs. On Workato, the pre-run gate checks completeness, not intent.
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; the compiler refuses invalid structures at the door. It then tests the build on a real saved claim and reads what reached the payment field. Dee can open that run too.
Their AI can run the code validator and the test cases. What the platform checks before a run is completeness: a configured trigger, valid mappings, valid connections. A payout mapped to the wrong valid field satisfies all three, so the catch is a test case the AI re-authors after each step edit, because editing a step counts as deleting one.
Ask the AI which integrations use a broken lookup, fix it once, and every one of them inherits the fix, including the ones your team forgot about. On Workato, the reuse their AI can author stops at the recipe layer.
Open the scenarioThe same connector logic was being rebuilt per customer, and the copies diverged.
The shift lookup was built once, then copied into 60 trust integrations, and a February timezone correction reached 41 copies. On an audit call, a liaison asks which version each trust runs today.
Marcus asks the AI which integrations run the shift lookup; it names the referencing assemblies and the automations using them. Built once, fixed once: all 60 trusts inherit it. He can walk the list himself. Reuse is a first-class element rather than a pattern to assemble: the AI writes a call to a typed subroutine or a shared assembly into the automation the same way it writes a condition or a loop.
Their AI authors recipe functions, and one shared connector reaches every customer workspace. Where the catalog lacks the operation the reusable unit is a Ruby SDK connector, and the documented handoff there is a person pasting the code into the connector editor. The one-click refactor is a UI action too.
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.
Any endpoint is reachable on both, and how fast you get a working call is not the difference. What differs is what the reach turns into: here, one connector carrying every trigger and action the API offers, private and partner endpoints included, deployed once and configured per account. On Workato the escape hatch is where reach costs you an asset to maintain: their own HTTP versus SDK comparison table marks that route as not paginating and not reusable across recipes, printing the SDK column yes against the HTTP column no on both of those rows, so sharing the step means wrapping it in a recipe function your team owns, the datatree inside that wrapper still comes from a pasted response sample, and a custom action is bounded by the scopes their connector asked for, with "contact your Customer Success Representative to file an enhancement request" as the documented remedy.
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. On Workato, a person moves the connector code.
Open the scenarioThe integration the deal depended on was never in anyone's catalog, and the catalog vendor had no incentive to add it.
Membership holds and multi-site transfers live in a 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.
Not something their AI can do. Not reachable by asking. Their documented route runs Connector Copilot in a browser panel and ends with a person pasting Ruby into the connector editor, and their spec generator is documented for creating a new connector rather than updating one.
Five integrations clear their vendor portal paperwork in one afternoon, with the credentials landing straight in the vault instead of a spreadsheet. On Workato, five vendors is five developer portals worked by hand.
Open the scenarioOnboarding stalled for days on OAuth paperwork before a single record moved.
Five integrations launch this quarter, each blocked on registering an app on a vendor's developer portal: forms, callback URLs, credentials. It is nobody's job, so it becomes everybody's bottleneck.
Five portals, one afternoon, zero credentials in a spreadsheet.
Not something their AI can do. Not reachable by asking. Registering the app in each vendor developer console is a person, in their own one-sentence procedure. Once that person holds the client ID and secret, a custom OAuth profile can be posted by the agent.
An onboarding call maps forty-one custom fields and a dropdown their admin invented, because the connector reads the customer's live tenant. On Workato, the refresh is a click and end-customer mapping is enabled by their team.
Open the scenarioField mappings built against documentation break on contact with a customer who renamed things and added forty custom fields.
A 60-store retailer's CRM carries forty-one custom fields and a member tier dropdown whose values exist in no documentation. 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."
Their AI does field mapping, and the platform reads schemas from connected apps. Pulling the current structure after a customer adds forty-one fields is documented as a Refresh click, and letting the end customer map their own fields is a feature a Customer Success Manager switches on, without array fields.
Every API gets a vetted way of announcing changes, so records stop going missing or arriving twice. On Workato, the harder trigger shapes are a developer's Ruby.
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.
The AI picks the right pattern per API and builds the trigger, or Dana's team picks it: polling for new records, polling for new-or-updated, manual webhooks, self-registering webhooks, service webhooks with event filtering, long-lived protocol listeners. Six vetted patterns either way, and which one a feed is using is visible on the trigger itself.
Not something their AI can do. Not reachable by asking. A carrier with no updated-at field, and one expecting a webhook registered for it, both land in the Ruby SDK per their own HTTP versus SDK table, and their generator does not produce triggers, so a developer writes each.
Ask the AI for an inference or a price calculation and it arrives as a step your team can open and check. On Workato, the field tree comes from a sample somebody pasted.
Open the scenarioCreate-read-update-delete alone cannot express what modern APIs do.
The photo-damage model and the fraud score in claims intake sit inside a code block whose author left in March. At 3,000 claims a month, adjusters quote repair numbers the company cannot account for.
Ask the AI for the fraud score and it builds the call as an invoke action, the primitive for operations that compute, transform, or generate. Or Renata's team builds it. Add, delete, find, get, list, update, and invoke: seven primitives, and either way the step opens as data rather than as a contractor's code block.
Their AI can author the HTTP or code step and generate a schema from a JSON sample. The field tree then comes from that pasted sample rather than from the account, and where the call needs a scope the connector lacks, the documented remedy is an enhancement request to a Customer Success Representative.
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. On Workato, the dial is per recipe and a person turns it.
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.
Tell the AI the vendor's published limit and it sets the throttle, at connector, action, or connection level, or Sunil types it once himself. Either way the platform enforces it across every automation and every account touching that API, with queueing and backoff, and either of them can read the current setting back. One deployment runs 232 locations against a single 185-calls-per-10-seconds budget.
Not something their AI can do. Not reachable by asking: neither published endpoint index carries a throttle or concurrency call. A person sets concurrency in the settings of a stopped recipe, one recipe at a time, and the vendor ceiling stays arithmetic your team redoes.
Integrations your team hand-built years ago become AI-editable without a rewrite. On Workato, the recipes travel and the Ruby stays a developer's file.
Open the scenarioYears of existing integrations would otherwise be stranded outside the AI's reach.
214 integrations built by hand over eleven years, and the two people who built them are one retirement and one resignation from being gone. Modernizing cannot pause a single member-facing flow.
Point the AI at the hand-built estate and it converts each integration into the same structured form it operates, so the 214 flows Cascade Ridge already owns become maintainable by the AI and by Marta's team. Or her team converts them itself, one flow at a time. Nothing is stranded, nothing loses its visual form, and no member-facing flow pauses.
Their AI reads and edits eleven years of recipes in place, which is real and should be conceded. The custom connectors under those recipes are a different artifact: Copilot returns Ruby in a chat panel and a person pastes it back, replacing the whole actions block to add a single action.
A connector for an API no catalog lists is hours of work, not quarters, and every connector you add joins the same inspectable library: built once at whatever depth the API allows, then deployed to every account, with each customer's differences in settings rather than in a copy that drifts.
Depth is not only how far into an API you reach. It is how much logic the AI writes in one go, and here that is a whole automation: nested boolean conditions, loops, typed subroutines any other automation can invoke, and fan-out groups that wait for their children, all elements of one document the platform compiles. On Workato the reusable piece and the asynchronous call are separate recipes with runs of their own. Changing a rule is an element-level edit to a readable model, made and proven in the build environment before it ships. Workato's API reference states the alternative for the recipe already deployed: "UPDATING A RUNNING RECIPE IS PROHIBITED. Any update call to a running recipe will return an error", and on webhook-driven recipes "trigger events that occur while the recipe is stopped may not be picked up".
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?
Contact changes flow both ways on day one, without the overnight loop that rewrites one record 4,000 times. On Workato, the loop guard reaches into the customer's own apps.
Open the scenarioTwo systems updating each other trigger each other, forever.
22 clinics keep patient details identical in practice management and marketing CRM, editable from either side. One record was updated four thousand times overnight and both APIs rate-limited them.
The sync runs both directions on day one, and "infinite loop" is not in the runbook.
Their AI can write the trigger filter in each direction. The version their own best practice recommends needs a dedicated field created inside each connected application, which is a person in the practice management system and a person in the CRM, and detection when the guard slips is by symptom.
One fix instead of nine, with nothing left behind in a forgotten copy to drift out of step. On Workato, the shared piece is editable; its callers are not enumerated.
Open the scenarioThe same twelve-step sequence appeared in nine automations and had to be fixed nine times.
A twelve-step onboarding sequence sits inside nine automations. The April rule change meant the identical edit nine times, and copy seven had drifted: a welder paid at the wrong rate for five weeks.
Ask the AI to extract the twelve steps into one subroutine and repoint all nine automations at it, or do the extraction by hand. Either way the fix lands once, all nine inherit it, and the subroutine tests on its own.
Their AI can edit the shared function, and Acumen answers which recipes use a connection. The caller list for a recipe function is a different question: their dependency graph enumerates nineteen asset types and recipe functions are absent from it, so who calls this is answered by reading recipes.
Customers get one 5pm summary instead of 400 pings, and nothing is lost when two runs land at once. On Workato, the digest is an application your team maintains.
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.
The operations manager asks for one 5pm summary and the AI builds the collector: events drop into a named bucket all day, drained on the schedule. She can build the same bucket herself. It is a dedicated primitive, safe when two runs land at once.
Their AI can author the digest recipe, which you then own. What it cannot reach is the platform's own error mail: the published granularity is a per-recipe hourly cap on a Workspace admin screen with no endpoint, and message templates sit on AIRO's published exclusion list of assets it cannot build.
Refunds over $500 wait for a manager's approval while everything else keeps moving. On Workato, the approvers are a directory an admin maintains.
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.
Ask the AI for a gate above $500 and it adds the moderation step; the head of support can add it herself. The run pauses on a queue, a person approves or denies from a link, and the run resumes. Everything smaller keeps flowing.
Their AI can create the data table and author the skill. Two steps stay human: approvers are added to Workato Identity by an admin, and a reviewer has to be signed in to the chat interface when the request arrives. The approval feature is published as beta.
Change one step of a fifty-step process without re-testing the other forty-nine. On Workato, the proof is rebuilt on the same cadence as the change.
Open the scenarioOne monolithic automation became unmaintainable and untestable.
Order-to-cash is one automation that has grown to 64 steps. Any change to the credit-check rules means retesting all 64, so the applications manager tests none of it and edits at 5am on Sundays.
The AI splits the 64 steps into small automations that call each other with parameters, or the applications manager does the split himself. Either way each piece tests alone, so a credit-check change retests one piece instead of all 64. Size is what makes this worth having: one shipped APIANT product carries 65 automations across eight folders with shared subroutines between them, one of them an installer that runs past 100 steps, in production and versioned through v3.9.3.
Their AI can split the flow and manage test cases. The durable proof does not survive the next change: editing any step counts as deleting one, so the checks fail and the case is re-authored, and the interactive input that exercised a piece in March is lost when the page is refreshed.
A customer's 300-row mapping sheet becomes the configuration directly, with unresolved rows flagged, instead of a week of error-prone typing. On Workato, three hundred rows are typed or scripted by hand.
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.
Hand the AI the 300-row file and it becomes the mapping directly: the AI reads it, applies it, and flags the rows that do not resolve. The consultant can key a row herself, or correct one the AI flagged, on the same screen.
Not something their AI can do. Workato does not document this. We searched their Data tables and Lookup tables pages, the Embedded dynamic field mapping page and the 2026 changelog. On that basis turning a spreadsheet into mappings is manual work rather than a platform behaviour.
Turnover stops costing you the same debugging twice: a quirk solved once stays solved after its author leaves. On Workato, the memory is a document somebody uploads.
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.
The AI writes each solved quirk into a searchable library and checks that library before it builds anything, so the timestamp-zone trap is solved once, ever. Your engineers read and write the same library, which is what keeps the knowledge after its author leaves.
Not something their AI can do. Not reachable by asking. Playbooks are the memory feature and adding one is a click path: Add Playbook, then drag the file in. Neither published index carries a playbook call, so what the agent works out is written up by a person or not at all.
A genuinely odd requirement ships without waiting on a vendor release, and everything around it stays readable. On Workato, a reused exception becomes a developer's connector.
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.
Give the AI the ring-binder rule and it writes the check-digit logic into one script node and compiles it; the analyst can write that node himself. Either way code is an optional leaf inside a data document, never the foundation, and everything around it stays visible, testable and machine-editable.
Their AI can put a code step or an HTTP step in a recipe, and the fixed-width case has a named tool. Once the exception has to be reused it becomes an SDK connector with a single editable head, released by a person, and that release moves every recipe using it from its next job.
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. What that permits is ours to state plainly: one APIANT product began as a one-hour meeting transcript, and two working days later the integration existed and had been tested branch by branch, with its own connector, 46 automations, 15 event metrics and a provisioning automation behind it.
A rare path is proven on a real execution rather than on a parallel set of mocks, and the branch is forced by correcting a saved run and restarting it from that step, on the build and test surface. On Workato the edit and the proof are coupled: "if you make changes to any of the steps in your recipe, Workato treats this as a deleted step and the check fails", with nothing to fall back on, "Workato does not store the history of changes made to test cases".
"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. On Workato, the mock is one ask and it expires with the next edit.
Open the scenarioThe branch nobody could trigger on demand was the branch that broke.
The donation pipeline has a branch that fires only in the last week of December. It is March and the integration was just modified. Prove the December branch still works without waiting nine months.
The branch that used to be tested by December is tested by lunch.
Their AI manages test cases, so mocking a step to reach a December branch is one ask. It fails after the next step edit.
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. On Workato, impact is answered per connection, one workspace at a time.
Open the scenarioA one-line connector fix silently changed behaviour for three hundred accounts.
A date-format bug turns up in a shared connector operation, with 300 customer accounts live. The fix is one line. Which automations call it, on whose accounts, and which rely on the buggy behaviour?
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.
Their AI answers this in conversation for a connection or a connector, and the page concedes that. For an Embedded fleet the unit is the workspace: a usage query per relevant workspace, filtered by connector, read and interpreted, while a one-line fix inside one operation sits below what that enumeration addresses.
You know a change is fully tested because the platform counts untested paths, not because someone felt confident. On Workato, which branches were covered is counted by hand.
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.
She asks whether the change is fully tested, and the AI answers from the branch test points the platform tracks, then walks the ones still unexercised. She can read the same list herself. Coverage is measured, not assumed.
Not something their AI can do. Workato does not document this. We searched their Test Automation overview, the test case run and results pages, the FAQ, the limits page and the wk CLI command tree. On that basis a coverage number is manual work rather than a platform behaviour.
Bugs get retested against the actual record that broke, emoji in the surname included. On Workato, the rerun is a call inside the retention window.
Open the scenarioSynthetic test data does not contain the thing that breaks integrations.
A patient pre-authorisation posted wrong on 3 July, escalated after the third rejected claim. Reproducing it needs that exact run: an emoji in the surname field. That run is six weeks old.
She names the 3 July run; the AI re-executes it from the step that broke, its captured data intact, or she does it herself. The emoji in the surname and the mangled mobile number are in the test, because the real record is the test.
Their AI can rerun the failed job on its real trigger event through the repeat jobs endpoint, and the rerun picks up the current recipe.
Answer a month-old complaint by re-firing the exact message that failed. On Workato, changing the payload means changing the source record.
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.
She asks for last month's tender; the AI finds the stored payload and re-fires it at the fixed automation, or she replays it herself and watches it process. No shipper is asked to re-send a load they already moved.
Their AI can repeat jobs, capped at twenty-five per request and one request per second, but the payload replays exactly as captured. Where the payload is the fault, their documented route is the shipper's system: delete and recreate the object, or update it so the trigger picks it up.
Shared logic proves itself in one run instead of dragging nine workflows through a test cycle. On Workato, testing the shared piece alone is on their roadmap.
Open the scenarioProving one shared component meant running nine automations.
One change is needed to the address-and-residency normalisation sequence before enrolment opens Monday at 8am. Proving it means dragging all nine parent automations through a test cycle on a Sunday.
She asks the AI to prove the shared sequence; it runs the subroutine alone on controlled inputs and reports what came back. She can run it the same way herself. A subroutine carries declared inputs and outputs, which is what makes it runnable on its own. One run, not nine parents dragged through a cycle.
Their AI can author and run a test case against the shared piece from a pipeline. Their own documentation puts independent testing of recipe functions in future improvements rather than in the product, and the case you build is pinned to the step identities the next edit changes.
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.
One deploy call here carries a fix to a list of accounts, previewed before it writes, and the verified proof point is one fix reaching 232 locations in a single deploy, which works because the integration exists once and each location's differences live in its settings rather than in a copy. On Workato a shared custom connector goes to the whole customer community in one action, conceded, while recipe packages move a workspace at a time: POST /api/managed_users/:managed_user_id/imports, "You can import one package at a time", two documented status values that mean updated but not restarted, and "Any errors in restarting the recipes must be fixed manually." Their reversal is documented too, "roll back to a previous deployment at any time", and it is one deployment in one workspace, so across a fleet it is that loop run again with an older package.
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. On Workato, the fleet is a loop of single-workspace imports.
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 runs the same booking-system-to-CRM integration at 232 locations, each on its own credentials. A fix has to reach all 232 before the evening class rush.
Fix at 2pm, fleet-wide by 2:15, evening classes uneventful.
Their AI can call the import, and per-customer settings survive it because the import is name matched. The call takes one workspace id and one package at a time, so a fleet is a loop the agent runs, and recipes that fail to restart are repaired by hand.
One incoming request lands in the right location's account, on that location's own credentials, with hundreds of accounts behind the curtain. On Workato, the branch lookup is logic your team writes.
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 178 children: the webhook hits the master, which routes by store code to the right child, processing on that branch's own credentials. Priya asks the AI where a refill landed and it searches execution history across all 178 accounts at once, or she opens the run herself.
Not something their AI can do. Workato does not document this. We searched Automation HQ, the Embedded API index, the webhook gateway limits page and the webhooks connector page. On that basis routing to the right child workspace is manual work rather than a platform behaviour.
One CRM login covers every location while each site keeps its own booking login. On Workato, two logins in one recipe depends on a secondary connector.
Open the scenarioRe-authenticating per location does not scale past about twenty.
Southern Reef Dental's 96 practices each hold their own practice-management login, but the one group CRM token expires every 90 days. Re-authorising clinic by clinic has cost three weekends.
One CRM credential, flagged shared, serves all 96 practices while each keeps its own practice login. Dan asks the AI whether the group token still authenticates, and it tests the connection live. He can check by hand. Sharing is a toggle on the hierarchy, alongside shared settings and automations.
Their AI can create connections and author the recipe function that picks one at runtime, which is their documented route to many practice logins. Inside a plain recipe it depends on a secondary connector existing for that app, and their own page states that some apps have none.
A week of hand-updating becomes one confirmed action, staged if you prefer, with every prior version kept for a redeploy. On Workato, the one-click version is a button and the AI version is a loop.
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.
Marta tells the AI to ship it: the whole folder published, then out to the 186 venues, each returning its plan and writing on her confirmation, per-account results in front of her. She can run both herself. Staging is naming a subset on one call, and every prior version is kept, so a reversal is a redeploy rather than a rebuild.
Their one-action fleet push is real, and it is a console button, as is its reversal. From the agent surface the same outcome is a build, a deploy and an import per workspace, with recipes stopped, updated and restarted each time, so a fleet-wide reversal is that loop run again with an older package.
A new account is created, linked, and inheriting shared logins, settings and automations in one operation, with no onboarding checklist to work through. On Workato, the customer's own OAuth grant is a browser, per property.
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.
Ines asks the AI to onboard the next hotel: it creates the account and links it into the hierarchy, inheriting shared connections, settings and automations, and one deploy covers the rest. She can do the same in the console. The 31-step checklist becomes one operation.
Their AI can create the customer, provision environments and post the credentials your platform holds, which closes a property in a few calls. The app whose grant belongs to the customer stays a browser: an imported package leaves a placeholder connection that has to be authenticated afterwards.
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.
Suppression with an audit of what is suppressed, retry eligibility and per-step alert mapping are tools the agent calls here, each returning a preview before it writes. On Workato their AI raises the incident, their documented route to a tuned alert is a monitoring recipe an agent can author and your team then owns, and the platform's own thresholds stay Workato's: "A recipe encounters 3 consecutive trigger errors", "A recipe is stopped by Workato after 60 consecutive trigger errors", configured on a screen reached by "Go to Workspace admin > Settings > Error alerts".
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. On Workato, searching by the member's name is decided before the run.
Open the scenario"It did not work for this one customer last Tuesday" was a multi-day archaeology project, and often unanswerable.
6:51am: one location of a 90-site franchise writes that a member signed up on June 30 and never appeared in their CRM. It is July 21, and hundreds of thousands of executions have run since.
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.
Not something their AI can do. Not reachable by asking: their jobs endpoint filters by offset, status and rerun, with no data value. Searching by a member name needs a custom column a person adds in the UI, on a stopped recipe, in advance of the run, and it is not retroactive.
"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. On Workato, tuned alerting is a recipe you build and maintain.
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 and two are real. They muted it months ago. Last Thursday one of the two sat unread for nine hours while orders silently queued.
Three alerts a day, each one real, each one read. The channel gets unmuted.
Their AI cannot reach the alert settings: neither published endpoint index carries a notification or alert call, and recipients, the project filter and the hourly cap live on a Workspace admin screen. Their documented route is to author a monitoring recipe instead, which their AI can do and which you then own and are metered on.
Ask once and 180 automations across a parent and 60 children are snapshotted and disabled, then restored exactly as they were. On Workato, the kill switch is a control recipe you write and maintain.
Open the scenarioWhen an upstream vendor breaks, the choice was between flooding a broken API and losing track of what to turn back on.
An upstream CRM is down and 180 automations across 60 child accounts are hammering a dead API. When it recovers you must restore the previous state exactly, not reawaken the three disabled on purpose.
Total human attention: minutes at the start, minutes at the end. No flood, no amnesia.
Their AI can stop recipes, per recipe and per workspace, so a fleet shutdown is a loop it runs plus a record of what was on beforehand that it has to keep itself. No snapshot and restore action is published, and the automatic bulk pause they do document is keyed to credit limits rather than to incidents.
Transient blips retry themselves while broken credentials stop instead of hammering a customer's API, set once for the whole tenant. On Workato, retry policy is recipe code, re-entered per recipe.
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.
Ask the AI to retry the 502s and stop the expired token, or set the lists yourself: retryable error classes are tenant-wide, and auth failures on named domains get carve-outs. Shutoff is a policy on record, not a surprise you discover.
Their AI can write the Handle errors block, and their job retry API replays failed jobs in batches from outside the recipe. The policy itself is per recipe, so it is re-entered in each one, the recipe has to be stopped for the edit, and the bounds are theirs: three retries, one to ten seconds apart.
Ask the AI and a job pounding a customer's system stops: the in-flight runs halted, the automation deactivated so nothing new starts. On Workato, the move an agent can call is off, not slower.
Open the scenarioA misconfigured run was hammering a customer's API, and the only remedy was waiting.
A looping seat-hold sync is firing thousands of calls a minute at an arena's box-office API. The sale is live, 40,000 fans are in the queue, and the arena says it will revoke the API key.
Ask the AI to stop it: one call halts the runs in flight, a second deactivates the automation so nothing new starts. Dane can press both himself, while the sale is still live.
Their AI can stop the recipe, and pending jobs pause with it. Cancelling the single job that is looping is a button on that job's page, and slowing a run is absent from their write surface: concurrency is a setting a person changes on a stopped recipe.
Catch a silent backlog before the customer calls: work that arrived but never ran has its own screen. On Workato, finding what arrived and never ran is manual.
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.
Ask what arrived and never ran: the AI returns the received-but-unprocessed queue, 430 events, and Marlene sees the same view unprompted. Stuck work shows up before a customer notices the gap.
Not something their AI can do. Workato does not document this. We searched the webhook gateway limits page, the Jobs API reference and Event streams. On that basis listing events that arrived and never became jobs is manual work rather than a platform behaviour.
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. On Workato, a value is searchable where a Logger step wrote it in advance.
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.
Ask with the claim reference and the AI searches every account at once for that value, returning the runs that touched it. Eoin can run the same search. Correlation across 74 accounts is a query, not a shift.
Not something their AI can do. Not reachable by asking. Their documented route is a person on the Logs page, filtering by recipe id or a search term, per workspace and per region, and a value is there where a Logger step wrote it in advance of the incident.
A support question that used to need a database ticket and two days gets answered in the meeting. On Workato, the per-record answer depends on retention and truncation.
Open the scenarioDiagnosis stalled waiting for someone with database access.
The overnight sync left 260 students without timetable records, and a queue is forming at the registry counter on day two of term. The registrar has a theory she cannot test without database access.
Is it the part-time cohort at one campus? The AI answers in seconds with a guardrailed read-only query, and Alison can run the same query herself. Tested in the meeting, not in a database ticket.
Their AI answers the operational question directly, ad hoc usage reports included, and that half should be conceded. The per-record answer is a different read: job details, per recipe, inside a thirty-day default retention and a one megabyte truncation of inputs and outputs across all steps.
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.
Your brand and your hostnames on the surfaces your customer touches, because every paid tier ships on your own dev and production servers under your own domain. Since June 2026 the Workato Identity login and connection pages take a self-serve logo, favicon and app name, while the Embedded pages your customer configures in still list "Origin and path prefix" and "Logos" under Limitations, to be arranged through a Workato Success Representative, and that configuration surface, the embedding script and the OAuth callback answer at app.workato.com, embedding.workato.com and www.workato.com. On their API-key Genie path they state "Workato is invisible to end users", which is a different surface and is not in dispute.
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. On Workato, the setup screen is an iframe on their host.
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.
A practice manager clicks "Connect accounting" in Lumen's settings, authorizes, maps two fields, done, without seeing another company's name. She is trusting Lumen, not buying an integration platform.
The customer's takeaway: "Lumen's integrations are great." Which is the entire point.
Not something their AI can do. Not reachable by asking, and not by your team alone: the frame is an iframe on a Workato host, and standing it up means sending an RSA public key and an origin URL to a Workato Success Representative before any customer sees it.
The AI assembles the setup screen, so there is no front-end project: validated input, live choices from the customer's systems, embed code returned. On Workato, the form builder is a person's screen.
Open the scenarioConfiguration UIs were bespoke front-end projects, every time.
Palletworks promised its three largest brokers a screen that pulls their live carrier list and validates SCAC codes before anything saves. Its two front-end engineers are nine weeks into a backlog.
The AI assembles the setup screen from an element catalog and saved patterns: input validated before it saves, choices pulled live from the customer's systems, embed code returned. Adjust it in the designer yourself; the same form either way.
Not something their AI can do. Not reachable by asking: Workflow apps is on AIRO's published list of assets it cannot build. A person assembles the pages in the drag-and-drop builder, and inside the Embedded widget what is settable is field level, lock, hide or prefill.
A new customer connects, maps and goes live without anyone from your team on the call. On Workato, app visibility is a list the vendor maintains per customer.
Open the scenarioEvery new customer connection required a human on both sides.
310 schools want the gradebook-to-parent-messaging connection live in three weeks. Each takes a 40-minute screenshare with a Coursefold engineer: 206 hours of calls, four people in implementation.
Ask the AI for the connect flow, or build it yourself. Either way the registrar clicks connect, authorizes, maps what needs mapping, and is running, inside your product, without a Coursefold engineer on the call.
Their AI can provision the customer workspace and post connections. The accessible apps list is administration their documentation puts on you, added to by hand every time the app set changes, and the initial origin URL goes through a Customer Success Representative.
The assistant you ship resolves requests instead of deflecting them: real lookups, real writes, an approval gate before anything destructive, full logs. On Workato, the chat agent is buildable by asking.
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.
The AI builds the agent you ship: explicit goals, scoped tools, each tool an automation you can open and read. Or you wire the goals yourself. It acts through the same governed engine as everything else: real writes, approval gates, full logging.
Their AI can create a genie, author skills and assign them through published endpoints, so the chat agent itself is one ask, and getting to a working agent is not the difference.
Every surface a customer's IT team inspects, screens, addresses, callbacks, carries your name on every plan. On Workato, the brand items an auditor asks about route to a person.
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.
Ask the AI which hostnames the integration answers on and it lists them off the connectors and the embed code. The dev and production servers are yours, so the configuration screens, the webhook receivers and the authorization callbacks all answer on your domain from the first paid tier. If you also embed one of our hosted widget scripts, that file is served from ours, and that is the one line on the list you did not write.
Not something their AI can do. Not reachable by asking. The two items an IT director asks about, the origin and path prefix and your logo, sit on their own limitations list routed to a Workato Success Representative, and the embed, script and webhook hosts stay Workato names.
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.
Both AI layers operate rather than stopping at build, and their launch post claims the same reach inside an outside client: AIRO "works in developer tools such as Codex, Claude Code, Cursor, or any model context protocol (MCP)-compatible client, with the same capabilities it has in Workato." Take that at face value and count the phases. Reading what exists, building, running a test case, listing a recipe's jobs, starting and stopping a recipe, deploying and reading tenant usage are all calls their agent can make. Three stay off that list, and each is day-two work: tuning the platform's own alerting, where neither published index carries a notification or throttle call and the documented route is a monitoring recipe you then own; comparing two versions or putting one back, where the documented version response carries metadata and no recipe code; and writing back what the agent learned. Their procedures arrive as "CSV, DOC, DOCX, and PDF files up to 25 MB each" added by "Click Add Playbook", with no playbook endpoint in either published API index, and the write their CLI publishes on a version is "comment | Set or update the comment on a recipe version". So what the agent works out on Tuesday is written back by a person on Wednesday, or not at all.
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, and build is one procedure out of forty-two. On Workato, the runbook layer is documents a person keeps current.
Open the scenarioAn AI with raw API access improvises. An AI with encoded procedures repeats what works.
Day two. A customer reports a discrepancy, an API starts rate-limiting, a fix needs to reach the fleet. The question for the AI is no longer "can you build it" but "how much of this can you handle?"
One person and the AI cover the lifecycle. Day two looks like day one.
Not something their AI can do. Their AI plans, builds and fixes, which this page concedes. The runbook itself is not reachable from it: a person writes the document and uploads it through Add Playbook, and neither published index carries a playbook call.
Give an AI forty similar-looking tools and it picks the wrong one. Here it sees only the handful this job needs. On Workato, the tool list is an admin role, not a property of the job.
Open the scenarioDepth and focus are in tension: an AI drowning in tool definitions gets worse, not better.
Friday, 16:40. The integration lead has the AI retune a load-tender mapping inside 61 automations, a change 40 dispatchers need Monday. Every irrelevant tool is another way to reach the wrong one.
Sanne asks for the retune and the session loads that procedure with the tools it needs, the connector and mapping edits, a test run against real data, the alert rules, not all 138. The rest stay one request away when the job widens. Or she makes the same edits in the editor herself, on the same automation either way.
Not something their AI can do. Not reachable by asking: the agent's tool list is an API client role in Workspace admin, sized by whoever administers the workspace rather than by the job, and scope is fixed per connection, so two workspaces at once means two authorisations.
The AI files the platform defect it hits, so it gets fixed instead of papered over by an undocumented workaround. On Workato, the platform bug lands on a person and a ticket.
Open the scenarioAgents silently working around platform bugs means the bugs never get fixed.
The platform layer behaves differently than documented, the AI routes around it, and that detour is permanent, undocumented, and a 2am problem next hail season. The supervisor has inherited three.
The AI files the defect itself: a structured report to engineering, autonomously, instead of routing around it and shipping. Or Marla files one from the same session. Either way the detour becomes a record with the defect attached, not an undocumented workaround somebody inherits. The tools get better because the agent using them is also their reviewer.
Not something their AI can do. Workato does not document this. We searched the AIRO and AIRO MCP pages, Acumen, both published endpoint indexes and the 2026 changelog. On that basis it is manual work rather than a platform behaviour: a person writes the ticket.
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: ask for it, watch it get built at whatever depth the API allows, prove it, ship it, and change it later without a rebuild. On Workato the same job was reachable when someone had already built the piece you needed, at the depth they chose to build it, and priced by how many records moved through it. Not because their product is careless. It is widely used and it gets to a working result quickly, and so does this one: any API, in hours, not quarters, driven by asking. Speed to a working result is not the difference. What differs is that its integrations are assembled from operations that people hand-authored one at a time, so what you can automate is bounded by what someone else already decided to expose, and what it costs grows with the volume you push through it. On APIANT the connector is generated from the API's own documentation and stored as data, which is why depth is not a roadmap request, a missing operation is a working session, and that depth ships as a product: one build serving every account, each customer's differences in settings. What you end up owning is an asset your team can read rather than a subscription to someone else's catalogue.
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 Workato on this page derives from Workato's public documentation, help centre, developer platform docs and pricing page as reviewed in August 2026. Direct quotes are reproduced verbatim for comparison purposes. All product and company names are trademarks of their respective owners. Platform capabilities evolve; verify anything decision-critical against the current versions of the linked pages.
