English
Romana
An agency that builds auto parts stores for several clients, or a group operating multiple retail brands, quickly hits the same question: does it make sense to pay for a separate TecDoc license for every store, or can all catalogs be managed from a single, shared integration? The short answer is that a multi-tenant architecture on top of TecDoc is technically possible, but it requires strict data isolation rules between stores and, just as importantly, must be confirmed explicitly at contract level with the license provider.
The difference from a regular TecDoc store isn't in the technical catalog itself — vehicles, parts and fitment data stay the same for every client — it's in the application layer that decides who sees what, at what price, under which brand. This article explains the recommended architecture, where the most frequent data-isolation mistakes happen, and what needs to be clarified with TecAlliance before launching several stores on the same license.
What "multi-tenant" means for a TecDoc catalog
Multi-tenant is an architecture model in which a single software installation serves multiple clients (tenants), each with logically separate data, even though the technical infrastructure is shared. Applied to TecDoc, this means:
- A single API/WSDL connection to the TecDoc catalog, used by every hosted store.
- Multiple stores (tenants) — each with its own domain, brand and, typically, its own pricing and stock catalog.
- Shared technical data — vehicles, KTYPE, article codes and fitment data are identical for all tenants, since they come from the same TecDoc catalog.
- Separate commercial data — price, stock, active suppliers and margin differ from one store to another, even when the identified TecDoc part is the same.
In practice, TecDoc remains a single shared "technical brain," while each store keeps its own business layer on top of it — much like a B2B platform, where the technical catalog is shared but price and stock vary per account.
Who a multi-tenant model on top of TecDoc fits
This model isn't for every auto parts store — it makes sense in specific situations:
- Software agencies that build and host TecDoc stores for multiple distributor clients, each with its own brand.
- Groups operating several retail brands that run separate stores for different market segments (e.g. premium vs. economy parts), but share the same technical infrastructure.
- Distributors with multiple markets/countries that run separate localized stores while querying the same TecDoc catalog for technical data.
It doesn't make sense for a single store with a single end client — a standard, simpler TecDoc integration is sufficient and easier to maintain there.
Recommended architecture: a clear split between the technical catalog and commercial data
The structure that works well in practice relies on two distinct layers with a clear technical boundary between them:
- Shared technical layer — a single internal service (or module) that talks to the TecDoc API, caches frequent results, and exposes them uniformly to all hosted stores.
- Tenant layer — each store has its own database (or its own set of tables, with `tenant_id` on every row) for price, stock, suppliers, orders and customer accounts.
- Tenant identification layer — on every request, the platform determines which store is making the call, based on domain or subdomain, before querying the commercial layer.
- Result merging — the final response combines the technical data from TecDoc with the price and stock specific to the identified tenant, the same way a B2B integration for repair shops works.
This separation is what distinguishes a solid multi-tenant architecture from an improvised one, where one store's pricing logic or supplier catalog ends up accidentally mixed with another's.
Database: a single shared schema or separate databases per tenant?
The choice depends on the number of hosted stores and how strict the isolation needs to be:
| Model | How it works | When it's recommended |
|---|---|---|
| Single schema with `tenant_id` | All stores share the same tables; every row has a mandatory `tenant_id` column, automatically filtered on every query | Many small-to-medium stores, where operational simplicity matters more than physical isolation |
| Separate databases per tenant | Each store has its own database; the application switches connections based on the identified tenant | Few large stores, with strict isolation requirements (e.g. separate contracts, compliance, independent backups) |
| Hybrid model | TecDoc technical catalog and its cache in the shared schema; sensitive commercial data (price, orders, customers) in separate per-tenant databases | Groups with multiple brands, where technical data can be shared but commercial data must be strictly separated |
The single schema with `tenant_id` model is the most common choice for agencies hosting several small stores, since it simplifies code updates and maintenance. Its main risk is human: a query that omits the `tenant_id` filter exposes data across stores — which is why this filter needs to be applied at the data-access layer (a global query scope), not manually in every controller.
Caching the technical catalog: shared across tenants, but mind the localization
Since TecDoc's technical data (vehicles, fitment, article codes) is identical for every tenant, the cache for this data can and should be shared — querying the same API repeatedly for every store, for the same data, wastes request quota and slows the platform down. A few practical rules:
- Cache TecDoc's technical responses (vehicle identification, list of compatible parts) at a global level, not per tenant.
- Keep only what genuinely differs separate, per tenant: display language, currency, price and availability.
- If tenants operate in different markets/languages, check whether TecDoc naming needs additional per-store localization on top of the shared technical cache.
- Invalidate the technical cache on TecDoc catalog updates, not on every individual store's deployment — the two cycles are independent.
Common risks in a multi-tenant TecDoc catalog and how to avoid them
The most costly problems in multi-tenant architectures aren't performance issues — they're data isolation failures:
- Commercial data leaking between stores — a price or stock value calculated for the wrong tenant, due to a missing `tenant_id` filter. Mitigation: apply tenant filtering at a central data-access layer, not ad hoc throughout the codebase.
- Incorrectly shared TecDoc configuration — if one store has access to brands or categories it shouldn't sell (e.g. an exclusivity agreement with a supplier), that restriction must be applied explicitly in the commercial layer, not assumed from the catalog itself.
- API quota/license overload — several active stores at once can generate far more queries than a single store, pushing closer to the license's contractual limits. Mitigation: aggressive caching on the shared technical data, as described above.
- Brand mix-ups in displayed data — if templates or internal naming stay hardcoded for a single store, a new tenant can accidentally display another brand's visual elements or copy.
- Mixed billing and reporting — without a clear per-tenant split of orders and revenue, financial reconciliation for each store becomes cumbersome. Mitigation: mandatory `tenant_id` on order and billing tables too, not just the catalog.
What to clarify with TecAlliance before launching multiple stores on one license
The contractual side matters just as much as the technical one. TecDoc licensing terms can vary based on the number of stores, end-user volume, and the type of data exposure (public vs. authenticated), according to publicly available information on TecAlliance's website. A few points to verify explicitly, as general guidance, before launching a multi-tenant model:
- Whether the license covers exposing the catalog to multiple distinct stores/brands, or is designed for a single point of sale.
- Whether there are API query volume limits that could be reached faster with several active stores.
- Whether a "white label" model is allowed — hosting the TecDoc catalog for third-party clients under brands other than the integrator's own.
- Whether usage reporting needs to be done in aggregate or separately for each hosted store.
These points depend on the specific contractual terms of each license and cannot be assumed — verify them directly with TecAlliance or the license representative before launching a second store on the same integration.
Practical plan: steps to build a multi-tenant TecDoc catalog
Recommended order for an agency or group starting from a single TecDoc integration and looking to extend it to multiple stores:
- Confirm license terms for hosting multiple stores, as described above.
- Explicitly separate the technical layer from the commercial layer in the existing code, if the current integration has them mixed together.
- Choose the database model (single schema with `tenant_id`, separate databases, or hybrid), based on the number and size of the planned stores.
- Implement automatic tenant identification from the domain/subdomain, at the start of every request.
- Apply tenant filtering centrally (global query scope), not manually in every controller or function.
- Set up the shared TecDoc technical cache, separate from per-tenant commercial data.
- Test data isolation with at least two test stores, explicitly verifying that one store's price, stock and orders never appear on the other.
- Launch a real second store only after isolation tests pass consistently, not just in the happy-path cases.
Multi-tenant vs. separate integrations per store: when each option is worth it
Not every group of stores should be forced into a multi-tenant architecture. A direct comparison helps with the decision:
| Criterion | Multi-tenant (single integration) | Separate integrations per store |
|---|---|---|
| Maintenance cost | Lower — one codebase, updated once for all stores | Higher — each integration is updated and tested separately |
| Data isolation | Requires strict technical discipline (tenant filtering everywhere) | Natural isolation, each store has its own fully separate environment |
| Speed of launching a new store | Fast, once the architecture is in place | Slower — each new store repeats the integration from scratch |
| Best fit | Agencies, groups with many technically similar brands | Clients with very different business logic or compliance requirements |
Frequently asked questions about TecDoc multi-tenant
Can a single TecDoc license technically serve multiple stores at once?
Technically, yes — the TecDoc API can be queried from a single integration and the results redistributed to multiple stores. Whether this is also contractually permitted depends on the specific license terms, which must be confirmed directly with TecAlliance or the license provider.
Do you need separate databases for each store?
Not necessarily. A single schema with a `tenant_id` column on every relevant table works well for many small-to-medium stores, as long as tenant filtering is applied consistently at a central level. Fully separate databases are justified for large stores or ones with strict isolation requirements.
How do you avoid one store's price accidentally showing up on another?
By applying the tenant filter at the central data-access layer (e.g. a global query scope in the framework), not manually in every place in the code where price is read or written. Isolation tests, using accounts from different tenants, must be run explicitly before every major release.
Can you do a "white label" model with TecDoc, for third-party clients?
It depends on the terms of the TecDoc license held. Hosting the catalog under brands other than the main integrator's (white label) isn't implicitly allowed by every license type — verify this scenario explicitly with TecAlliance before offering it as a service to clients.
What happens to API query volume as you add more stores?
Volume grows proportionally with the number of active stores, if each one queries the technical catalog separately. A shared technical cache across tenants (see the dedicated section above) significantly reduces this volume, since vehicle and fitment data is identical for all tenants and doesn't need to be requested more than once.
Conclusion
A multi-tenant TecDoc catalog is an efficient solution for agencies and groups operating multiple auto stores, but it depends on a disciplined separation between the shared technical layer (the TecDoc catalog itself) and the commercial layer isolated per store (price, stock, orders, customers). Success comes not from choosing a particular technology, but from rigorously testing data isolation between tenants and from explicitly confirming with TecAlliance that the held license covers this usage model.
Are you building or extending a platform that hosts multiple auto parts stores on the same TecDoc integration? Contact us for a consultation on the multi-tenant architecture that fits your situation.
Write a comment