Catalog by car make — now by VIN

Vindec is an API that turns a VIN into a vehicle ID inside the FAPI catalog by car make. The catalog opens directly on the correct modification, with no manual «brand → model → modification» picker in the storefront.
What’s inside
- 17-character VIN in, JSON out.
- The response includes the manufacturer, modification (engine + year + body), power (kW), displacement (cc), fuel type, body style, drivetrain, transmission, plus model and modification IDs that drop you straight into the catalog.
- Confidence level in every response:
exact/partial/brand_only/unknown. If we’re not sure, we say so. - Catalog reference data stored locally — vehicle models and types live on our side, no per-request lookups over the network.
Example response
Request: GET /v1/decode?vin=WVWZZZ1JZXW000010
{
"confidence": "exact",
"vin": "WVWZZZ1JZXW000010",
"manufacturer": "Volkswagen",
"model": "Golf IV",
"modification": "1.6 (AKL, AEH)",
"year_from": 1997,
"year_to": 2006,
"body_type": "Hatchback",
"engine_kw": 74,
"engine_cc": 1595,
"fuel": "petrol",
"drive": "FWD",
"gearbox": "MT",
"catalog": {
"model_id": "20210",
"type_id": "1041"
}
}
WMI/VDS/VIS breakdown per ISO 3779 happens inside Vindec; the consumer gets a ready modification plus a pair of IDs to drop straight into the FAPI catalog by car make. When the VIN decodes only partially (e.g. WMI is unambiguous but the modification is not), confidence returns brand_only or partial — that’s a signal to the UI: show a manual modification picker, don’t guess.
Who it’s for
The service is built for clients of the FAPI catalog by car make.
- You already have the catalog — Vindec plugs into your storefront or 1C-frontend as another entry point: instead of picking brand/model by hand, the client types in a VIN.
- You’re evaluating the catalog — Vindec only makes sense alongside it, so start with the catalog itself.
- No FAPI catalog by car make — not useful yet: Vindec returns a catalog ID, and you need somewhere to query it.
Where it plugs in
Three typical scenarios — each has its own UI, but the common part is the same: instead of «brand → model → modification» entered by hand, the client or specialist passes a VIN and the catalog opens on the correct row.
Auto parts store front. A «VIN» field next to the usual brand picker. The client copies 17 characters from the registration document or the windshield — the catalog jumps straight to the right engine and generation. When decoding is partial (partial / brand_only), the storefront shows what matched and keeps the manual path open for the rest. On covered cars — zero «wrong modification» errors.
Parts specialist front-of-house (1C-based). The partseller picks up a call: «Skoda Octavia 2011, need brake pads.» Follow-up: «Can you read me the VIN?» — and a second later the screen is on the correct modification, no manual A5 vs A7, pre- vs post-facelift, 1.6 MPI vs 1.4 TSI. The scenario gets 3-5× faster; wrong-part errors are filtered at the input stage.
Mobile intake at a service station. The intake clerk scans the VIN barcode under the hood with a phone, gets the modification and immediately sees the maintenance items (oil, filters, belts) in the FAPI catalog by car make. Works offline in the car cabin: the catalog reference data lives locally, only the Vindec call goes over the network.
Why an API, not a manual picker
- Speed. A partseller spends seconds instead of minutes navigating brand → model → modification → engine. On a call queue, this is dozens of hours saved per month.
- Modification accuracy. A VIN uniquely encodes the engine, year of make and trim. Manual picking relies on the client’s memory («mine is 2014… I think 1.6…») — the road to wrong articles and returns.
- Onboarding floor. A less-experienced seller without years on a specific make still makes correct picks: the VIN decoder handles what a seasoned specialist holds in their head.
- Audit traceability. The order keeps the original VIN — a disputed return is settled by fact, not by «he told me, I picked it.»
Status: closed beta
Since 2026-05-16, early access is open to existing catalog customers. Beta means:
- Capacity is limited; access rolls out in batches.
- Pilot pricing is negotiated individually with participants and fixed for the contract term.
- Feedback from early users goes straight into the roadmap.
Join the waitlist
- Email:
fapi@iisis.ru, subjectVindec beta. In the body — company name, whether you already have the catalog, expected VIN query volume. - Telegram updates channel: @database_auto_parts — announcements of new access batches.
Technical
- REST API, JSON.
- Service written in Go; storage in PostgreSQL plus read-only reference data from the FAPI catalog by car make (MariaDB).
- Deployment: managed by us or self-hosted on your side (discussed with beta participants).
- Documentation and Swagger spec handed out after access is granted.
FAQ
Which makes are supported?
The API works for all makes and models present in our FAPI catalog by car make.
What about rate limits during beta?
Negotiated individually. If your use case is embedding Vindec into a storefront with thousands of requests per day, mention it at sign-up so we can plan capacity accordingly.
Is this a replacement for the catalog?
No. Vindec doesn’t ship parts and doesn’t build the make/model hierarchy. It returns a vehicle ID — an entry point into the FAPI catalog by car make that you already have.
When will it go GA?
After beta closes. We don’t announce dates so we don’t split attention between «promises» and work with early customers.
What if a VIN doesn’t fully decode?
Vindec returns confidence: partial or brand_only and fills in the fields it could establish (e.g. only the manufacturer from WMI). That’s an explicit signal to your UI: show a manual modification picker, don’t substitute article numbers blindly. Vindec doesn’t return guesses — we don’t fabricate what isn’t encoded.
What about JDM cars without VIN and early Soviet-era VAZ?
JDM cars with a body number in the XXX-1234567 format and early Soviet/early VAZ numbers are not described by ISO 3779 — Vindec returns confidence: unknown for them, and the flow must fall back to manual entry. On the RU market this is a noticeable share; it’s important for the UI not to crash on these cases but to degrade gracefully to the old path.
What’s the response latency?
Tens of milliseconds for decoding plus one local lookup against the MariaDB reference data. No external APIs in the hot path — everything is readonly-local. That makes Vindec safe to embed straight into input-onChange of a web form without a user-perceived lag.
What about VIN privacy?
A VIN by itself is not personal data — it identifies the vehicle, not the owner. But we don’t store the raw VINs from your requests: only aggregate usage stats (request counts, confidence distribution, common WMIs). If you have a compliance task — that gets written separately into the contract.
Is self-hosted supported?
Discussed with beta participants. Architecturally Vindec is a single Go binary + PostgreSQL + a readonly replica of the FAPI catalog reference data; deploys in Docker within an hour. If you have on-prem requirements (banks, public sector) — that’s a supported path.