What the ExpoFP floorplan API gives you and what it does not

The floor plan on the show website looks right. Four hundred and twelve booths, colour coded by category, searchable, and the sales team is happy. Then the post-show report asks a question that sounds trivial. How much net square footage did our top twenty exhibitors occupy this year compared with last?

Nobody can answer it from the plan, and working out why is the useful part. The ExpoFP floorplan API is a write path into a rendered plan, and the plan is a publication. The exhibitor master, the contract, the square footage history and the account key all live somewhere else, and if nobody decided where, they live nowhere.

What the API is actually for

ExpoFP (2026) documents three ways to get exhibitor data in: entering companies by hand, importing an Excel template that carries names, descriptions, addresses, booths, categories, contact details, social links and logo URLs, or calling the API. On the API the company is specific about the operations available: "Add Exhibitor: pull exhibitors from your system and add them to ExpoFP, Add Exhibitor Booth: assign them to a specific booth, Add Exhibitor Extra: if your event offers additional items for purchase".

Read the direction of travel in those verb names. Every one of them pushes data from your system into the plan. The developer portal adds a set of client-side SDKs for embedding, a JavaScript API for the browser, native SDKs for iOS and Android, and an offline data API that produces versioned archives of a plan for use without a network (ExpoFP, 2026). All of that is about display.

So the platform's role is clear and it is a good role. It takes an exhibitor list and a hall geometry and turns them into something an attendee can use on a phone in a loud hall. What it is not is the system of record for who your exhibitors are, and teams get into trouble when the plan becomes the only place a booth assignment exists.

Where does the geometry live?

Inside the plan, in the plan's own coordinate space, and that is worth understanding before somebody proposes exporting shapes into a warehouse.

An exhibition hall plan is an indoor drawing. It has an origin somewhere in the corner of the file, an arbitrary unit, and no relationship to the earth. That is the correct design for the job it does. It is also why the obvious geospatial standard does not apply: the GeoJSON specification, published as RFC 7946 by Butler, Daly, Doyle, Gillies, Hagen and Schaub in 2016, requires that "The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) datum, with longitude and latitude units of decimal degrees". A booth polygon in hall coordinates is not that and should not pretend to be.

Where an organisation genuinely needs indoor geometry in a portable form, the Open Geospatial Consortium's Indoor Mapping Data Format is the community standard built for it, described by OGC as providing "a generalized, yet comprehensive model for any indoor location, providing a basis for orientation, navigation and discovery", and it does conform to RFC 7946 by georeferencing the venue properly. That is a real project with real survey work behind it, and it is the right answer for a permanent venue with wayfinding ambitions.

For a trade show that occupies the hall for four days, it is almost never worth it. The pragmatic position is to treat the plan as the geometry source and keep exactly two things out of it in your own systems: the booth identifier and the net square footage. Those two fields answer the square footage question above without a single polygon leaving the platform.

Counting the gap in one hall

Export one hall and count both sides of the join, because the two counts have different owners and different fixes.

Take a hall with 412 booth polygons on the plan and an exhibitor list of 358 rows. Join booths to exhibitors and suppose 331 booths carry an exhibitor and 81 do not. Eighty-one out of 412 is 19.7 per cent of the hall unattached, which sounds alarming and is mostly fine.

Break the 81 apart. Suppose 34 are unsold inventory, which is correctly empty and belongs to sales. Another 22 are structural: pillars, a food service area, a lounge and two storage bays, all drawn as booth-shaped objects because that was the quickest way to get them on the plan. Fifteen are sold but the exhibitor record has not been created yet, which is a process lag measured in days. And 10 are genuine misses, where an exhibitor exists in the contract system and was never assigned.

So the real error rate is 25 booths out of 412, which is 6.1 per cent, and only 10 of those are anybody's mistake. Reporting 19.7 per cent would have started a fight about data quality. Reporting 10 booths and naming them starts a fix.

