Integrating an ERP Without an API: File Exchange, Database Access, RPA, or Replacement?

You can integrate some legacy ERP workflows without a modern API. Start by checking supported file imports and exports, licensed integration modules and approved read-only data access. Use middleware to coordinate those interfaces. Consider UI automation only where the actual deployment and recovery process are viable; consider replacement when the required business outcome cannot be supported safely.

The question is not whether somebody can move data once. It is whether the business can distinguish an accepted transaction from a rejected, duplicated or still-unknown one, and keep doing so after an ERP upgrade or a failed overnight run.

This guide compares decision criteria for legacy ERP integration without an API, not connector prices or a generic ERP selection exercise. Product documentation was reviewed on 29 September 2026. Named systems illustrate specific interface boundaries, not a claim that those products lack APIs or that the same features exist in your installed version. Recommendations and scenarios below are our assessment framework, not results from a hands-on ERP benchmark.

What does “ERP without an API” actually mean?

Write down the product, edition, exact version, hosting arrangement and support provider before choosing a technology. Ask whether “no API” means no REST endpoint, no licensed access, no documentation, no access from the network, or no interface for the particular business operation. Those are different feasibility problems.

Ask the vendor about a supported SDK, SOAP service, EDI interface, scheduled report, command-line importer or documented staging mechanism. A paid module might solve the problem more cleanly than screen automation. Verify its object coverage and recurring entitlement before treating a brochure or partner demonstration as proof.

Separate read, write and post or approve. Reading stock for a dashboard does not reserve stock. Creating an order draft does not authorize its release. Exporting invoice lines does not prove that a payment was allocated. Describe the accepted business state, including who is allowed to cause it.

For an ERP that already exposes an API, our Odoo API integration limits guide addresses a different problem: designing around an available API's constraints. Here, the first deliverable is an evidence-backed inventory of usable interfaces, not a new backend.

File exchange, database access, middleware, RPA or replacement?

Choose an access method per operation, not one technology for the entire company. A reasonable result might combine a read-only reporting feed with a supported order import and a manual exception queue.

This is narrower than a general custom software versus off-the-shelf decision. An integration assessment can legitimately recommend keeping the ERP, buying an existing module or retaining one manual step.

When supported file exchange is enough

Do not dismiss CSV or XML because the transport looks old. Microsoft documents file mappings, transformations and validation hooks in Business Central's data exchange framework. Microsoft: file mapping and validation That is evidence of structured file-processing capabilities, not proof that every document type in every deployment has an unattended importer.

Obtain the actual specification and sample accepted and rejected files. Confirm character encoding, date and decimal formats, currency, units, leading zeros, nulls, company identifiers and master-data prerequisites. Establish whether a multi-line document is accepted as a whole or can leave partial state. A bank-file feature is not automatically a sales-order interface.

Define the handoff contract: immutable batch identifier, individual source references, schema version, record count, integrity check and a clearly signaled completion boundary. Consumers must not process unfinished uploads. WinSCP documents a temporary-name-then-rename mechanism for SFTP binary transfers. WinSCP: completed-upload handoff Test the chosen server's behavior and configure the importer to ignore temporary files; do not assume every FTP or shared-folder setup has the same semantics.

Then distinguish receipt from acceptance. NetSuite's CSV status documentation notes that an afterSubmit error can occur after a record was created or updated; the whole import should not be repeated for that case. Oracle: NetSuite import outcomes An error label alone therefore cannot decide the retry policy.

A production-ready file workflow should expose which source objects became which ERP documents, which failed validation and which still need investigation. Agree the retention period for source files and evidence, with sensitive fields minimized. Include the scheduler, credentials, storage, monitoring and manual exceptions in the operating estimate. A person uploading a file every day remains part of the process until unattended execution is actually supported and tested.

What approved read-only database access can and cannot solve

Ask for a documented reporting view, supported query service or approved replica before asking for unrestricted production database credentials. NetSuite's SuiteAnalytics Connect, for example, is explicitly read-only and cannot update NetSuite data. Oracle: the Connect read-only boundary A supported query surface and direct access to an application's physical tables are not interchangeable.

Do not turn a read-only proposal into undocumented writes to ERP transaction tables. SAP Business One's SDK Recordset documentation permits DML for user tables but warns that system-table writes are unsupported and risk corruption. SAP: Recordset support boundaries That is a specific SAP interface rule, not a universal claim about every ERP contract. Vendor-approved staging tables or documented business-object interfaces need their own review.

For extraction, have the ERP owner explain each field's business meaning. Is “quantity” physical stock, available stock or allocated stock? Does an amount include tax? Which company and document status does a row belong to? Join keys and source timestamps alone are not a data contract.

