ERP and inventory systems: creating articles, checking fitment, billing per end customer

Where data is missing in the process

An article master in the parts trade is rarely created in one go. It grows out of delivery notes, labels, catalogue searches and calls from the warehouse — and at each of these points something is typed, estimated or left open today:

• Creating an article from a number. The OE number arrives from the label, the delivery note or a photo in several spellings. Whether 5Q0 919 275 C and 5Q0919275C are the same article is decided by the clerk today — see OE number: reading original part numbers correctly.
• Name, manufacturer and article type. The article is called „sensor“ because the field had to be filled. A documented name, an article type and the replacement chain are missing.
• Pricing. The selling price of a used part is set from memory because the system holds no basis for comparison.
• Fitment in the order. A customer orders five items for one vehicle, and whether they fit is settled at installation — or in the return.
• Labels at goods receipt. Supplier number, OE number and references are printed on the label and copied into the form by hand, see Part identification: from removed component to sellable record.

What the API delivers

One process from start to finish

1. Goods receipt: photograph the label. The ERP sends the image to POST /scanner/label/extract-partnumbers and receives part and reference numbers. What cannot be read on the image is not returned — the analysis is billed nonetheless, because it was performed.
2. Clean up the number. GET /parts/oe/normalize brings the number read into its comparison form; ambiguous and invalid go to a clarification list instead of the article master.
3. Create the article. GET /parts/oe/{oeNumber} returns 200 for a confirmed match, with name, manufacturer, article type and replacement chain; 404 means no match in the OE stock, not an error.
4. Propose a price. GET /parts/oe/{oeNumber}/price gives an indicative evaluation that the clerk sees and confirms. It does not replace the pricing decision.
5. Check the order. Before confirming the order, the ERP sends the VIN and the OE items to POST /vin/cart-check, with mode=type for the vehicle type or mode=vehicle for the specific vehicle.
6. Publish. For multilingual marketplaces and documents, GET /translation/translations translates the name; the article goes into stock and sales with documented fields, see Storage in a dismantling yard: the location that finds the part again.

curl \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "<CUSTOMER_NAME>",
    "externalReference": "erp-customer-4711",
    "endpointKeys": ["parts.oe", "vin.cart_check"],
    "sponsorship": true
  }' \
  'https://api.tapinomahub.com/client/partner-workspaces'

The integration

1. Store the key server-side. The X-Api-Key belongs in your backend configuration. It must never reach a browser or a client bundle — not even „just for testing“.
2. Start with one endpoint. For an ERP that is almost always GET /parts/oe/{oeNumber} behind article creation. The sequence contract, key, process, go-live is described in the integration guide.
3. Define the field mapping. Name, manufacturer, article type and replacement chain have fixed targets in the master; the tapiGenArt gets a field of its own so that filters and marketplaces can use it, see GenArt number: what kind of part is this, actually?.
4. Separate empty result from error. 404 on the OE lookup is a business result: no confirmed match. The ERP creates the article, leaves the fields empty and raises a clarification task. Only a technical error is retried.
5. Collect asynchronous answers. Cart checks may answer with 202, Location and Retry-After. The ERP stores the job ID and polls GET /vin/cart-check/jobs/{jobId} instead of repeating the call.
6. Roll out. First with one end customer, then broadly. GET /client/usage and, per workspace, GET /client/users/{clientId}/usage show which calls run how often.

What to watch out for

• Set an `Idempotency-Key`. On repeatable calls such as the cart check, the header protects against double bookings after a timeout; X-Tapinoma-Idempotent-Replay flags the replay. Exception: POST /client/partner-workspaces issues a secret key once and is not replayed — after a timeout, reconcile what exists instead of blindly repeating.
• Do not fill empty fields. If manufacturer, name or listPrice comes back as null, the master data field stays empty and the article gets a clarification task. A default value in the article master is more dangerous than a visible gap.
• Store the `tapiId`. Where a vehicle was matched through a VIN flow, the tapiId belongs in the vehicle record; GET /vehicles/{tapiId} returns the technical data as part of that paid workflow, without VIN and without equipment.
• Never put the key in the browser. A web-based ERP also calls the API from the backend; the browser talks only to your server.
• Set rate limits per workspace. PUT /client/users/{clientId}/rate-limits limits per user, key or endpoint so that a faulty import at one end customer does not use up everyone else's quota.
• Have the result checked. Price evaluation and fitment statements are the basis for a decision in the ERP, not the decision. The clerk confirms, the system records where a value came from.

What the API does not do

The API does not sell a data set: what is owed is the lookup and the output of its result; checking before use lies with the customer. The price evaluation is indicative and no price guarantee. Vehicle data from provider 1 must not be retrieved directly by third-party systems: there GET /vin/{vin}/vehicle answers redirect_required, and the match runs through a browser session from POST /vin/redirect-sessions that expires after ten minutes; providers 2 and 3 can be queried directly. A keeper lookup, an expert appraisal or a residual value calculation is not something the API provides. And where a field is not documented, it stays null — the API does not guess, and neither should your ERP.