A great deal of business critical software predates the expectation that everything has an API. That does not make it un integrable, and the available options are better than most people assume.
Start with the contract, not the documentation
The most common finding is that an interface exists and is not enabled.
Many established platforms, particularly in verticals like dealer management, property management and field service, have integration capability sold as a separate module or gated behind a partner programme. The documentation may not be public. The support desk may not know.
Before concluding that a system is closed, read the contract, ask the account manager directly, and ask specifically about an API, a data feed, webhooks, scheduled exports and a read replica. Ask in those terms, because a generic question about integration frequently gets a generic no.
Scheduled exports
A nightly or hourly file drop is a real interface. It constrains freshness, not feasibility.
What matters is whether the export is complete or incremental, whether it includes deletions, and whether it is atomic. An export written in place while you are reading it produces truncated files, so look for a write to a temporary name followed by a rename.
Build it properly: verify the file is complete before processing, record which files have been processed so a redelivery is not applied twice, and handle the case where a file is missing rather than assuming the schedule always runs.
The honest conversation with the client is about freshness. If inventory updates hourly, the website cannot show real time availability, and that constraint should be stated before anyone promises otherwise.
Read replicas
Frequently the best available option and the one people forget to ask for.
A vendor approved read replica can support reporting or extraction without writing to the operational database. Check replication lag, granted tables, query limits and supported schema access. It is not necessarily complete or current, and expensive queries can still affect its capacity. Writes need a separate supported route.
The caveats are real: the schema is undocumented and can change without notice, so pin what you rely on, monitor for structural changes and expect to adjust after vendor upgrades.
Vendor supported file exchange
Older enterprise systems often speak SOAP, fixed width files or EDI. These are unfashionable and completely workable.
Build an adapter that absorbs the awkwardness and presents a clean typed interface to the rest of your estate. The rest of the system should not know that a customer record arrived as a fixed width record at three in the morning.
What about screen scraping
Driving the user interface with a headless browser is possible and it is a maintenance commitment rather than an integration.
Layout changes can break a browser automation. Check the vendor's terms and obtain the necessary permission rather than assuming automation is allowed or prohibited. Multi factor authentication, session expiry and interactive challenges need an approved operating approach; bypassing them is not an integration strategy. Tests also need a stable environment and a way to detect when the production interface differs.
There are narrow cases where it is the right answer: a one time migration, a low frequency read of something genuinely unavailable elsewhere, an internal tool with a tolerant owner. Outside those, we will describe the risk plainly and recommend against it rather than take the work and hand you a maintenance problem.
Manual bridges, deliberately
Sometimes the honest answer is that part of the flow stays manual, and the software makes that step as fast as possible.
A screen can show what needs entering into the other system, in the order that system asks for it, with values ready to copy. Measure whether it reduces work in practice. Include a confirmation step and a reference to the resulting record so the manual boundary remains visible.
Name it as a deliberate design decision rather than letting it be the thing nobody mentioned.
Plan for the vendor changing
Whatever interface you use, assume it will change.
Keep the adapter isolated so a change affects one module. Monitor for structural drift, particularly with replicas and exports. Keep a reconciliation job that would notice if the data stopped arriving. And write down what you depend on, so that when the vendor announces an upgrade, someone can answer the question of whether it affects you.
Give a file exchange a receipt protocol
A file appearing in a directory does not establish that the receiving system accepted its records. Agree a batch identifier, expected record count, format version and completion signal with the vendor. A manifest or supported atomic rename can distinguish a finished export from one still being written. The exact mechanism depends on the storage system; a rename is not universally atomic across every remote service.
Stage the file before applying business changes. Validate the encoding, required columns and record identifiers, then report rejected rows separately from accepted ones. Do not silently discard a row because a field was added or a date failed to parse. Preserve enough source context for an operator to correct it without opening an unrelated customer record.
Send or record an acknowledgement appropriate to the exchange: received, validated, partly accepted or rejected. If the sender redelivers a batch after losing that acknowledgement, the batch identifier should retrieve the prior result instead of applying all rows again.
Finally define deletion semantics. A customer absent from a partial export has not necessarily been deleted. Require a documented tombstone, a complete snapshot contract or a separate approved reconciliation process before removing destination records. This decision is more important than the transport protocol when the receiving system holds operational history.