Read-only does not mean operationally harmless or automatically consistent. Microsoft warns that SQL Server NOLOCK/READUNCOMMITTED can expose uncommitted data and duplicate or omit records. Microsoft: SQL read-consistency warnings Do not prescribe that hint as a universal cure for integration load. Ask the DBA to approve the consistency strategy, timeouts, query plan and workload window; test alongside representative ERP activity.

For incremental extraction, prove how updates, deletions and corrections are discovered. SQL Server change tracking requires checking the retained minimum version; an expired synchronization position needs reinitialization. Microsoft: recovering change-tracking consumers Enabling change tracking or CDC is a separate administrative and support decision, not an automatic right granted by read access. A modified-date filter is not proof that deletions or late corrections will be captured.

Specify an initial snapshot, a recoverable synchronization position and a periodic comparison with the authoritative ERP view. Also specify what downstream users see when the feed becomes stale. A reporting copy must not quietly become the authority for stock reservations or financial posting.

What middleware adds, and what it cannot invent

Middleware can own mappings, schedules, queues, credentials, identifiers and exception routing. It can expose an API to a new portal while using a file or approved query interface behind it. The portal's API is then your integration contract, not a new transactional API magically added to the ERP.

Network connectivity is another separate concern. Microsoft's on-premises data gateway uses outbound connections rather than requiring inbound ports. Microsoft: gateway connection model That deployment option does not grant permission to a database or add a missing business operation. Verify the chosen gateway's supported sources, ownership and upgrade obligations.

Keep a durable record per business object: source system and company, source identifier, operation, payload version or hash, ERP identifier, observed state and next permitted action. Track received, validated, submitted, confirmed, rejected and outcome-unknown separately. Never display “synced” merely because a file was uploaded or a job was queued.

AWS's idempotency guidance distinguishes request identity from identical content and explains why the deduplication record and mutation need atomic handling. AWS: request identity and safe retries Applied to a legacy integration, our conclusion is limited: a middleware log alone cannot guarantee exactly-once ERP effects. A crash can happen after the ERP commits but before your log records success.

Before retrying, prove a supported lookup by stable reference or another trustworthy confirmation mechanism. Where available, test target-side uniqueness under concurrent submission. Reusing the same identifier with changed content must trigger an explicit conflict or approved update process, not silently become a second order. Where certainty is unavailable, stop for investigation rather than converting an unknown result into a duplicate.

When UI automation is a reasonable boundary

Use UI automation as a candidate for a specific workflow, not the default answer to “ERP integration no API.” UiPath documents selectors based on element attributes rather than only coordinates; changing layouts or dynamic attributes still require care. UiPath: selector behavior Test the actual legacy client, not a modern demonstration application.

The deployment topology matters. Power Automate's unattended documentation identifies session restrictions and warns that unattended display resolution can differ from the development session. Microsoft: unattended-session constraints A flow working while a developer watches is insufficient evidence for the overnight operating model.

Virtual desktops need their own check. Microsoft's Power Automate documentation requires its virtual-desktop agent for supported remote automation and lists platform limitations. Microsoft: virtual-desktop requirements Confirm the exact RDP or Citrix configuration, installation approval and version compatibility; do not assume remote screen access provides the same element controls as a local installation.

Our proposed release conditions are explicit input validation, approved credentials, a permitted session model, verification of the selected company and record, and an authoritative result check. Keep a human approval step where the business impact requires it. Do not disable MFA, endpoint protection or patching just to keep a bot running.

Measure representative throughput including login, waiting, validation dialogs and exception handling. Test concurrent human use, timeouts, expired credentials, changed labels, a locked record and a restarted machine. Define an owner for failed runs and a maximum tolerable backlog.

Computer-use models do not remove these acceptance conditions. A model-generated click still needs permission, bounded inputs and proof of the resulting business state. For sensitive posting or payments, a screenshot that appears successful is not a sufficient basis for an automatic retry or release. A useful outcome can be attended document preparation with the final decision retained by an employee.

Failure handling: 120 submissions are not 120 completed transactions

Illustrative scenario, not a customer result: a batch contains 120 source orders. The integration confirms 117 ERP documents, has two definitive validation rejections and loses the response for one submission. The reconciliation is 120 = 117 confirmed + 2 rejected + 1 outcome unknown, not “three failures to retry.”

Keep the 117 confirmed source-to-ERP mappings. Correct the two rejected orders and resubmit only after establishing that no business document was committed. For the unknown one, search through the approved interface using its stable reference and inspect the relevant state. Do not blindly replay the whole batch. Without a reliable way to resolve the unknown result, unattended submission has failed an important feasibility gate.

