Accentra
Celigo iPaaS

Celigo integration, built like software.

We design, build and support Celigo integrations for Australian businesses, version-controlled, linted before promotion, and documented flow by flow. Most Celigo work is done by hand in a browser and lives in one person's head. This is the alternative.

Discuss your integrationSee our work

Celigo is not a plugin you install. It is an integration platform with a data model, an execution order, a failure model and an operational surface, and integrations built without understanding those go wrong in ways that are expensive and slow to find.

This page is longer and more technical than most agency pages, on purpose. If you are choosing an integration partner, the useful signal is not how many logos they can show you. It is whether they can describe how the platform actually behaves. So here is ours.

How the platform composes

Five primitives, one build order.

Everything in Celigo is assembled from connections, exports, imports, flows and integrations, with JavaScript hooks running inside flow execution. The higher-level resources (tools, APIs, AI agents and MCP servers) all package those same primitives behind a stable contract.

Build order
  1. IntegrationContainer. Groups flows, settings and connections.
  2. FlowThe unit of execution. Chains sources to destinations.Script hooks attach here
  3. Export + ImportSource step, then destination step.
  4. ConnectionCredentials and config for one external system.
Five primitives compose every integration on the platform. You read this top down, but you build it bottom up: a flow cannot exist before the export and import it chains, and neither can exist before the connection they authenticate through. Getting that order wrong is the most common reason a first Celigo build stalls.
What a real flow looks like

The steps are hiding inside the branches.

This is the single most useful structural fact about Celigo, and the one that most often makes an inherited account look simpler than it is. If someone hands you an integration audit that counts one step per flow, they read the top level and stopped.

Top-level read reports1 STEPActual8 STEPS / 3 BRANCHES
ExportScheduled
Router, fans out to 3 branches
  • Branch 0 / new orders
    1. 1.lookup: customer
    2. 2.map
    3. 3.import: sales order
  • Branch 1 / amendments
    1. 1.lookup: existing SO
    2. 2.script: preMap
    3. 3.import: update
  • Branch 2 / unmatched
    1. 1.script: classify
    2. 2.import: exception queue
The thing that catches everyone out. Celigo nests almost every step inside router branches, at routers[].branches[].pageProcessors[], and leaves the top level pageProcessors list empty. Read only the top level, as most documentation tools and most people do, and a flow like this one reports one step. The real flow has eight, across three branches, each with its own mappings, scripts and failure modes. Every audit we run walks the branches explicitly, because that is where the integration actually lives.
Where the code runs

Hook points, in execution order.

  1. 1
    preSavePageAfter the export reads a page

    Filter or reshape records before they enter the flow.

  2. 2
    preMapBefore field mapping

    Enrich or look up values the mapper will need.

  3. 3
    postMapAfter field mapping

    Correct the mapped payload before it is submitted.

  4. 4
    postSubmitAfter the destination responds

    React to the write: chain, log or compensate.

  5. 5
    postResponseMapAfter response mapping

    Reshape what the flow carries forward.

Where your JavaScript runs, in the order it runs. Choosing the wrong hook point produces integrations that pass testing and fail in production. Enriching data in postMap when the mapper needed it in preMap is the classic version. There is also preSend for request level changes and handleRequest for API and tool endpoints.
Build surface

What we actually build on Celigo.

Flows, exports and imports

The core build. Scheduled and real-time flows, delta exports with checkpointing, webhook triggers, multi-branch routers, and imports with lookups and upsert logic. This is most of the work on most projects.

JavaScript hooks

preSavePage, preMap, postMap, postSubmit, postResponseMap, preSend and handleRequest. Written as reviewable source, not pasted into a text box and forgotten.

Lookup caches

In-memory key-value stores for cross-reference resolution, deduplication and state tracking across a run. The difference between a flow that makes 10,000 lookup calls and one that makes none.

API Builder

Custom HTTP endpoints that let external systems query or push data through your integrations synchronously, with a real response instead of a queued job.

B2B and EDI

Trading partner onboarding, EDI profiles, file definitions, X12 and EDIFACT parsing, and functional-acknowledgement handling for partners who still exchange documents this way.

AI agents, tools and MCP servers

Celigo's newer surface: agent imports for classification and extraction, guardrails for PII and moderation, reusable tools, and MCP servers exposing your integrations to AI clients.

How we work

Treated as engineering, not as clicking.

The common failure mode with iPaaS work is not a bad flow. It is an account nobody can safely change two years later, because every decision lives in a UI with no history and no owner. Four practices prevent that.

Flow config lives in Git

Every flow, export, import and script is pulled to disk and committed. You get a diff for each change, an owner, and a way back. Not a screenshot of a UI panel from six months ago.

Linted before it reaches production

celigo account lint runs static analysis across every integration, flow and script, catching broken references, missing required fields and common script errors. It runs in CI before a promotion, not after a failure.

