Older ERPs were closed boxes. Connecting one to anything else, a B2B e-commerce store, a reporting tool, a partner's system, meant a custom project quoted by the vendor or a consultant. An API-first ERP treats its API as part of the product: documented, supported and kept up to date. Connecting a tool becomes a job for any competent developer rather than a negotiation.
What an API is, in plain words
An API (application programming interface) lets one program ask another for data, or make a change, without a person clicking through screens. "Give me every order shipped yesterday." "Create this customer." "How much of this item is on hand in the main warehouse?" A REST API does this over the web, with each kind of record (customers, items, orders) at its own address.
What API-first should mean in practice
- Coverage of the records you work with. Customers, items, stock, orders and purchase orders at a minimum. Check which records can only be read and which can also be created, changed or deleted.
- Keys you control. You create API keys yourself, give each one only the access it needs, and revoke it without calling support.
- Published documentation and schema. A machine-readable description of every endpoint and field, often an OpenAPI schema, so a developer can generate client code instead of guessing.
- A place to try calls. A sandbox or test environment where mistakes do not touch live orders.
- Clear limits and errors. Published rate limits, and error messages that say what went wrong.
- A change policy. How the vendor announces changes, and how long old behaviour keeps working.
Webhooks or polling
An integration can learn that something changed in two ways. With webhooks, the ERP calls your integration when an event happens, such as an order being confirmed. With polling, your integration asks the ERP on a schedule, "what changed since last time?"
Webhooks react faster and make fewer calls. Polling is simpler to build and easier to recover: if the integration was down, it picks up where it left off on the next run. Plenty of integrations poll and work well. Ask which the vendor supports, and design for that.
Why access should not be a toll
An integration has real costs: a developer's time to build it, and someone's time to watch it and fix it when something changes. Those are fair. Paying the ERP vendor for permission to reach your own records is a different matter. Watch for:
- Per-integration or per-connector licence fees.
- Per-call charges that make a sensible sync schedule expensive.
- An API that is only available on the top tier.
- Read-only access, with every write going through a paid service.
- "Integration" that means the vendor's consultants build it and you cannot change it.
Each of these makes the vendor the gatekeeper of your data, and that matters most on the day you want to leave.
What an open API lets you do
- Feed a reporting or BI tool with orders and stock, so you can chart SKU velocity or fill rate without exporting spreadsheets by hand.
- Bring orders in from another channel, such as a partner's ordering site.
- Keep a pricing or catalogue tool in step with your item list and stock.
- Build a small internal tool for a job your ERP does not cover, without waiting for the vendor's roadmap.
The hidden benefit: you can leave
Switching ERPs is hard enough: data to move, people to retrain, reports to rebuild. A closed system adds custom integrations that only work with it. When your integrations talk to a documented API and your data can be pulled out on demand, switching costs less, and your vendor has to keep earning the renewal.
How to test a vendor's API before you sign
- Ask for the API documentation early. If it is neither public nor available on request, note that.
- Have a developer create a key with read-only access to orders, then fetch yesterday's orders.
- Try a write in the sandbox: create a customer, then an order for that customer.
- Revoke the key and confirm the next call is refused.
- Read the pricing for API access line by line, including anything charged per call or per connection.
If a developer can do all this without opening a support ticket, the API is real. If every step needs the vendor's help, integrations will cost you later. Add these steps to your list of questions for an ERP demo.
Keep your keys safe
- Use one key per integration, so you can revoke one without breaking the others.
- Give each key the least access it needs. A reporting tool needs read access, not delete.
- Store keys in the integration's settings or a secrets manager, never in email or a shared spreadsheet.
- Revoke keys when a contractor or employee who handled them leaves.
If you are deciding which systems to connect in the first place, see building a tech stack.
The APFoodz API
APFoodz has an open API, with keys you control.