Counts are only the first check. Compare business identifiers, company, document status, line quantities, currency and relevant totals. Test revisions, cancellations and out-of-order delivery. An equal total can conceal the wrong document allocation, so preserve object-level evidence rather than a single green dashboard number.

Recovery is not always a technical rollback. Microsoft describes compensation as business-specific and potentially requiring manual intervention. Microsoft: business-specific compensation For an ERP integration, agree supported cancellation, correction or reversal paths with the business owner. Do not delete transactional rows or restore the entire production database to undo one duplicate.

Define who investigates an unknown result, who may authorize a correction, how downstream work is paused and when to escalate. Exercise the runbook with failed cases. A retry counter without a business owner is not a recovery process.

What a paid integration-feasibility assessment should establish

Buy a decision before buying an implementation. Start with one representative workflow and its success criteria, then test the most consequential uncertainty. Provide redacted examples, interface documentation, deployment details, relevant license terms and access to an authorized ERP contact. Share access through an approved process, not passwords in an email attachment.

Label evidence honestly: vendor-documented, confirmed in the assessed environment, demonstrated only in a test, proposed, blocked or not tested. A prototype proves only what was observed under its stated conditions. It does not establish production reliability, upgrade compatibility or sustained peak throughput by itself.

The assessment cannot remove a vendor dependency that remains unresolved. Missing documentation or access may prevent a conclusive implementation estimate. A useful paid result can identify that blocker and the exact evidence needed to reconsider it, rather than promise a fixed build price on an assumption.

Which failure cases should the buyer insist on testing?

Use the following as a proposed acceptance pack. Agree pass criteria and owners before a demonstration, then retain evidence for each relevant case. “Not applicable” requires a reason; “not tested” is not a pass.

Three illustrative decisions, with different valid outcomes

A distributor with a next-morning synchronization requirement

Assume its installed ERP has a supported order import, scheduled stock export and object-level results. The business accepts overnight latency. Start with those files and only the coordination needed for validation, secure transfer and exceptions. A full replacement or UI bot is not justified merely because REST would look more modern. First prove repeat-submission and partial-acceptance behavior.

A manufacturer that needs reporting, not transaction entry

Assume an approved reporting view exposes the required entities and a DBA accepts the extraction workload. Use read-only extraction with a defined freshness indicator and reconciliation. Keep reservations and posting in the ERP. A later demand for immediate stock commitments is a scope change requiring a supported write path, not a small enhancement to the reporting feed.

A screen-only workflow with limited volume

Assume the vendor allows the proposed access, the actual UI is automatable and an employee must approve the final document. Attended preparation may be sufficient. If the business instead demands unattended irreversible posting but no trustworthy outcome lookup or supported session model exists, do not proceed on the same design. Evaluate a vendor module, a controlled manual boundary or replacement.

These are invented decision scenarios, not project estimates. None establishes a universal cheapest approach, delivery duration or return on investment. Price the accepted workflow and ongoing responsibilities, including business exception work, against the real baseline.

When replacement, deferral or a no-go is the responsible result

Stop the proposed implementation when it depends on unapproved access, unsupported transactional writes, bypassing security controls or repeating irreversible actions whose outcome cannot be determined. Also stop when required freshness exceeds the source's observable update capability, or no one accepts operational ownership.

Stopping one design does not imply replacing the entire ERP. Reduce the scope to read-only reporting, retain a supervised import, obtain an approved module or defer the workflow until support conditions change. Distinguish an inconvenient limitation from a business-critical impossibility.

For replacement, Microsoft's Strangler Fig guidance describes incremental migration but notes that the pattern may not fit systems whose requests cannot be intercepted or whose source cannot be changed. Microsoft: phased-migration constraints Do not assume that a closed desktop ERP can simply receive a transparent API facade and gradually disappear.

Prove separable business boundaries, decide which system is authoritative during coexistence and plan historical data access, reconciliation, cutover and support. A staged migration is a candidate architecture, not a reason to promise zero disruption. The old and new operating costs can coexist until a real dependency is retired.

Scope a paid integration-feasibility assessment

Bring one workflow, the ERP/version, a redacted sample, available interface documentation, the required timing and examples of exceptions. Ask for an assessment scope that explicitly includes access approval, failure handling, supportability and a go/no-go recommendation. Agree its fee and deliverables separately from any implementation.

Wavect's custom software development services provide the commercial starting point for scoped integration work. The MyMerch process-automation case study offers adjacent delivery context, not proof of a no-API ERP implementation or compatibility with your system.

Request a paid ERP integration-feasibility assessment before commissioning the full solution. The next proposal should follow the evidence, whether the answer is configuration, a small adapter, supervised automation or no implementation.