An API is nothing more than an agreed way for two programs to talk to each other. Instead of a member of staff typing a VIN into a form, reading the result and transferring it into the ERP system, the ERP system asks for itself and writes the answer into its own fields.
What actually changes
| Task | Without an API | With an API |
|---|---|---|
| Create a vehicle | Type the VIN, read the result, transfer fields | Scan the VIN, fields are filled |
| Capture a part | Search the number, pick an article type, estimate dimensions | Number from the image, article type and attributes from the cross-check |
| Publish a listing | Re-enter per channel | One record, several channels |
| Source of error | Every manual transfer | No manual transfer |
The benefit lies less in the minute saved than in the errors avoided. One mis-typed digit in a part number produces a return, and a return costs a multiple of the time saved.
From when it pays
An honest answer: not immediately. As long as a yard takes in few vehicles a month and capture happens on the side, the web interface is the faster route. The tipping point is where the same hand movement becomes routine — usually when several transactions occur per day, or when a second sales channel is added and data would otherwise be maintained twice.
What a call looks like
Technically it is an ordinary HTTP call with a key in the request header. One example from the documentation:
curl \ -H 'X-Api-Key: <API_KEY>' \ 'https://api.tapinomahub.com/parts/oe/5Q0919275C'
The response is structured and machine-readable. Any software that speaks HTTP — and they all do — can process it. The full description of the endpoints is in the documentation, linked from the API page. Which calls apply in which software category — ERP, DMS, fleet, workshop, marketplace — is described on the integration pages.
How a connection project usually runs
- Create an account and generate a key. The key belongs in your software's configuration, not in source code and not in a file that gets shared by accident.
- Pick one transaction. Do not connect everything at once. Vehicle import via the VIN is almost always the most rewarding first step.
- Define the field mapping. Which response fields land in which fields of your system? That mapping is the actual work, not the call.
- Test with a handful of vehicles. Including the edge cases: no result, half a result, invalid number.
- Define the failure case. What happens when no answer arrives? A sensible rule: create the record, leave the field empty, raise a follow-up task — never an estimated value.
- Roll out and observe. After two weeks the credit journal shows which transactions run how often.
What to watch out for
- Do not fill empty fields. Where a source returns nothing, an empty field belongs in the record and a task in the list — no default and no estimate. A plausible value in stock is more dangerous than a visible gap.
- Think about idempotency. Running an import twice must not create a second vehicle. The VIN is the natural key for that.
- Do not query on every page view. Results belong in your database; every request costs.
- Protect the key. A key in a file on a network share is no longer a key.
- Make provenance visible. If the record shows which field came from a lookup and which someone typed, later discrepancies are explainable.
Frequently asked
Do I need a developer?
Not necessarily. Many ERP systems can be connected by their vendor. For in-house work, basic HTTP knowledge is enough.
Does using the API cost more?
No. They are the same requests at the same rates, just made by a different program.
What happens if the API does not answer?
Your system should still create the record, leave the field empty and raise a follow-up. A default value would be worse than a gap.
Can I start with the web interface?
Yes, and that is usually the right way. Connecting pays only once the same hand movement occurs several times a day.