The question that decides the price
Before anyone quotes, ask your vendor one thing in writing: do you provide an API for this, is it documented, and does it cost extra?
A system with a good API might be two weeks of work. The same functionality against a closed system might be two months, or genuinely impossible.
The options, best to worst
- Official API — supported, documented, safe. Ask even if you assume the answer is no.
- Supported export and import on a schedule. Unglamorous, low risk, adequate for most sync and reporting needs.
- Read-only database replica where you control the database. Excellent for reporting with no risk to the live system.
- Interface automation — last resort. Fragile, breaks on any interface change, needs constant attention.
We will build interface automation as a bridge, with the maintenance cost stated plainly. As a permanent architecture it accumulates cost quietly and we will say so.
Vendors who charge for their API
It is increasingly common and it is a legitimate cost to weigh. What matters is that you know the figure before scoping rather than discovering it mid-project.
Where the charge is punitive, that is worth knowing for a different reason: it tells you what leaving would cost, which is a fact about your dependency rather than about the project.
Negotiate at renewal, not at build time
- API access included, or at a stated price
- Full data export on demand, in an open format, at no charge
- Notice of breaking changes to any interface you depend on
- A sandbox environment for testing
These are far easier to obtain at renewal than in the middle of a project when the vendor knows you are committed.
When the honest answer is to change vendor
If integration is impossible or priced punitively, and the system is central to your operation, that is a genuine argument for replacement — but it is a bigger project than the automation you wanted.
We will lay out both, with numbers, rather than quietly proposing the larger one.