Make (the automation platform formerly branded Integromat, unrelated to the build tool of the same name) is a reasonable choice for connecting an ERP system to the rest of your stack, provided you treat it as an integration layer and not as the system of record. The visual scenario builder makes the happy path fast to wire up — an order webhook, a lookup module, a create-record module — but ERPs are exactly the kind of system that punishes anyone who skips the error-handling half of the job, and Make's error handlers are easy to leave at their defaults.
Which side owns the trigger
The first design decision is whether Make polls the ERP or the ERP pushes to Make. Most ERPs, Acumatica included, support outbound webhooks (Acumatica calls them generic inquiries wired to business events, or a direct webhook notification depending on version) that fire on record changes. Where that's available, use it — polling a REST endpoint every few minutes for "what changed" is extra load on the ERP and adds latency equal to your poll interval. Where the ERP has no usable webhook for a given entity, Make's scheduled polling module is the fallback, but keep the interval realistic; polling a large entity list every minute to catch changes that happen a few times a day is wasted API quota on both ends.
Use the REST module, not generic HTTP, once you can
Make's generic HTTP module works for a first pass, but it means you're hand-rolling auth headers, pagination, and retry logic in scenario-level modules instead of relying on a connector that already understands the API's quirks. If your ERP has a Make app (Acumatica does not have an official one; most integrations go through the contract-based REST API via the generic HTTP/OAuth modules, or through middleware), building a small internal API in front of the ERP that Make talks to over plain REST is usually cleaner than making every scenario reason about the ERP's native API shape directly.
{
"name": "ERP Order Sync",
"flow": [
{"module": "webhook:customWebhook", "name": "Order Created"},
{"module": "http:ActionSendData", "name": "Fetch Order Detail",
"parameters": {"url": "{{env.erp_base}}/entity/Default/23.200.001/SalesOrder/{{1.orderId}}"}},
{"module": "tools:setVariable", "name": "Map Fields"},
{"module": "http:ActionSendData", "name": "Post to ERP",
"parameters": {"method": "PUT", "url": "{{env.erp_base}}/entity/Default/23.200.001/SalesOrder"}}
]
}Error handling is not optional on ERP scenarios
An ERP write that fails halfway can leave a document in an inconsistent state — a sales order created without its line items, an inventory adjustment posted twice because a retry re-ran a non-idempotent call. Make's error handler routes (Ignore, Resume, Break, Commit, Rollback) exist specifically for this, and the default of just letting a scenario error out and stop is the wrong choice for anything that writes to a ledger-backed system.
If a scenario can retry a create-record module, that module needs a natural key to check against first — an external reference field, an order number, something the ERP can use to detect "this record already exists" rather than creating a duplicate. Bolt this on after the fact and you'll be reconciling duplicate sales orders by hand.
Rate limits and batching
ERPs are typically not built for high request volume from an integration layer — a REST endpoint that's fine for a handful of interactive users can throttle or slow down hard under a Make scenario looping over a few thousand records one API call at a time. Batch where the ERP's API supports it, and add deliberate throttling (Make's built-in sleep module, or a rate limiter in front of the ERP) rather than discovering the ERP's tolerance the hard way in production.
Observability beyond Make's own history
Make keeps an execution history per scenario, which is enough to debug a single failed run but not enough to notice a pattern of failures across a week. Pipe scenario failures to somewhere with alerting — a webhook to Slack or a monitoring tool on the "Break" error handler route — rather than relying on someone checking the Make dashboard. The failures that matter on ERP integrations are rarely the loud ones; they're the quiet partial failures where three line items imported and the fourth silently didn't.
A 400 from an ERP's REST API usually carries a structured validation message — which field failed, which business rule blocked the save. Make's default error output often surfaces just the status code. Capture the response body in your error route; it's the difference between "something failed" and "the customer's tax zone is missing."
Wrapping up
Make is a solid layer for ERP integration as long as the scenario design assumes failure: explicit error routes, idempotent writes keyed on a natural identifier, throttled batches, and alerting that doesn't depend on someone opening the execution history. The visual builder makes the wiring quick; the reliability comes from the parts that aren't visual — retries, dedup keys, and where the trigger actually lives.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.