My Website: widgets on your own site
The My Website section is for those who already have a site. There's nothing to migrate to our storefront: you paste one line of code into your existing site, and after that you switch the products you need on with toggles in the admin panel.
Where to find it: Admin panel → Marketing → "My Website" (admin.masamenu.tr).
It works on any platform where you can paste a <script>: WordPress, Tilda, Wix, Shopify, Webflow, Bitrix, InSales, OpenCart, a custom-built site, or a landing page builder.
Site address and install code#
The “🌐 Your site” block at the top of the section walks you through three steps — address → code on the site → check — and the main button always offers the next unfinished step. The first is your site address (for example, example.com): we use it to check the installation and to build the correct links inside the widgets.
The second is the install code — a single line:
<script src="https://cdn.masamenu.tr/site/v1.js" data-domain="YOUR-DOMAIN" async></script>
Paste it once — into <head> or right before </body>. You won't need to touch the site's code again: which widgets run is set by toggles in the admin panel, not by tags on the page. Turn a widget on, and it appears on the site within a few minutes; turn it off, and it disappears.
If you previously pasted individual widget tags by hand, they'll keep working: the single loader sees them and won't start the same widget a second time.
Installation on Popular Platforms#
In the "Installation Code" window there is a tab for each platform — with the same steps as below.
Every platform here has its own anchor, so you can send the link to whoever edits the site instead of retelling the steps: #html, #google-tag-manager, #wordpress, #tilda, #wix, #shopify, #webflow, #squarespace — for example, /en/docs/site-widgets#tilda.
What is true on every platform, so we don't repeat it in each block:
- the tag goes in once for the whole site — into the shared template, not into a single page;
- on website builders (Tilda, Wix, Webflow, Squarespace) the change stays in the editor until the site is published again;
- check the live site, not the editor preview;
- if a cache or a CDN sits in front of the site, purge it: both the visitor and our check may be served a stored copy of the page without the tag;
- what the installation check will not see anyway — a separate breakdown below.
HTML#
Any site whose template you can edit: hand-written, a landing page, a static site generator.
- Copy the code line: Marketing → "My website".
- Paste it into
<head>or before</body>of the site's shared template. - No shared template (pages are separate files) — paste it into every page.
- Upload the change, open the site and press "Check installation".
Google Tag Manager#
The way to go when you have no access to the template but GTM is already on the site.
- Tags → New → type "Custom HTML".
- Paste the code line, trigger — "All Pages", save.
- Press "Publish": until the container version is published, the live site has no tag.
⚠️ A tag raised from GTM will never be detected by our "Check installation" — that is not a bug but a consequence of the method: “What the installation check does not see”. Open the site and look with your own eyes.
WordPress#
- The WordPress dashboard (
your-site/wp-admin); administrator rights are required. - The reliable way: Plugins → Add → any plugin that inserts code into the header/footer → paste the line into its Header field → save.
- Without a plugin: Appearance → Theme File Editor →
header.php(before the closing</head>) orfooter.php(before</body>) → "Update File". - Open the site and press "Check installation".
⚠️ Edits to the parent theme's files are lost when the theme is updated — the WordPress documentation warns about this too. A code-insertion plugin or a child theme survives updates. If a caching plugin is installed (W3 Total Cache, WP Rocket and the like), purge the cache, otherwise the check will see an old copy of the page.
💡 You don't need a separate widget plugin: one tag brings all widgets in. The Cenaly Consent plugin is a different story — it installs the cookie-banner tag only (see Cookies and consent).
Tilda#
- In the project list open "Site Settings" of the right site (project settings, not page settings).
- Section "More" (in some accounts it is labelled "Code Injection") → the field "HTML code for the head section".
- Paste the line and save.
- Republish all pages of the project — otherwise the code stays in the editor only.
- Open the live site and press "Check installation".
💡 If you need the tag on a single page only, the same field exists in "Page Settings" → "Additional"; then republish that page.
Wix#
- The site must be published and the domain connected: that is Wix's own condition for custom code.
- Settings → Development & integrations → Custom Code.
- "+ Add Custom Code" → paste the line, give the snippet a clear name.
- Apply to All pages, load once, placement — Head. Save.
- Press Publish, open the live site and press "Check installation".
⚠️ Wix code snippets are tied to the domain: assign another domain to the site and the snippets are deleted — the tag has to be pasted again.
Shopify#
- Shopify admin → Online Store → Themes.
- On the theme "…" → Duplicate: the copy is your way back.
- There as well: "…" → Edit code.
- On the left, the Layout folder → the
theme.liquidfile → paste the line before the closing</head>(or before</body>) → Save. - Open the storefront and press "Check installation".
⚠️ The edit belongs to the theme, not to the shop: switch or re-create the theme and you must paste the tag into the new one, otherwise the widgets disappear with the old theme. Shopify checkout pages are closed to arbitrary theme scripts — the widgets are meant for the storefront.
Webflow#
- Site settings of the project → the Custom code tab.
- The Head code field → paste the line and save. Only the script itself goes there: no
html,headorbodywrapper tags. - Press Publish — custom code does not run in the editor or in preview.
- Open the published site and press "Check installation".
⚠️ Custom code fields in Webflow site settings are available on a paid Site plan. If you need a widget on one page only, a page has its own code fields in its settings.
Squarespace#
- Site panel → Website → Website Tools → Code Injection.
- The Header field (it goes into the
<head>of every page) → paste the line → Save. - Open the live site and press "Check installation".
⚠️ The Code Injection panel is available on the Core, Plus and Advanced plans and on some legacy Squarespace plans. A page Code Block is not a replacement: it puts the code inside one page, while widgets are needed across the whole site.
The steps are checked against the platforms' official help. If a platform renames a menu item, trust its help centre rather than us — and tell us, we'll fix it.
Twelve widgets#
Each widget is a card with a toggle and a settings gear icon. Whatever the widgets collect lands in the regular sections of your admin panel — there's no separate "website inbox" to watch.
| Widget | What the visitor sees | Where the data goes | Documentation |
|---|---|---|---|
| 🍪 Cookies & Consent | Consent banner with categories and a preferences screen | Consent log, cookie declaration | Cookies & Consent |
| 💬 Chat: AI assistant and agents | Chat bubble on the page | The “Guests” section of Team Chat — together with WhatsApp, Telegram, email, Messenger/Instagram | Chat with guests |
| 💡 Popups & Forms | Promos, exit-intent offers, email capture, timers | Campaigns and their statistics | Engagement campaigns |
| 📅 Table Reservation | "Book a table" button | The "Tables" section — bookings and floor plan | Table reservations |
| 🗓️ Online Booking | "Book now" button: service → specialist → time | The "Appointments" section | Appointment book |
| 🛒 Online Ordering | "Order" button, cart and checkout on top of your site | The "Orders" section | Online ordering on your own site |
| 📚 Help Center | A "?" button with your published help articles | Articles live in "Articles & Pages" (the "Help" group); help analytics live in the Knowledge Base | Help Center |
| ⚖️ Legal Documents | Links to — or the text of — your privacy policy, terms, and other legal pages | Pages hosted by us; republishing updates your site automatically; configured right in the widget panel, with no wizard | Legal documents |
| 📞 Call from website | A "Call" button — talking straight from the browser, no dialing | The "Calls" section: a recording and a breakdown, like a regular call | Call from website |
| ☎️ Callback | A "Call me back" form with a choice of convenient time | Callback queue: the system dials the manager and the guest itself; requests land in "Requests" and in the "Callbacks" tab of the "Customers" section | Callback |
| ➕ Multibutton | One floating button behind which all your contact channels sit at once | Wherever the chosen channel leads; click statistics by channel live in your admin panel | Multibutton |
| 📈 Live Showcase | Unobtrusive "just booked a table" pop-ups | Collects nothing — it only shows your own events | Live Showcase |
The load order is deliberate: the cookie banner starts first, so that the other widgets and any third-party analytics on your site see the visitor's cookie decision already applied. For the same reason, multibutton loads second-to-last: it gathers the already-enabled widgets under itself and mutes their own buttons, so the corner doesn't end up with five buttons jostling for space. "Live Showcase" loads last — its cards step aside if another button is already sitting in the same corner.
Multibutton is not just a list of links: it has an invitation bubble ("Have a question?"), display conditions (which pages, after how many seconds, mobile-only or everywhere), a first-message draft for messengers, and its own click statistics by channel.
"Live Showcase" shows social proof built on your own data — orders, table reservations, and bookings — and does it honestly: there are no names or phone numbers in the cards, events are aggregated, and stale ones stop showing according to the location's calendar (a location that was closed yesterday doesn't "sell" yesterday's orders).
The "Popups & Forms" card has a "✨ Create from a template" button next to the toggle and the gear icon: it opens the same widget settings window, but straight on a gallery of ready-made scenarios — and it saves nothing until you click "Done".
The "Legal Documents" panel no longer sends you into a five-step wizard: the country, the set of documents, questions about your business, your company details, and the language all sit on one screen, with auto-fill and the preview collapsed, and a "Publish N documents" counter at the bottom. An option that contradicts answers you've already given is locked, with an explanation of exactly why.
The hub's open windows live in the page address: a widget's gear icon writes ?widget=<widget>, and the install-code window writes ?panel=install. That means a link to a specific widget's settings can be sent to a colleague, and it will survive F5 and the browser's Back button.
For one widget the toggle alone is not enough — it also needs content:
- Online Booking appears on the site once your menu has at least one item of type "Service" and booking is enabled (the same switch used for table reservations);
- Help Center switches on with the toggle right away, but without published articles it opens an empty help page — the widget's settings show how many articles are published.
Above the buttons of every card sits a 7-day mini-statistic: views, opens and a third number that fits the widget (leads, orders, reservations, bookings, calls, conversations, clicks). “—” means there is no data at all yet, “0” means telemetry exists but nothing happened; “More →” leads to the “Website widgets” dashboard.
The online ordering settings window has one more button for a third-party site — “🔔 Notify when back in stock”: you pick the product and variant from your catalogue, mark up the button on the sold-out product page, and the guest leaves an email, confirms it via a link and receives a single message when the item is back in stock. We never read a third-party catalogue or take stock levels from a third-party page — the product is linked by hand. Details are in Online ordering on your own site.
Forms that are already on your site#
The “📝 Forms that are already on your site” block under the card grid is for the case “the enquiry form is already on the site, and nobody is going to change it”. We neither replace nor delay it: the form submits to your back end as before, and a copy of the enquiry lands in the dashboard.
A rule is a CSS selector for the form, the addresses of the “name / phone / email” fields (the value can be just a field name such as phone, or a selector like input[name="tel"]), optional page masks and a toggle. Up to 10 rules per location, one rule per form. A rule without a form selector, or without a phone or an email, cannot be switched on — it would have nothing to collect. Every row has a “Check” button: the server reads the page and reports whether the form was found, which of the rule's fields are in it, and which field names it has at all.
What exactly is sent. Exactly three fields — name, phone, email — plus the page address without query parameters or the hash. Input before “Submit” is pressed is never read, we add no validation and no delays of our own, and a form that fails the browser's own validation creates no lead. Re-submitting the same form with the same contact within 10 minutes (a retry, “back → submit again”) yields one lead, not two. Forms of our own widgets are not listened to, so a lead never doubles.
Where to find them. The “Leads” section and the “Leads” tab of the contact centre — as the group “Site forms:
⚠️ The “Check” button parses HTML without a browser: a form drawn by JavaScript will not be seen by it — while the interception in the guest's browser will see it. The panel says so directly.
Action links and QR codes#
The “🔗 Action links and QR” block under the card grid builds a link that opens one specific action on your site: https://your-site/#cenaly=book — the reservation form, #cenaly=appointment:<service> — booking straight into a service, #cenaly=order:<product> — the product card, plus chat, callback, the help centre, a document (legal:<type>) and the multi-button fan. Such a link is usually printed as a QR code: on a table, on a receipt, on packaging, in offline ads.
How to build one: choose the action, optionally a specific object (a service or an item from the published menu, a published document) and “where you place it” — this sets the UTM tags for your analytics (utm_source=qr&utm_medium=<place>&utm_campaign=<action>; we do not read them). The output is a link with a “Copy” button and a QR code downloadable as PNG and SVG. The link's base is your site address; if none is set, our storefront. Every widget card has a short “🔗 Link” button with the action preselected.
Why a # hash rather than a ? parameter: third-party CMSs, cache plugins and CDNs strip unknown parameters and change the canonical address, while a hash is never sent to the server by the browser — it is guaranteed to reach our code. It is executed by the unified tag: it reads the hash once on load, removes it from the address and opens the widget once it has come up. Standalone widget tags do not read the hash.
The block warns before you print a batch: the action's widget is off, or no install code was found on the site at the last check. The link does not switch on what is off and does not substitute a missing document — in that case it simply does nothing: on a third-party site that beats an error. The same link also works on our storefront of the business, including the help centre, documents and the multi-button — the sticker is printed once, and the site may change.
The online booking widget in detail#
Settings live in the "Online Booking" card → gear icon: button color, its text, the screen corner, and the language. Right below the settings there's a ready-made code line just for this widget, in case you're installing only this one.
Language. The default is auto: the widget speaks the language of the page it sits on and knows 45 languages. Only the dictionary that's actually needed gets loaded, so this doesn't affect your site's speed. You can also pin one language in the list — for example, if the site is bilingual but you want bookings taken in just one language.
Links to a specific service or specialist. You can add attributes to the widget tag so the guest lands right on the step you need:
| Attribute | What it does |
|---|---|
data-service="service id" |
the service is pre-selected — a "Book" button next to the service's description on your site. The id is shown next to the item in the "Menu" section |
data-master="specialist id" |
the specialist is pre-selected — for a page about a specific specialist; the specialist's id is the same as the employee's id |
data-open="true" |
the booking panel opens on its own, with no click on the button — for a dedicated "Book now" page |
A stale id (the service was renamed, the specialist left) doesn't break the widget: it quietly shows the usual choice starting from the first step.
Fewer steps to a booking:
- a single service or a single suitable specialist — the extra screen isn't shown;
- the "⚡ Nearest: today 17:30" chip books in one tap, and the calendar opens on its own on the first day with free time;
- the name, phone, and email are remembered on the guest's device: on a repeat booking the fields are already filled in, and the "Not you?" link clears them;
- on a phone the panel opens full screen, and the booking button doesn't hide under the keyboard;
- the widget can be used from the keyboard and reads correctly with a screen reader.
Email. The email field is optional; if the guest leaves an address, they get a letter with the visit details and a "Manage booking" link that lets them move or cancel the visit themselves. Details — in Appointment book.
What the widget brought in. In the appointment book, the "🌐 Website widget" button shows the funnel for 7, 30, or 90 days: how many times the button was seen, how many guests opened the panel, reached the contact step, and booked, and how many bookings were lost to a slot taken meanwhile. Bookings that came from the site carry a "From website" badge.
Installation check#
The "Check installation" button opens your site and reads the page's source HTML. Possible answers:
- "Widget code found on the site" — the single tag is in place;
- "Only individual widget tags found" — old individual snippets are working, there's no single tag;
- "The code on the site belongs to a different location" — the tag carries someone else's
data-domain(a common mistake with several venues); - "No widget code on this page" — no tag is visible.
⚠️ The check reads the source HTML of one page. If the tag is inserted in the browser by Google Tag Manager or another script, the check won't see it — that's not an error. What else stays outside the method is collected below in “What the installation check does not see”.
Once a week the same check re-runs on its own — for locations that have a site address, at least one widget enabled and whose previous check found the tag. A tag dies silently — the site moved to a new theme, a contractor shipped a layout without the snippet, a cache plugin threw out the “extra” script — and before, the only way to notice was that the leads had stopped. Now the transition “tag was there → tag is gone” arrives as a card in the team chat (no more than once a week per location) and as a red third step in the “Your site” block. A site that did not open (timeout, server error) is not counted as broken — we will check again next week; a tag inserted through Google Tag Manager is never seen by the check, so there will be no false alarm for it either.
The same analysis is available publicly, without signing in — the Site check page: paste an address and it reads the page HTML and shows analytics and ad pixels by name, whether a consent banner is installed (ours, another vendor’s, or none), and whether our tag with its enabled widgets is visible. Handy for checking a site before connecting it, and for handing a link to a developer or a client.
Below the widget cards, the section has two more blocks: "Storefront on your own code (Headless)" — data, an API, and webhooks for when your own developer builds the site and doesn't need our widgets — and "Advanced: a separate tag per widget" with ready-made individual tags. So an individual tag isn't only something you "carry over from the past" — you can also take one right here.
What the installation check does not see#
The method is simple and honest: one request for the source HTML of one address, with no browser. We read what the server returned and look for <script src="…"> with our paths in the markup. Hence the whole list of what it cannot do — this is the boundary of the method, not a defect.
| Case | What the check will say | How to find out for real |
|---|---|---|
| The tag is inserted by Google Tag Manager or any other script in the browser | "no code" | Open the site: the widget is either there or not. In developer tools, the Network tab, filter site/v1.js |
| Another page of the site: the tag is in the home-page template but not on blog or catalogue pages | an answer about the address that is in the "site address" field | Put the full address of an inner page into the field and run the check again |
| SPA (React, Vue and similar with client-side rendering): the markup is assembled by JS in the browser | "no code", even when the widget works on the site | Look with your own eyes. It is safer to put the tag into the server template or index.html rather than inside the app |
| Navigation inside an SPA without a page reload | nothing: the check does not click through the site and only sees the first server response | Walk through the sections yourself — the widget lives on the page and survives such transitions |
The site answers over http:// only, or is behind a login, an IP filter or anti-bot protection |
a check error | The check only goes over https and without authentication; look at such a site yourself |
| A very large page | the first 512 KB of markup are read | The tag belongs in <head> of the template — that puts it at the start of the page |
| More than three redirects in a row | an error | Enter the final address |
| A platform or CDN cache serves a stored copy without the tag | "no code" | Purge the cache and repeat |
| The tag is there but the widget does not work (not paid for, toggle off, display conditions kicked in) | "code found" | That is a different question — see "Troubleshooting" below |
What the check does see well: whether our tag is in the source markup, whether it is the single loader or a set of individual tags, and whose data-domain it carries — that is, it catches the most common mistake, "copied the code from a neighbouring location".
The public Site check page has exactly the same boundary: it reads the source HTML and does not execute scripts. Real cookies and everything loaded in the browser are collected only by the CMP scanner — see Cookies and consent.
Troubleshooting#
A general list for all twelve widgets — from the most common cause to the rarest. Specifics of a particular widget are covered in its own article.
1. "Check installation" says there's no code. The tag isn't inserted, it isn't inserted on every template page, or the site hasn't been republished after inserting it (Tilda, Wix, Webflow require republishing). Also check the site address in the section header: the check runs against exactly that address — and against that one page only. Before fixing anything, go through “What the installation check does not see”: half of the "no code" answers are the boundary of the method, not a broken site.
2. The code on the site belongs to a different location.
The tag carries someone else's data-domain — a common mistake when there are several venues and the code was copied from a neighboring card. Take the code with the right location selected.
3. The check doesn't see a tag inserted through Google Tag Manager. That's not an error. The check reads the page's source HTML — what the server actually returned — while GTM inserts the tag only in the browser. Open the site and look with your own eyes: the widget is either there or not. The full list of what the method does not show (GTM, another page of the site, an SPA, a closed site) — “What the installation check does not see”.
4. Changes haven't shown up on the site. Widget files are served through a CDN with a 5-minute cache. After flipping the toggle or changing the settings, wait a few minutes and reload the page with the cache cleared (Ctrl+F5). If the browser keeps showing the old version, check in an incognito window.
5. The widget is on, but it's not visible on the page. Go through the list:
- the widget is a paid add-on and hasn't been paid for — an unpaid add-on is stripped from the site's data on the server, so it will not reach the page even with the toggle on;
- the widget has display conditions (multibutton, callback, "Live Showcase"): a page mask, a delay, a device filter, or a schedule may have filtered out exactly this page and this moment;
- the widget is missing content: online booking appears once the menu has at least one service item and booking is enabled; the help center opens an empty panel without published articles; multibutton isn't drawn at all without a single channel; "Live Showcase" stays silent while the numbers are below the threshold;
- multibutton has absorbed a neighboring button: if its fan menu has an "Open chat" or "Callback" item, those widgets' own buttons are deliberately muted — they're now inside the fan menu.
6. Several buttons are crowding the corner of the screen. Turn on multibutton and add the actions of the widgets you need to its fan menu — their separate buttons will go dark on their own.
7. There are no widgets on a site built with our website builder. There, the install code is baked into the template, and the code block doesn't appear in the admin panel — that's normal. Check the widget toggles instead: a freshly generated site arrives with the cookie banner, legal documents, and chat already on; everything else needs to be switched on manually. Also note the difference between surfaces: on our storefront, multibutton shows only via a separate "Also show on our storefront" toggle (it absorbs the page's native buttons there), while "Live Showcase" works off the same single toggle as on someone else's site.
Website with Content-Security-Policy#
If your server sends a Content-Security-Policy header, the browser decides on its own what our installation code is allowed to load. The tag itself still works—you allowed it—but everything it pulls in can be blocked silently: from the outside, it looks like "widgets have disappeared." In the browser console, you will see lines like Refused to load the script.
The breakdown occurs in exactly one mode: the policy allows scripts only via a one-time nonce, without 'strict-dynamic' and without our CDN host on the list. Below are three ways to resolve this, from the simplest.
Option 1 — nonce on our tag#
Your server generates a new random value for every response, placing it in both the header and the tag:
Content-Security-Policy: script-src 'nonce-r4nd0m...'
<script nonce="r4nd0m..." src="https://cdn.<your-brand>/site/v1.js" data-domain="YOUR-LOCATION" async></script>
The unified tag reads the nonce from its own tag and passes it to each widget bundle it injects—they pass the same check. Nothing else needs to be permitted.
⚠️ A persistent value that is identical across all responses is not a nonce: anyone who manages to inject code onto the page will copy it into their own script. Generate it for every response, on the server.
Option 2 — 'strict-dynamic'#
Content-Security-Policy: script-src 'nonce-r4nd0m...' 'strict-dynamic'
With 'strict-dynamic', trust in our tag extends to the scripts it injects, and there is no need to list anything else. This is the shortest policy under which all widgets work, including the lazy-loaded parts of "Smart Popups".
Option 3 — host list#
If a nonce is unavailable to you (as is often the case with website builders), explicitly allow our hosts:
Content-Security-Policy: script-src https://cdn.<your-brand>;
connect-src https://cdn.<your-brand> https://api.<your-brand> wss://ws.<your-brand> https://o.<your-brand>;
img-src https://cdn.<your-brand> https://i.<your-brand>;
frame-src https://cdn.<your-brand> https://your-location.<your-brand>;
style-src 'unsafe-inline'
A ready-made snippet with your brand's hosts and your location already populated is available in the dashboard: Marketing → My Website, under the "Website with Content-Security-Policy?" block below the installation code—there is also a "Copy" button and a note on which widget needs each host.
What is needed for what:
| Directive | Required for |
|---|---|
script-src |
All widgets: bundles from our CDN |
connect-src |
All: requests, reservations, bookings, orders, telemetry; for chat—WebSocket and signal bucket |
img-src |
Ordering: photos of items and dishes |
frame-src |
Ordering, support center, and legal documents: they open your storefront in an <iframe> |
style-src |
All: widget windows inject <style> into their Shadow DOM |
What this does not cover — honestly#
- Styles. Window styling uses inline
<style>inside Shadow DOM, which is whystyle-src 'unsafe-inline'is required. This does not affectscript-src: we do not request'unsafe-inline'or'unsafe-eval'for scripts. - Lazy-loaded parts of the widgets (rich popups and slots of “Smart Popups”, the consent banner's age gate, the multi-button mobile bar, form interception) are loaded by their own loaders and do receive the nonce — they pass the same check as the main bundle. The exception is the form of the “Notify when back in stock” button (
stock/form-v1.js): it is a separate tag outside the unified loader and does not carry the nonce yet — under a nonce-only policy without our CDN host, the subscription form will not open. - Website builders (Tilda, Wix, and similar) send the header themselves, so you cannot issue a one-time nonce to your tag there. The host list option remains—if the platform allows editing the policy at all.
- Website call transmits audio via a WebRTC stream and does not load media files, so it does not need
media-src; microphone access is permitted byPermissions-Policyand HTTPS, not CSP.
Move a widget to its own section#
If one of the widgets is your main product (say, you only use popups or only the cookie banner), the path "Marketing → My Website → card → gear icon" is too long. Each card has a "Move to sidebar" button — the widget gets its own menu item and opens in one click.
This is a setting for your interface: it only controls the section's visibility, not how the widget runs on your site.
What is included and what is a paid add-on#
Some widgets are part of the subscription, others connect as an add-on in the "Extensions" section: Table Reservation, Popups & Forms, Help Center, and Legal Documents are marked as paid — their card carries a "💳 Paid add-on" chip.
A paid widget turns on after purchase. Clicking the toggle on an unpaid widget doesn't turn it on — it opens the checkout window right in the section; the widget switches itself on after payment. The "💳 Paid add-on" chip on an unpaid widget is also a checkout button, while on an already-paid one it leads to the catalog to review the subscription. A widget that's already running won't switch itself off. The limit isn't only in the interface: an unpaid widget is stripped out of the location's published data, so it won't appear on the site in any case.
On a site built with our website builder, "Legal Documents" and the cookie banner are free. Their cards carry a "🎁 Included with the site" chip instead of "paid," and no checkout window is shown at all: this isn't an upsell, it's the condition under which the site can be used lawfully. A freshly generated site arrives with the cookie banner, legal documents, and chat already switched on. On someone else's site, both widgets remain paid add-ons.
Pricing and payment — in App Store and Subscription.
Related sections#
- Website builder — if you don't have your own site and want to use ours
- Headless storefront — if your own developer builds the site and takes the data from us
- Custom domain — connecting your own domain to our storefront
FAQ#
Do I have to give up my own site? No. The widgets live on top of your site; you don't change your layout or hosting.
How many tags do I paste if I have several widgets? One. The set of widgets is toggles in the admin panel.
Will a widget slow down my site?
The loader connects asynchronously (async) and doesn't block page rendering; each widget loads as its own small file, and only if it's enabled. A disabled widget isn't downloaded at all.
Will a widget break my layout? No. Every widget is drawn in an isolated container (Shadow DOM): your site's styles don't leak into the widget, and the widget's styles don't leak out. The one deliberate exception is the online ordering widget: it intentionally places "Add to cart" buttons in your own markup, and this is configured with a preview (see Online ordering on your own site).
What language will a widget speak?
It looks at the page's language: first the data-lang attribute in the tag, if you've set one, then the lang of your HTML page, then the guest's browser language, and English as the last resort. Dictionaries vary in size: the cookie banner, the online booking widget and the chat window know 45 languages (the chat's labels arrive as a separate language pack matching the page language), and the rest ship with English, Russian, Georgian, and Turkish, falling back to English. You set the button labels and invitation text yourself — a separate line for each language of your site.
Where is the data the widgets collect stored?
In your brand's cloud: AWS for cenaly.com, Yandex Cloud for cenaly.ru; data from Russian venues stays in Russia. Requests, orders, table reservations, and conversations land in your admin panel, while only the widgets' settings and things that are public anyway (the menu, opening hours, published documents, Live Showcase's anonymized numbers) go out to the public CDN.
I have several venues — how does that work?
Widgets are configured per location: pick it in the list at the top of the section and take that location's install code. Each site has its own data-domain.
Can I put the widgets on several different sites? Yes, one location's tag can be pasted on several pages or sites — the data will arrive in that one location.