Sandbox

Open the demo

venue-seating-wizard.aviramk.com/en/?demo=1 boots the optimizer pre-loaded with the published example dataset: six bookings needing twelve seats, across four tables providing thirty-four. Run the optimizer, drag a guest, lock a placement, export the CSV — the whole flow, against input that is known to be valid. In Hebrew: /he/?demo=1.

The demo seeds an empty workspace only. If you already have an event open in this browser, the link leaves it exactly as it was.

Why there is nothing to isolate

Optimization runs in a Web Worker in your own browser and nothing is persisted server-side, so every session is already isolated from every other one. There is no shared production dataset to corrupt, no test key to swap in for a live one, and no way for a demo run to affect another visitor. That is a property of the architecture rather than a mode you switch into.

The API needs no separate base URL

Every operation under /api/v1 is a read-only GET over a static document. Calling one has no side effects and cannot be destructive, so pointing an integration at production during development is safe by construction. /api/v1/sandbox.json says the same thing in machine-readable form, including the dataset's URLs and totals.

The dataset

• /examples/guests.csv — six bookings, one of them declined (party size 0)
• /examples/tables.csv — four tables, three positioned, one left for automatic placement
• /api/v1/examples.json — the same files with a step-by-step walkthrough

The column contract for both files is on the documentation page, and the rest of the integration surface is in the developer portal.