API integration vs file-based exchange for NZ ERP systems: how to choose

Most guidance on ERP integration defaults to "use the API." The advice makes sense for cloud ERP systems — NetSuite, SAP Business Cloud, MYOB Acumatica — where the API is comprehensive, well-documented, and designed for external integrations. It makes less sense for the on-premises ERP systems that many NZ mid-market businesses actually run: Accredo, MYOB Exo, CSB-System, Pronto Xi. With those systems, the API (where one exists) covers some operations well and others poorly or not at all. File-based exchange — scheduled CSV or XML exports and imports — is not a legacy fallback in those environments. It is often the correct pattern for specific data flows.

This guide is for NZ businesses connecting an on-premises ERP to a B2B ordering portal, a warehouse system, a reporting platform, or another operational application. It covers what each integration method actually does well, the specific NZ ERP context that generic API-first guides ignore, the hybrid approach that most practical integrations end up using, and four failure modes to design around before go-live.

What REST API integration actually means for an NZ ERP

A REST API integration connects two systems over HTTPS. The calling system sends a request — read this customer's credit limit, create this sales order, look up the current price for this SKU and this account — and the ERP responds in real time. The interaction is immediate, stateless, and designed for the kind of on-demand queries that a user or an application might make at any moment.

For on-premises NZ ERPs, the REST API story varies significantly by product.

Accredo provides a REST API with solid coverage of the operations that matter most for B2B portal integrations: debtor record reads, inventory availability, sales order creation, and pricing reads at the account and SKU level. It handles the real-time operations a B2B portal needs — credit limit confirmation before order acceptance, live stock check at checkout — well. The coverage gaps matter: complex pricing hierarchy reads (particularly debtor specials, multi-level quantity breaks), historical transaction data, and some inventory movement records are more reliably accessed outside the API.

MYOB Exo has narrower API coverage. The Exo API supports a subset of operations; several integration requirements that arise naturally in a wholesale portal project — complex pricing reads, workflow events, high-volume batch operations — fall outside what the API handles well. Exo integrations frequently combine a limited use of the API for the operations it supports with direct database reads or file exports for everything else.

CSB-System integrations are primarily file-based. CSB-System supports data exports and imports via structured files; API-level access is limited and depends heavily on the specific configuration and version. For CSB-System, file-based exchange is not a workaround — it is the designed integration path for most data flows.

Pronto Xi supports both API and file-based exchange, with API coverage that has expanded in recent versions. The specifics of what is and is not accessible via the Pronto API vary by version, configuration, and licensing.

What file-based exchange actually means

File-based exchange is the pattern where one system exports data to a file (typically CSV or XML) on a schedule, and another system picks up and imports that file. The schedule might be every 15 minutes, hourly, or once per day — depending on how current the data needs to be.

Most NZ on-premises ERPs support scheduled file exports as a core feature, not as an afterthought. Accredo, MYOB Exo, and CSB-System all have export mechanisms that can generate structured data files for inventory, customer records, orders, pricing, and more. The export format, schedule, and destination are configurable. The integration layer picks up the file, transforms it if needed, and loads it into the target system.

File-based exchange is not inherently slower or lower-quality than API integration. At a 15-minute schedule, inventory data is current enough for most B2B portal use cases. At an hourly schedule, product and pricing data is accurate enough that stale-price errors at checkout are rare rather than common. The limitation is that file exchange cannot support genuine real-time interactions: a stock confirmation that needs to happen in the same moment as a customer's checkout click cannot wait for the next scheduled file run.

When API integration is the right choice

API integration earns its additional complexity in four specific scenarios:

• The interaction is genuinely real-time. A customer checking stock availability at the product page level, a credit limit confirmation happening as the customer submits an order, a price lookup happening as a line item is added to a cart — these are moments where the data needs to be current to the second, not current to the last file run. File-based exchange cannot provide that. An API call can.
• The ERP's API covers the operation well. If the Accredo API returns the data you need accurately and completely, use it. Do not route through a file export and a transformation step when a direct API call is simpler. The point is to use the right method for each operation — not to pick one method for everything.
• The data volume per request is low. Reading one customer record, one product's inventory level, one order's status — API is efficient at this. Reading 10,000 product records in a nightly catalogue update is not what a REST API is designed for; that is a file export operation.
• Write operations need immediate confirmation. When a sales order is created via the B2B portal and the ERP needs to return an order number or a confirmation status synchronously, a direct API call is the right pattern. A file-based import that creates the order in the ERP 15 minutes later cannot return an ERP order reference in real time.

When file-based exchange is the right choice

File-based exchange is the right pattern in four specific scenarios — and in each of them, it is not a compromise but the correct choice:

