Multi-Tenancy

Every Vantemo shop is a tenant — an isolated data silo that shares the same infrastructure but never leaks data to other shops. This page explains how tenant isolation works from a developer's perspective.

How It Works

When you make an API request, Vantemo resolves your tenant (shop) through one of two mechanisms:

1. API Key — Your key is linked to a specific shop. All queries are automatically scoped to that shop's data.
2. Domain Header — Storefront requests resolve the shop by the Host header or subdomain (e.g., your-shop.vantemo.com).

Once the tenant is resolved, a tenant context is created for the request. Every database query within that request is automatically filtered by shop_id — you never need to manually add WHERE shop_id = ? clauses.

What This Means for You

You Only See Your Data

Every API response contains only data belonging to your shop. There's no way to access another shop's products, orders, customers, or settings through the API.

Cross-Tenant Operations Are Impossible

Even if you know another shop's product ID, you cannot read, update, or delete it. The tenant isolation layer rejects the query before it reaches the database.

Session vs API Key Authentication

Data Model Scope

Most resources in Vantemo are tenant-scoped — they belong to a specific shop:

• Products, variants, and images
• Orders and line items
• Customers and addresses
• Carts and checkout sessions
• Coupons and discounts
• Blog posts and pages
• Webhooks and API keys
• Settings and configurations

A small number of resources are global (cross-tenant):

• Organization and billing
• User accounts (can access multiple shops)
• Platform-wide configurations

Best Practices

1. One API key per integration. Don't share keys across different services or environments. Create separate keys for development, staging, and production.
2. Use publishable keys for storefronts. They're read-only and safe to expose in browser code.
3. Test with test-mode keys. Keys with _test_ in the prefix don't affect live data.