Now count the other direction. The 331 attached booths belong to, say, 306 distinct exhibitors, because some hold two stands. That leaves 52 of the 358 exhibitor rows with no booth at all. Some will be co-exhibitors under a parent contract, some will be directory-only listings, some will be sponsors who bought visibility and no floor space, and some will be cancellations that were never removed. That list is worth walking by hand once a year.

Who fixes an unmatched booth?

Assign each of the four categories an owner before the count is run, or the meeting turns into a discussion about whose fault it is.

Unsold inventory belongs to whoever sells the floor, and its count is a sales metric rather than a data defect. Structural objects belong to operations and the correct fix is upstream: draw them as a different feature type so they never enter the booth set. Booths sold but not yet configured belong to the show operations team, and the useful measure there is how many days the lag runs to. Genuine misses belong to whoever runs the assignment process, and ten of them is a Tuesday afternoon.

The reason to formalise this is that the same count runs every week during the sale and the numbers move. A weekly report of the four categories, with the owner named against each, turns an argument into a queue. It also gives you the structural count as a stable baseline, so a sudden jump in it means somebody drew something new rather than that the show is falling apart.

The join that makes all of this possible is booth identifier to exhibitor account, and getting that relationship into a warehouse in a form that survives is a modelling job in its own right, covered in keeping the booth link intact through the load.

Indoor geometry and the standards that describe it

One more consequence of the plan being a publication rather than a database, and it catches people planning year-on-year comparisons.

ExpoFP's own FAQ is explicit about how a plan carries forward: "Yes, you can copy the map, and optionally last year's exhibitors, to the new event", with the caveat that "there will be a separate charge for every year and every map will have a different URL" (ExpoFP, 2026).

A different URL per year is the detail to notice. The plan identity is scoped to the edition, by design, because the plan is a different publication each year. Any cross-year question therefore has to join on something you own, which brings you back to the exhibitor account key and the booth assignment table. If you were hoping the platform would hand you a five-year exhibitor history, it will not, and the multi-year extraction problem belongs with planning an export across several shows and years.

What the API does not give you

Worth stating plainly, because each of these has been assumed at least once.

It does not give you a contract. Booth assignment on a plan and a signed contract for that booth are separate facts that usually agree and occasionally do not, and the plan is the one that gets edited at 11pm before the show opens.

It does not give you an exhibitor master. Companies pushed in through Add Exhibitor carry whatever identifier you sent, and the quality of your cross-edition matching is a property of your system rather than the platform's.

It does not give you traffic. A booth polygon knows its shape. Whether anybody stood in it is a question for scanning or sensing hardware.

And it does not give you a schema promise. Any write API you build a nightly job against will change at some point, and what a vendor owes you when the schema moves mid season is worth settling before rather than after. The equivalent mapping exercise against a different platform's export has the same shape and different field names, which is the ExpoPlatform version of this problem.

Where this stops

Treating the plan as geometry and your own systems as the record works well, and it has one honest weakness: it makes the plan a second place where booth assignments exist, and two places drift.

The drift is one-directional in most setups, because the plan is where late changes get made under time pressure. Somebody moves a stand on the morning of build and edits the plan, and nobody edits the contract system. A month later your warehouse and the published plan disagree, and the plan is right.

There is no clever fix for that. The workable answer is a reconciliation run after the show closes, comparing the final published plan against the assignment table and writing the differences down as a list of specific booths, and a rule about which system wins that somebody has actually agreed to. It is a manual step, it takes about an hour on a 400 booth hall, and skipping it is how a floor plan and a revenue report end up describing different shows.

Start this week with the four-way split. Export one hall, join the booth list to the exhibitor list, and sort the unmatched booths into unsold, structural, pending and missed. Put a name against each of the four. You will almost certainly find that the number people have been worried about is three quarters inventory and drawing conventions, and that the part that needs work is small enough to finish this month. The rest of what an integration owes the systems around it sits with this cluster.