Claim a subdomain, not a codebase
A storefront starts as a subdomain request, reviewed once and then live, with pause and resume left entirely separate from that approval, so a seasonal business can go quiet without losing its slot.
Storefronts
Your own booking site. Built around a map, not a template.
Claim a subdomain, pick a branding level, drop in your products, and a real map does the introducing. No developer between the idea and the URL, and no separate deploy per customer.
- 4 branding levels From fully Tiqory-branded to completely white-label, chosen per storefront, not baked into the platform
- 1 pin per product The map API is shaped so a card always resolves to exactly one location, never an ambiguous cluster
- One deployment, every tenant Every organization is resolved from its own subdomain at request time, so a new storefront ships with zero new infrastructure
Four pieces of a storefront going live.
Each one solves a different part of turning a catalog into a site someone can actually visit.
Branding as loud or as quiet as you want
Full Tiqory branding, a quiet "by Tiqory" badge, a completely independent brand, or no branding at all for a reseller building on top: the same storefront engine serves all four without a special build for any of them.
A map that already knows your locations
Every product with a venue gets a pin the moment it is published, with a popup a guest can tap straight into directions, no separate geocoding step for the team to remember.
Content blocks, not a page builder to learn
A markdown block, an image, a couple of calls to action: reordered by dragging, reused across products, with one block set as the home page. Nobody is opening a website builder to change a paragraph.
How it resolves
How a visit turns into a booking
Five steps, from a browser hitting the subdomain to a guest holding a ticket.
- 1
The subdomain resolves to an organization
Every request is matched to its storefront by host at the moment it arrives, so one deployment serves every tenant without a separate build or release per customer.
- 2
Branding and content load as one config
Colors, logos, enabled languages and currencies, and every content block arrive in a single response, so the page never assembles itself out of a dozen separate calls.
- 3
The map places every product at once
Locations resolve into deduplicated pins in the same pass, so a guest sees the whole catalog on the map before choosing anything, not one pin loaded at a time.
- 4
A product page never leaves for checkout
Availability, pricing categories and buyer questions all come from the same product response, so choosing a date does not trigger a new page load to ask the next question.
- 5
The order becomes a ticket
Checkout confirms against the same inventory and pricing engine every other channel uses, so a storefront sale is never a second, looser code path from the one the dashboard relies on.
The API, as it is
What a storefront actually returns
Branding, enabled locales and currencies, and the map-ready location on every product, all public, all cached, and all scoped to one subdomain.
GET /api/v1/storefronts/roma-tours
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
{
"data": {
"subdomain": "roma-tours",
"branding": {
"type": "custom"
},
"default_locale": "it",
"enabled_locales": [
"it",
"en"
],
"default_currency": "EUR",
"products": [
{
"name": "Colosseum Underground Tour",
"location": {
"name": "Colosseum",
"latitude": 41.8902,
"longitude": 12.4922
}
}
]
}
}200 Storefront ready
The detail almost nobody explains
A product card only ever gets one pin
A product can genuinely offer more than one location, but the storefront API deliberately narrows a catalog card to a single location object, not an array. That one choice is what lets the map render one clean pin per card instead of a guessing game about which of several coordinates a card actually represents.
Frequently asked questions
No. A subdomain gets claimed and reviewed once from the back office, and everything after that (branding, content, products) is configured the same way, without a deploy of any kind.
Yes, the brandless mode removes Tiqory's own branding completely, which is exactly what a reseller building its own layer on top needs.
It simply carries no pin. The map only ever plots what a product actually has, never a placeholder location invented to fill the gap.
Yes. Pausing is a separate switch from approval, so a seasonal storefront can go quiet for the off-season and come back on the exact same subdomain, no new review required.
No. Each storefront enables only the languages and currencies it actually has content for, so a guest is never dropped into a page that quietly falls back to English.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.