Using the Brella REST API to pull meeting and lead data

An exhibitor calls three weeks after the show. They had 41 meetings, which they can see in their own dashboard, and they want to know whether 41 is good. The answer you have is another count: the median exhibitor had 18, so 41 is well above it. That answer lasts about four seconds, because the next question is whether the meetings were any use, and a count cannot say.

A Brella REST API pull can, at least partly, because the platform carries a field most integrations ignore. Brella describes the product as offering "a powerful, but simple API" and lists a public REST API with the line "Build flexible integrations with our simple, but powerful REST API", alongside a stated selection of more than 500 integrations, native connectors with supported partners, and webhooks (Brella, 2026). What matters for reporting is less the transport and more which objects you decide to bring across.

Which objects should the pull bring across?

Brella's own feature list names one to one and group meetings, a managed meetings view for organisers, meeting ratings, and a lead scan capability described as "Built in lead and contact scanning to manage your event activity and increase ROI" (Brella, 2026). Each of those is a different grain, and the mistake that costs a fortnight is assuming they share one.

Group meetings are the clearest example. A one to one appointment is one meeting with two participants. A group meeting with an exhibitor and four buyers is one meeting with five, and whether your pull returns one row or five decides whether your meetings-per-exhibitor figure is comparable across a portfolio. Settle it before the first load by pulling one known group meeting and counting the rows it produces.

Ratings are the second. If both sides can rate, a single meeting can carry two ratings, and a naive count of rating rows will overstate rated meetings by whatever proportion of them got a response from both parties. Count distinct meetings with at least one rating, then count meetings with two, and keep those as separate columns.

Lead scans are the third, and they carry a subtlety that a schema diagram hides. A scan record belongs to whoever did the scanning, so the same person scanned by four exhibitors generates four rows, each owned by a different company. Aggregate those rows to the person and you get a visitor-level popularity measure. Aggregate them to the company and you get exhibitor lead volume. Both are legitimate, they answer different questions, and a table that does neither cleanly will be quoted for whichever number somebody wanted.

One more decision belongs at this stage. Brella lists native integrations with supported partners alongside the API, and describes a managed integrations service where its team handles the build (Brella, 2026). A native connector is faster to stand up and gives you no control over the schema you receive. An API pull costs a few engineering days and leaves the mapping in your hands, which is worth paying for when you run six editions on the same warehouse and need one definition of a meeting across all of them. For a single annual show with no portfolio reporting, the connector is usually the right call, and there is no prize for building the harder thing.

Meeting ratings are the field worth building around

Brella describes meeting ratings as a way to "Gain valuable insights on the value and quality of the meetings hosted at your events" (Brella, 2026). That is the only field in the standard object set that carries a quality signal at all, and every other number you can pull is a volume measure wearing different clothes.

The reason to care is commercial rather than analytical. Booking counts are easy to grow and easy to distrust. An exhibitor who received 41 meeting requests and accepted all of them looks identical in a booking count to one who was carefully matched into 41 relevant conversations. A rating distribution separates them, and once you can separate them you can price differently, staff the concierge programme differently, and defend a renewal conversation with something other than a total.

Ratings also change what a low booking count means. Twelve meetings rated 5 is a better outcome for a specialist supplier than sixty rated 2, and you cannot see that without the field. Building the ratings into a composite is a separate exercise, and turning ratings and outcomes into one score has its own design problems that this post leaves alone.

What does a rating coverage of 32 per cent actually tell you?

Here is the arithmetic on an illustrative show. Brella holds 4,120 booked meetings. Of those, 3,180 are marked as having taken place. The pull returns 1,236 rating rows against 1,024 distinct meetings, so 212 meetings were rated by both sides. Rating coverage is 1,024 divided by 3,180, or 32.2 per cent. The mean rating across the rated meetings is 4.3 out of 5.