• High-volume batch operations. Syncing 8,000 product records from your ERP to your B2B portal nightly, or importing 300 orders from the portal into the ERP at end of business, is a batch operation. Doing this via 8,000 individual API calls (or 300 order-creation API calls in sequence) is slower, harder to monitor, and more fragile than a single structured file export and import. The ERP's export mechanism is designed for this; use it.
• The ERP API does not cover the data you need. If the operation falls outside what Accredo, Exo, or CSB-System exposes via API, file-based exchange is not a workaround — it is the only available integration path. Pretending otherwise means building fragile direct database access that breaks on ERP upgrades, or maintaining a workaround that should have been designed as a file flow from the start.
• Latency requirements are low. Most product catalogue data, pricing, and inventory does not need to be current to the second. A 15-minute inventory sync is accurate enough for most B2B portal configurations. File exchange at a 15-minute cadence is simpler to operate and monitor than a continuous polling API approach at the same frequency.
• Reliability and auditability matter more than speed. A file export is easy to audit: the file exists, you can inspect it, and you can re-import it if the initial load fails. A batch API operation that fails partway through requires careful error handling and retry logic to recover to the same clean state. For financial data — order records, invoice exports, payment files — the auditability of file-based exchange is often the deciding factor.

The hybrid approach most NZ integrations end up using

The API vs file debate is often framed as a binary choice. In practice, most B2B portal and ERP integrations in NZ use both — with each method assigned to the flows it is suited for.

A typical split for an Accredo-to-B2B-portal integration:

• API calls (real-time): credit limit check at order submission, live stock confirmation at checkout, current pricing lookup for a specific account and SKU when a cart line item is added.
• File export (batch): nightly product catalogue sync from Accredo to the portal (full product master, prices, images), end-of-day order import from the portal into Accredo, daily customer record sync (new accounts, changed credit limits, account status updates).

This hybrid maps to what each method does well. The API handles the moments where the customer is waiting for a response. The file exchange handles the volume operations where a slight delay is acceptable and a clean, auditable batch is valuable. A design that uses only API calls tries to do batch work through a real-time mechanism. A design that uses only file exchange cannot support real-time checkout operations.

Four failure modes to design around

The most common integration failures in NZ B2B portal projects are not technology failures — they are design failures that the technology cannot compensate for. Four recurring patterns:

1. File export assumptions that break on ERP change. File-based integrations that read from a specific export format or ERP report break when the ERP is updated, a report is reconfigured, or column ordering changes. File integrations need schema documentation and version-awareness built in from the start, not retrofitted when something breaks.
2. API error handling treated as optional. API calls fail. The Accredo server is temporarily unreachable, a VPN timeout occurs, a malformed request returns a 400. An integration that does not handle API errors explicitly — with retry logic, clear error states, and a way to alert on persistent failures — will surface these failures as customer-facing errors (stock check returning nothing, order submission silently failing) rather than as operational alerts that the team can act on.
3. Synchronous API used for batch operations. Using individual API calls to sync 5,000 product records is slow, inefficient, and fragile. When a nightly sync takes three hours via API because the volume was underestimated and the solution was not designed around file export, the problem is not the API — it is the choice of method. Batch volume should trigger file-based design at the start of the project, not after the API approach proves too slow.
4. No monitoring on file-based flows. File-based integrations feel simpler than API integrations, which creates a tendency to leave them unmonitored. A file export that silently stops producing files — because a scheduled task failed, a network path changed, or a disk filled up — can go undetected for days. Every file-based integration needs monitoring: confirm the file was produced, confirm it was picked up, confirm it was imported without errors, and alert on any of those not happening within the expected window.

The decision is about data flows, not technology preference

API-first is not better than file-based as a general principle. For NZ businesses on Accredo, MYOB Exo, CSB-System, or Pronto Xi, the right approach is determined by what each specific data flow requires: how current the data needs to be, what volume is involved, whether the ERP API covers the operation, and whether the interaction requires a synchronous response.

Most integrations benefit from documenting every data flow before the build starts — what moves, from which system to which, at what frequency, in which direction — and assigning each flow to the method it suits. The ones that need real-time response get API calls. The ones that are high-volume batch get file exchange. The ones where the ERP API has gaps get whatever access method the ERP actually supports reliably.

The ERP integration middleware post covers the architecture question one level up — when to use a middleware platform versus a custom integration layer to manage these flows. For businesses still working out whether to integrate an existing ERP or move to a different one, the replace vs integrate guide covers that decision. Zeabyte's integrations page covers the specific ERP and platform connections we build — including Accredo, MYOB Exo, CSB-System, Pronto Xi, SAP, NetSuite, and more than twenty others — and the approaches we use for each. If you want to talk through what the right integration design looks like for your specific ERP environment, reach out to the team — we design and build custom ERP integrations for established NZ businesses.