Keep your site. Change what happens when someone clicks Book.

Three ways to install it, same booking engine underneath

Script tag: mount the widget with your key and shop config, styled to sit inside your existing page. Iframe: use it when you want a hard boundary from your site's theme CSS instead of fighting for style conflicts. Hosted page: send traffic straight to your shop's own booking URL on inkdesk.online when you don't need an embed at all.

Pick based on your actual site, not because one option sounds more advanced — all three run against the same availability, deposit, and appointment engine underneath.

Place the embed where intent is actually highest, not buried below three screenfuls of gallery photos. If the book button lives at the bottom of a long scroll, you'll keep getting DMs instead of bookings, no matter how good the widget is.

Restrict allowed origins so a copied snippet on some random site can't impersonate your shop's booking flow. Multi-tenant isolation already keeps shop data separate — domain allowlisting protects your actual brand from a bad copy-paste somewhere else.

It works with the site builders shops actually use

Non-technical owners can follow platform-specific install docs through a guided connect flow, without ever pasting a raw API secret into a theme file. Agencies wanting full control over the UI can use the public API directly while still letting deposits, waitlist, and reminders run through Inkdesk underneath.

Allowed origins and widget domain settings keep random sites from embedding your booking button — worth caring about if your brand shows up on comparison sites or someone else's marketing page without permission.

When there's genuinely nothing open, the widget should still capture demand through the waitlist instead of hitting a dead end — that's how a cancellation later turns into a `waitlist.filled` event instead of a lost Instagram DM nobody follows up on.

A shop working with a web designer or agency doesn't need to hand over Inkdesk credentials to get the widget installed correctly — the connect flow is built so a designer can follow platform-specific steps and drop in the right snippet without ever touching the shop's actual Stripe or booking settings, keeping day-to-day account access limited to the people who should actually have it.

What a client actually experiences inside the widget

Artist and slot selection off live availability, an estimate or deposit preview when configured, and checkout for a flat or percent deposit through Stripe Connect — card minimums typically around $20 or more. Complex work can route to review before any payment happens at all.

After booking, the cancel and reschedule window — commonly 48 hours, configurable — plus reminders and consent or check-in flows all continue inside Inkdesk, not on whatever CMS is running the marketing site around it.

For developers wiring something more custom

OpenAPI-described endpoints cover catalog, availability, bookings, deposit intents, and portfolio for teams building a fully bespoke front end instead of the pre-built widget. Outbound webhooks include booking and waitlist events, including `waitlist.filled` when a refill happens.

SDKs and CMS-specific plugins are convenience layers on top of the same universal script, iframe, and hosted surfaces — useful, but never required to go live.

Going live without touching your existing design

Most tattoo sites already have a Book link that quietly dies into DMs. Replace that link with the hosted book page, or drop a script or iframe embed above the fold, while keeping your existing portfolio photos and marketing copy exactly where they are. Let Inkdesk own slots, deposits, and the path into the day board.

On Wix and similar builders, an embed block or HTML section is usually enough. On WordPress, follow the install docs so you're never pasting secrets into a random theme file by hand. Custom stacks can call the API directly and still present a fully branded UI on top.

After install, walk through a booking and a deposit yourself and confirm both show up correctly in the cabinet before you send real clients to the link — then double-check the cancel-window copy matches the policy you actually enforce.

Give the new booking path a real trial period before declaring victory — a week or two where staff actively watch for anything that feels off, like a client showing up confused about the deposit amount or a booking landing with missing contact info. Small mismatches between what the widget shows and what your policy actually says are much easier to catch and fix in week one than after a month of bookings have already gone through under a slightly wrong assumption.