Whenever two systems in a company are supposed to talk to each other — the merchandise management system with the accounting system, time recording with payroll, the order system with the warehouse — the word interface comes up quickly. For most managers it stays unclear what that actually means: a file, an add-on program, an agreement? To judge whether a project is feasible and affordable, you do not need programming knowledge. You need a picture of what a request looks like, what comes back, who identifies themselves along the way and where the limits are. This article explains APIs without prior knowledge, walks through the entries of an interface documentation and ends with the questions you can put to a system vendor without becoming technical yourself. Anyone able to judge afterwards whether a system can be connected at all is spared quotations for projects that fail on the vendor's technology. The corresponding services are described under interfaces.
Key takeaways
- An interface is neither a program nor a file but an agreement: which questions a system answers, how those questions have to be phrased and in what form the answer comes back.
- Every request goes through the same five steps (project experience): call the address, identify yourself, have permissions checked, receive a response with a status code and data, respect the call limits. Whoever can settle these five points can size a project.
- The data format is rarely the problem, permissions are: an account that may only read is fine for reporting but not for automatic postings — and an account with full rights does not belong in a connection that merely synchronises addresses.
- A system counts as connectable when there is publicly accessible documentation, a test environment, named versions with notice periods and a technical contact person. If two of these four are missing, effort and risk rise noticeably.
- If no interface exists at all, the remaining routes are scheduled file exchange, database access with the vendor's written consent, or replacing the system — screen imitation is the most expensive option because every change to the user interface stops it.
An interface is an agreed route for request and response
The term interface describes neither an add-on program nor a file, but an agreement between two systems: which questions one system may put to the other, in what form the question has to be phrased, and what comes back. An application programming interface — usually shortened to API — is exactly that agreement, written down in documentation and implemented in the vendor's system. When your vendor says the system has an interface, all they are saying at first is that there is an official route to reach certain data and functions from the outside. Which data and which functions is not yet settled by that statement.
A comparison from daily operations carries a long way: the interface is the counter of a warehouse. Whoever needs something steps up to the counter, identifies themselves, states the item number and either receives the goods or an explanation why not. Nobody walks into the warehouse themselves, nobody rearranges shelves on their own initiative. That is precisely the point: the other system keeps control over what may be handed out and what may be changed. The counter has opening hours, a queue and a catalogue of what it issues — all three limits have a direct technical equivalent and later determine what a connection can deliver.
From this follows the single most important rule for any feasibility question: a connection can only do what the counter hands out. If the interface of a sector-specific application delivers orders but not the line items belonging to them, no report by article can be built from it — no matter how much effort someone puts in. That is why a project does not start with the question of what should be built, but with what the systems involved actually release. This check belongs in the process analysis and not in the implementation phase.
Three terms that often get mixed up
What actually happens during a request
Every request to an interface follows the same pattern, whether it concerns a customer address or a stock movement. Once you have seen that pattern, you can hold your own in a meeting with the system vendor without doing any technical work yourself. The last step matters most: every request is answered with a status code, and that status code decides whether a connection quietly gets things wrong or makes an error visible.
Step 1: call the address
Every function of an interface has its own address, similar to a web address. One address delivers articles, another customers, a third accepts orders. These addresses are listed in the documentation and do not change without notice.
Step 2: state the intention
Each address comes with an intention: read, create, change or delete. Added to that are parameters such as a customer number or a date range. Only both together make a complete question.
Step 3: identify yourself
An access key travels with the request. The other system checks whether the key is valid and whether the account behind it is allowed to perform the requested action at all. Without a valid key the request ends here.
Step 4: take the response
Back comes a status code and usually a data package. Common codes mean: successful, not signed in, not permitted, not found, too many requests, error in the target system. Each of these requires its own reaction in the connection.
Step 5: process the result
Only now does the benefit appear: the record is taken over, a document is created, a key figure is updated. Faulty responses go into a follow-up list instead of disappearing unnoticed.
Every function of an interface has its own address, similar to a web address. One address delivers articles, another customers, a third accepts orders. These addresses are listed in the documentation and do not change without notice.
Each address comes with an intention: read, create, change or delete. Added to that are parameters such as a customer number or a date range. Only both together make a complete question.
An access key travels with the request. The other system checks whether the key is valid and whether the account behind it is allowed to perform the requested action at all. Without a valid key the request ends here.
Back comes a status code and usually a data package. Common codes mean: successful, not signed in, not permitted, not found, too many requests, error in the target system. Each of these requires its own reaction in the connection.
Only now does the benefit appear: the record is taken over, a document is created, a key figure is updated. Faulty responses go into a follow-up list instead of disappearing unnoticed.
In practice a request together with its response looks like the example below. You do not have to be able to write it — but it helps to have seen it once, because exactly these parts show up in quotations and documentation: address, intention, access key, requested format, status code and data package.
GET /api/v1/articles/4711 HTTP/1.1
Host: erp.internal.example
Authorization: Bearer ACCESS_KEY
Accept: application/json
--- Response ---
HTTP/1.1 200 OK
Content-Type: application/json
{
"article_number": "4711",
"description": "Pipe clamp 22 mm",
"stock": 148,
"location": "H-03-02",
"as_of": "2026-05-29T08:14:00+02:00"
}Two things about this example matter. First the timestamp: a response remains a snapshot, and the question of how old a value may be is a business decision, not a technical one. Second the number 200 in the response line — the status code for success. If 401 comes back instead, the identification is missing; with 403 the identification is valid but the permissions are insufficient; with 404 the record does not exist; with 429 too many requests were made; from 500 upwards the fault lies in the target system. These numbers are industry standard and will meet you again in every documentation.
Data formats: what the answer looks like and why that is rarely the problem
Only a few formats have established themselves for transferring data. The format shown above with curly brackets is called JSON and is the normal case today. Older systems and many sector standards use XML, which maps the same content with angle brackets and named tags and remains widespread in regulated areas. For bulk exchange — price lists, master data, posting batches — the plain text file with separators is still in use, commonly referred to as CSV.
The good news for planning: the format is almost never the reason a project fails. Converting between these formats is routine work. What genuinely creates effort are differences in meaning — when one system holds net prices and the other gross prices, when customer numbers are stored with a leading zero in one system and without it in the other, when dates are transferred without a time zone. These questions are settled at the table and not in program code; they belong to data integration and are the part that quotations regularly underestimate.
| Criterion | Interface with immediate answer | Scheduled file exchange |
|---|---|---|
| Timeliness | Answer within seconds | As current as the last run |
| Typical use | Stock, price, order status | Master data, posting batches, price lists |
| Volume per operation | Individual records | Large volumes at once |
| Error pattern | Faults visible immediately | Faults often noticed only the next day |
| Requirement at the vendor | Documented interface needed | Export and import function often enough |
| Setup effort | Higher, but more accurate in operation | Lower, but more manual follow-up |
Identification and permissions: who is asking, and what may be asked
Two questions are frequently mixed up here. The first is: who is making the request? That is identification. The second is: what is this requester allowed to do? Those are the permissions. Identification usually runs via an access key, a long string of characters issued by the other system. Larger systems use a procedure in which the key is valid for a limited time and renewed regularly — for your planning that simply means the renewal has to run automatically and must not depend on one individual.
Permissions are the point where projects actually fail. An account that may only read is fine for reporting and for reporting on key figures, but not for automatic postings. Conversely, an account with full rights does not belong in a connection whose only job is to synchronise addresses. Every connection should get its own technical account with exactly the permissions it needs — not the account of an employee. If that person leaves the company and their account is disabled, the data exchange stops overnight.
- A separate technical account per connection, named after its purpose rather than after a person
- Only the permissions genuinely required, in case of doubt read-only first and extended later
- Access keys stored separately from the application and never passed around in documents or messages — the German Federal Office for Information Security advises against keeping credentials in program code (BSI)
- A defined procedure for the case that a key becomes known: revoke, reissue, update the connection
- A log of which connection fetched or wrote which data and when — in a dispute the only reliable record
- Transfer exclusively encrypted, recognisable by an address starting with https
Call limits and what they mean in daily operation
No vendor allows an unlimited number of requests. An upper limit per minute, per hour or per day is common, technically known as a rate limit. Once it is exceeded, the system answers with status code 429 and often with an indication of how long to wait. For you this is not a technical footnote but a planning figure: it determines how many records can be transferred per hour and whether an initial full load of master data takes an hour or a weekend.
In practice this means a connection must not repeatedly fetch all data, only the changes since the last run. Almost every usable interface offers a filter by change date for this purpose. If that filter is missing, every query becomes a full transfer — irrelevant with five hundred articles and a knock-out criterion with eighty thousand. Ask about this point early; it changes the effort of a connection more than the data format does.
The limit belongs in the quotation
Versions: interfaces change, connections have to follow
An interface is not a finished component but a maintained one. Vendors add fields, change structures and switch off old releases. So that existing connections are not caught out, the interface is versioned: the address contains a marker such as v1 or v2, or the version travels with the request. As long as you address a fixed version, your connection stays stable even while the vendor offers a newer one in parallel.
What matters is therefore less whether versioning exists and more how shutdowns are handled. Reliable vendors announce the end of a version with a notice period, publish a change log and provide a migration guide. Where that is missing, you carry the risk: a connection that ran for years stops working on a Tuesday morning without warning. That is why notice period and change log belong in the contract documents rather than in a phone call.
Two questions about versions before any order
What an interface documentation contains
Interface documentation looks forbidding at first glance but follows one and the same structure. You do not have to understand all of it. It is enough to find six entries — if all six are present, a connection can be planned; if two of them are missing, implementation starts with queries to the manufacturer and becomes correspondingly more expensive.
Directory of addresses
A list of all callable functions stating what each one returns. Check here first whether the data you need is listed at all.
Sign-in procedure
How an access key is requested, how long it is valid and who may issue it. If all you find is a sales email address, expect waiting time.
Description of the fields
Which fields a response contains, what type they have and which entries are mandatory when writing. This is where you see whether your reporting is possible at all.
Errors and status codes
An overview of the replies and their meaning. If it is missing, every piece of error handling has to be discovered by trial and error — a frequently underestimated cost.
Limits and versions
Calls allowed per period, filter by change date, current version and the handling of shutdowns. These entries govern operation rather than setup.
Test environment and examples
A separate system with test data and complete example requests. Without a test environment development happens on live data, which is not acceptable in ongoing operations.
You can tick off these six points yourself without writing a line of code. Open the documentation and search for the terms endpoint or address, authentication, fields, error codes, limit, and sandbox or test access. Whatever you cannot find in twenty minutes will not turn up during implementation either. This quick check does not replace a technical assessment, but it filters out the cases that are laborious from the start.
How to tell whether a system can be connected at all
There is a wide gap between the claim that a system is open and an interface that is genuinely usable. Bitkom points out that missing links between existing systems are among the frequently named obstacles to digitisation in mid-size companies (Bitkom). The following signs can be recognised without any technical inspection and say more than the wording in a quotation.
- Good sign: the documentation is publicly available, without registration and without a sales call
- Good sign: there is a test environment with sample data that you may use before placing an order
- Good sign: the vendor names a technical contact, not just a sales address
- Good sign: versions are named and shutdowns are announced with a notice period
- Warning sign: the interface is only included in a higher contract tier and billed separately per connection
- Warning sign: there is only a data export at the push of a button but no route that can be automated
- Warning sign: the vendor insists that every connection be built by them, with no access for third parties
- Knock-out criterion in practice: there is no documentation, only an assurance that this will be clarified during the project
The last point deserves emphasis. An assurance without documentation shifts the clarification into the implementation phase, meaning into the period where every hour is billed. If a system change is due anyway, connectability is a selection criterion like price and functionality — and one of the reasons why replacing legacy systems often works out cheaper than trying to open up a closed system after the fact.
An interface is not a file handed over once, but an agreement that has to be maintained in day-to-day operation.
The questions to put to your system vendor
You can take the following questions word for word. They are phrased so that the answers remain usable for non-technical readers, and they cover exactly the points that later decide effort and feasibility. Written answers are preferable to spoken ones — not out of distrust, but because sales and technical staff frequently answer the same question differently.
- Is there a documented application programming interface, and can the documentation be seen before signing a contract?
- Which data and functions are reachable through it, and which are explicitly not?
- Is access read-only, write-enabled or both, and can permissions be restricted per account?
- How is a technical account set up, how long does that take, and does it cost extra?
- How many requests are permitted per minute or per day, and what happens when that is exceeded?
- Is there a filter by change date so that not all data has to be transferred on every run?
- Which version is current, and with what notice period are old versions switched off?
- Is there a test environment with sample data that we may use before placing an order?
- Who is the technical contact, and within what time are queries answered?
- Is use of the interface included in the existing contract or tied to a different package?
The answers make it almost self-evident whether a connection is a manageable piece of work or a project with an open end. Two answers weigh particularly heavily: the permissions and the change filter. Whoever may only read can report but cannot relieve anyone of work. Whoever has to transfer everything on every run pays permanently for data volumes nobody needs.
When there is no interface: the alternative routes
Not every system in a mid-size company has a usable interface, older sector-specific applications in particular. That does not end the project but it changes the route. The simplest alternative is scheduled file exchange: the system drops an export at fixed intervals, a second program collects the file, checks it and passes the data on. That is inelegant but robust — and for master data, price lists or posting batches frequently quite sufficient.
The second route is read-only access to the system database, explicitly with the manufacturer's consent. Without that consent it is inadvisable: such access can affect warranty claims, and a system update can change the data structure without warning. The third route — imitating screen input, meaning a program that operates a user interface the way a person would — is the most expensive. It works until the manufacturer moves a field. As a transitional solution with a limited runtime it has its place, as a permanent solution rarely.
Whichever route is chosen, the same requirement applies: every exchange needs logging, a follow-up list for faults and a named person in charge. A data exchange that belongs to nobody eventually fails and is noticed only when a report stops adding up. We cover these operational questions under process automation — they determine the benefit more than the choice of technology does. Legal questions, for instance on retention and data processing agreements, should be assessed professionally in each individual case; electronic invoicing between businesses in Germany has been tied to receiving obligations since 2025 (German Value Added Tax Act) and is a frequent reason for connecting systems seriously for the first time.
Related Articles
When You Need Middleware — and When You Do Not
Middleware brokers between systems that cannot talk to each other directly. When a direct connection is enough and when the extra layer starts to pay off.
Invoice checks automated: order, goods receipt, invoice
Matching order, goods receipt and invoice by machine: which fields are compared, where the tolerance band sits, who owns the exception and what stays manual.
Choosing Business Software: Requirements Come First
How to decide before you buy: measure the volume baseline, write a lean requirements document in a week, score vendors by weight and check the contract terms.