Expo and Enterprise
What API access is for
The short version: your plan stops being somewhere you type things and starts being something your other systems can read and write. If you already have a booking form, a CRM, a finance system or a website that knows who is coming, this is how it stops being your job to keep them agreeing with each other.
Not built yet. This describes what is being built and what it is for, so you can tell whether it will do what you need before you pay for it. If you need it now, say so on the Enterprise form — what people ask for here decides what gets built first.
Four things people actually want
Stop typing everything twice
Traders apply through your own form. Right now somebody reads those and types the names onto the plan. With the API your form writes straight to the plan — the trader submits, the space shows their name, nobody retypes anything.
POST /api/plans/{plan}/spaces/{ref} with a name, a
description and a status.
Put who is coming on your own website
The embed puts the drawing on your site. The API gives you the data behind it, so you can build your own trader directory, your own "what's on" page, or a search that matches how the rest of your site works.
GET /api/plans/{plan} returns every space, who has
it, what they do, and where it is.
Bill from the plan
Confirmed spaces are your invoice list. A nightly pull into your finance system means the people you bill and the people standing on the site are the same people, which is not always true when the two lists are maintained by hand.
GET /api/plans/{plan}/spaces?state=confirmed
Know the moment something changes
A webhook when a space is held, confirmed or freed. Your CRM sends the welcome pack, your finance system raises the invoice, your steward's list updates — without anybody remembering to tell them.
We POST to a URL you give us, signed so you can
prove it came from us.
A worked example
A county show with 400 trade stands. Applications come through their own website, payment goes through their existing finance system, and the plan is what the public sees.
-
A trader applies on the show's own website
The show's form asks its own questions in its own words. Nothing about it changes.
-
The form asks us what is free
GET /api/plans/county-show/spaces?state=open— so the trader picks from spaces that genuinely exist, with real sizes and real positions, rather than from a dropdown somebody maintains by hand. -
Accepting the application holds the space
PATCH /api/plans/county-show/spaces/D14with{"state": "held", "occupant": "Gorse Farm Lamb"}. The public plan shows it held within the second, so two people cannot be sold D14. -
Payment clears, and the space confirms itself
Their finance system marks the invoice paid and sets the space to confirmed. Nobody opens our app to do it.
-
The webhook tells everything else
The CRM sends the exhibitor pack with their stand number in it, and the show's website adds them to the trader directory.
How it will work
- Authentication
- A key per integration, revocable on its own, so turning off a supplier does not break everything else.
- Scope
- Keys are read-only or read-write, and limited to named plans. A website directory should not be able to move a stall.
- Format
- JSON over HTTPS. Sizes come through in metres whatever your display setting is, because a machine reading a plan should not have to guess the unit.
- Rate
- Generous, and published. Polling a plan every minute during load-in is a normal thing to do.
- Refs
- You address a space by the ref people say out loud —
D14,W-A1— not by an internal id, because the ref is what is on the paperwork.
When you do not need it
Most events do not. If you type names onto the plan yourself and share a link, that is the product working as intended and the API adds nothing. It earns its keep when a second system already holds the same facts and somebody is currently keeping the two in step by hand — that person is the reason to buy it, and if there is no such person, there is no reason.