Driven from the CLI, not only the UI

Celigo shipped a first-party CLI in April 2026. It makes bulk edits, dependency graphs, account-wide search and scripted promotions possible. Most integration work is still done entirely by hand in a browser.

Documented flow by flow

What each flow moves, on what schedule, through which branches, with which scripts, and what breaks it. Written down where the next person will find it, including when the next person is you in a year.

The failure path

What happens when a record fails.

  1. Record submittedIf it succeeds, it completes.
  2. Open errorPayload and HTTP trace retained.
  3. RetryExponential back-off.
  4. ResolvedA clean replay closes it out.
  5. Assigned to an ownerOnly when retries are exhausted. Once the fix ships the record re-enters retry.
What happens to a record that fails. Most integrations are judged on this path rather than the happy one. A flow that moves 10,000 orders and silently drops four is worse than one that stops and tells you. Celigo retains every errored record with its payload and HTTP trace, so a retry replays the actual data instead of asking the source system to send it again.
Australian commerce

Four things that break integrations built offshore.

None of these are exotic. They are the default conditions of running commerce in Australia, and they are where integrations built to a US or European model quietly produce wrong numbers.

GST is in the price, not added at checkout

Australian retail prices are GST-inclusive. Integrations built for US tax models add tax on top, so totals reconcile to the cent in testing and drift in production. Tax handling has to be settled in the mapping, not discovered in the month-end close.

Multi-warehouse and click & collect

Stock that exists in one location, is reserved in another, and is collected from a third. Getting availability right means modelling location-level inventory, not a single quantity field, and deciding what the webstore is allowed to promise.

Australian carriers and 3PLs

Australia Post and eParcel, StarTrack, Shippit, StarShipIT, Aramex, and 3PL warehouse systems that each have their own idea of what a consignment looks like and when tracking becomes available.

Local payments and marketplaces

Afterpay, Zip and PayTo settle differently from card payments, which changes how the finance reconciliation flow has to work. Amazon AU, eBay AU and The Iconic each impose their own fulfilment and messaging rules.

Straight answers

Questions worth asking any Celigo partner.

Are you a certified Celigo partner?

We work with Celigo as our primary integration platform, with hands-on delivery experience right across its build surface: flows, hooks, lookup caches, API Builder, EDI, and the newer AI and MCP resources. If formal partner tier matters for your procurement process, ask us and we'll tell you exactly where we stand rather than leaving it implied.

How is Celigo licensed, and what does it cost?

Celigo prices on a flat-rate basis metered by endpoints and flows, not by task or record volume, and it does not charge overage fees, so a peak trading period does not produce a surprise invoice. There are three editions: Standard, Professional (adds API Builder, lookup caches, SSO and a sandbox environment) and Enterprise (unlimited endpoints, deeper governance and audit, fastest support SLAs). Celigo does not publish figures publicly; pricing comes through their sales team. The edition question that actually matters is whether you need a sandbox, because that lands you on Professional at minimum.

How does Celigo compare to Workato, Boomi, Jitterbit or Patchworks?

Celigo is purpose-built for business system integration and is strongest where you are connecting an ERP to commerce, CRM, finance and fulfilment systems with pre-built connectors and deep platform-specific logic. Workato is a broader automation platform and wins when the requirement is complex multi-step workflow across IT and business teams. Boomi suits large multi-entity, multi-region estates with heavy governance requirements. Jitterbit and Patchworks are both credible for commerce-centric integration, with Patchworks especially common in UK and AU Shopify work. We recommend Celigo for most ERP-and-commerce work; we will tell you when a different platform fits better.

Can you take over an existing Celigo account someone else built?

Yes, and it is a large share of what we do. We start with an audit: every integration, flow and script inventoried, dependencies mapped, error backlogs reviewed, and undocumented flows walked branch by branch so nothing hides inside a router. You get a written picture of what you actually own before anyone changes anything.

What happens when an integration breaks at 2am?

Errored records are retained with their payload and HTTP trace, so a retry replays the real data instead of asking the source system to resend. We configure retry policies with exponential back-off, route alerts to the channel your team actually watches, and set escalation for the failures that need a human. The goal is that a failure is visible and replayable, never silent.

When is Celigo the wrong choice?

When you have exactly one simple integration and a native connector already does it, an iPaaS is overhead you do not need. When your requirement is high-volume, low-latency event streaming rather than business record synchronisation, purpose-built infrastructure fits better. And when nobody on your side will own the integration after go-live, no platform saves you. That is an operating model problem, not a tooling one.

Related:Celigo vs WorkatoiPaaS vs custom codeHow we deliver integrationsERP integrations

Inherited a Celigo account you don't fully understand?

That is the most common reason people call us. We start with an audit, every flow walked branch by branch, dependencies mapped, error backlog reviewed, so you know what you own before anything changes.

Book a consultation See our work