From Blueprint to Sold Out: One Venue Through Design, Render, Go Live

How one venue moves through Seatmap Pro: drawn in the editor, published to the renderer, sold through the Booking API, and filled on the night.

From Blueprint to Sold Out: One Venue Through Design, Render, Go Live

A ticketing platform buys a seat map for one evening. On that evening the house is full, and nobody had to fix a row by hand the day before. Between the empty file and that evening, the venue passes through four stages, and each one belongs to a different part of Seatmap Pro.

We made a short film about that path. It follows one arena with a round stage from a blueprint in the morning to a sold-out night.

This post walks through what happens at each stage and which tool does the work.

Design: the venue is drawn once

You draw the first section in the Editor with the Seat Rows tool. Drag a rectangle, and the Editor shows how many rows and seats it will produce before you let go. After that, the section panel takes care of row labels, outline, alignment, extra rows, rotation and curve by value or slider, and flip. For the next section of the same shape, use Clone Section.

A round venue needs a few more controls:

  • Venue Shape places sections inside, outside, or centred on the outline of the hall.
  • Path-based transformation bends rows along a curve, so a ring of sections keeps its rows parallel to the stage.
  • Tables, round or elliptical, and general admission areas with a set capacity cover the floor.
  • Number Seats applies arabic, roman, or alphabetic numbering, and numbering defaults can be set once per schema.
  • Pricing Zones group seats for the prices you assign later, and an SVG underlay keeps the drawing true to the real floor plan.

Until you publish the schema, it stays a Draft. Prices go on the published version, so a half-finished drawing never reaches a sales channel.

Render: the same data on the buyer’s screen

When you publish, the schema goes to the Renderer. The booking page loads the @seatmap.pro/renderer SDK with a public key and an event ID, and the buyer sees the venue you drew, with its sections, rows, and prices.

If the host page turns WebGL on, the Renderer draws through it. On a device without WebGL, it falls back to HTML5 canvas. The 3D view reads the same schema and adds depth, so you don’t rebuild the drawing for another view. You can try it in the Playground with the view3D preset.

Go Live: seats that sell without conflicts

After sales open, the platform handles seats through the Booking API:

  1. When the buyer picks a seat, the platform locks it. A booking session holds it for fifteen minutes by default, with a ten-minute grace period for payment.
  2. The sale confirms the seat. If the platform doesn’t need a hold, a direct sale books the seats in one atomic call.
  3. If a lock expires or is released, the seat goes back on sale.

Since version 1.72.0, the Booking API can also refuse a selection that would leave a single seat stranded between sold ones. In that case it returns HTTP 422 with ORPHAN_SEATS_REFUSED. A fault in the check itself never blocks a sale. In that case the sale goes through.

Enjoy: the night the house is full

This part of the film shows no tools at all. By the evening, the drawing, the prices, and the seat locks were all settled in the Editor and the Booking API.

The largest venue on Seatmap Pro today seats 80,000. It runs on a customer deployment with real ticket sales.

Bottom line

You draw the schema once in the Editor and publish it once. The Renderer then shows it on every device, and the API sells it seat by seat. Each stage has its own tool, and none of them asks you to redraw the venue.

If you want to walk your own venue through these four stages, book a demo and we’ll build the first sections with you.

Continue reading

All posts →