The temptation is to publish 4.3 and move on. Before you do, ask what the other 2,156 meetings would have said. Suppose their true mean was 3.4, which is not a wild assumption if people who found a meeting useful are more inclined to answer a prompt about it. The all-meeting mean would be 1,024 times 4.3 plus 2,156 times 3.4, all divided by 3,180, which comes to 3.69. Your headline of 4.3 overstates by 0.61 of a point, and 0.61 on a five point scale is the difference between a good show and an average one.

Now the part that stops this becoming a counsel of despair. Groves reported in 2006 that nonresponse "can, but need not, induce nonresponse bias in survey estimates", and that recent empirical findings at the time illustrated "cases when the linkage between nonresponse rates and nonresponse biases is absent" (Groves, 2006). Bias depends on how strongly the tendency to respond is related to the thing being measured, so a 68 per cent nonresponse rate is not automatically a 0.61 point error. It might be a 0.05 point error.

The practical move is to test rather than assume. You already hold observable attributes on every meeting, rated or not: format, duration, day, whether the exhibitor was a first-time exhibitor, whether the buyer was in the hosted programme, and whether the meeting was requested by the buyer or the seller. Compare rated against unrated meetings on those. If the two groups look alike, your rating average is probably close to the truth. If rated meetings are concentrated among hosted buyers who had a concierge chasing them, you know both that the average is inflated and roughly where the inflation lives.

The lead scan rows an organiser cannot see

There is a hole in the data model worth knowing about before you promise anybody a complete picture. Brella's help documentation for organisers, describing attendee-to-attendee lead scanning, states that scanned prospects "will be saved in their individual event profiles" and that "You as the event organizer will not have access on the admin panel to any of the prospects saved" (Brella, 2026).

That is a defensible product decision and it has a reporting consequence. Peer-to-peer scanning is invisible to you, so any narrative about networking volume built from what you can pull is a lower bound on what happened. Say so in the report. The alternative, which several organisers reach for, is to present exhibitor lead capture totals as though they covered all connection activity, and that claim falls apart the first time an attendee mentions the 30 contacts they collected from other attendees.

What to settle before you write the pull

Five questions, in the order they will bite.

Which identifier ties a Brella participant to your registration record. If registration pushed people in, confirm the field carrying your reference and confirm it survives a profile edit. Where it is absent, you are joining on email, with the usual losses.

What the pull returns for a cancelled meeting. A meeting cancelled two days before the show may vanish, may flip status, or may keep its slot with a flag. Each behaviour needs different code, and the difference between them is roughly 5 per cent of your booking count on a normal show.

Whether ratings are editable after submission. If a rating can change, a snapshot taken on Friday and one taken the following Wednesday disagree, and neither is wrong.

How rate limits behave during show week. A pull that runs comfortably in February at 800 meetings can time out in October at 4,120.

Where the pull sits relative to a push feed. Running a scheduled pull and a webhook subscription side by side is the reconciliation habit, and the trade-off between a push feed and a nightly poll decides which one is your source of record.

Where this stops

Ratings measure the rater's impression at the moment of the prompt. They do not measure whether business followed, and the correlation between the two is unknown on your show until you go and check it.

That is worth stating plainly because ratings invite over-reading. A meeting rated 5 by a buyer who enjoyed the conversation and bought nothing is recorded identically to one that opened a six-figure order. If you want the second thing you have to get outcome data from the exhibitor's own systems months later, with all the response bias and lag that implies, and no API from a matchmaking platform will hand it to you.

The second limit is scale. On a show with 300 booked meetings, a 32 per cent coverage rate gives you 96 ratings, which is enough for one show-level average and nothing else. Stand-level averages on four ratings each will produce a league table that reverses itself next year, and publishing that table teaches exhibitors to distrust everything else you send them. Set a minimum count below which you report the count alone, and hold it. The same discipline applies to reading meeting demand from a matchmaking platform's own export, and to every other feed in your integration layer.

Start with one call. Pull a single edition's meetings and ratings, count distinct meetings with at least one rating, divide by meetings that took place, and write that percentage on the front of the deck you were going to send exhibitors. If it is below 40 per cent, fix the prompt before you fix the analysis.