Skip to content
Core API
Esc
navigateopen⌘Jpreview
On this page

Create dashboards and reports

Use an agent and the Core API to analyze conferences, tradeshows and business events, then create useful dashboards and reports.

Turn your event data into an interactive dashboard, an exhibitor summary, a session review or a Markdown report. The Core API supplies the permitted data; an agent with analysis and file tools can calculate, visualize and save the results. These workflows use Read permission and do not require a Brella MCP server.

Install the skill, then choose an example below. If your agent cannot connect to the API, it can work from exports you provide; the report should identify their date and coverage.

Choose a useful output

Your question Core API sources Suggested output
How did our conference perform? Event analytics, session analytics Event KPIs and a session comparison dashboard, with a Markdown summary.
What activity did an exhibitor receive? Sponsor statistics; leads when a contact-level export is needed An exhibitor activity report and, if authorized, a separate follow-up file.
Where was networking capacity used? Networking timeslot analytics A timeslot/area dashboard showing meeting states, assigned meeting points and recorded feedback.
Which audiences and topics should we plan for? Audience segments, interest demand A segment comparison and topic/intent brief for the next event.
How do our event editions compare? Organization event benchmarks A comparison table with cohort median and changes from the previous eligible event.
What ticket sales and campaign activity were recorded? Ticket sales, email campaigns Separate currency totals and campaign delivery, open and click summaries.

These are analyses the agent can produce from existing endpoints. Creating a file does not create an event, send email, change meetings or publish a dashboard in Brella.

Prompts to copy

Replace bracketed values with your context. Ask the agent to identify unavailable fields instead of requesting unrestricted access.

Conference dashboard and report

Use the Brella Core API skill to create a post-event report for our
conference. Ask for the organization and event IDs if missing. Use only
read requests and the credentials configured in your runtime.

Create event-report.md and, if your tools support it, an interactive HTML
dashboard with event KPIs, a session comparison and networking capacity.
Let me filter sessions by track and sort them by RSVP count or rating.
Show rating sample sizes, data coverage and when the data was retrieved.
Keep missing values distinct from zero and accepted meetings distinct
from completed meetings. Use no invented data or embedded credentials.
Save the files locally; do not publish or send them.

Exhibitor activity report

Use the Brella Core API skill to prepare an exhibitor activity report for
organization [ID], event [ID], sponsor [ID]. Use Read requests only.

Use sponsor-statistics to summarize captured leads, accepted-meeting
activity and tracked booth-page visits. Preserve the API's counting grain.
Include the available leads-by-day breakdown, clearly labelled as recorded
lead captures. Show coverage and explain that these signals are not sales
revenue or verified physical booth attendance.

Create exhibitor-report.md for the sponsor's team. Use aggregate data by
default. Do not infer values hidden by demographic cohort suppression.
If I separately request a contact export, use the lead export workflow
and only permitted fields for this sponsor. Save locally; do not send it.

Networking capacity review

Use the Brella Core API skill to review networking for organization [ID],
event [ID], using networking-timeslot-analytics and Read requests only.

Create an HTML dashboard and networking-review.md. Let me filter by area
and compare timeslots by accepted/pending/draft meeting counts and
meeting-point utilization. Include recorded feedback when available.
Treat no-show counts as rating records, not unique failed meetings.

Identify capacity patterns and questions for the operations team. Do not
infer meeting completion or change bookings. Include a data table,
definitions, retrieval time and missing metrics. Keep credentials out of
the files and save locally.

Compare event editions

Use the Brella Core API skill to compare events [ID, ID, ID] in organization
[ID] with organization-event-benchmarks. Use Read requests only.

Create event-comparison.md with networking-opt-in-rate,
meeting-acceptance-rate and accepted-meetings-per-100-joined-registrants.
Show the returned cohort, median, previous event and absolute/relative
changes. Distinguish percentage points from percent change and counts
per 100. Flag missing values and incompatible metric versions.

Explain differences in audience size, event format and timing only where
the supplied context supports them. Do not invent an industry benchmark
or claim a causal improvement. Save locally.

Plan the next event’s program

Use the Brella Core API skill to review audience-segment-analytics and
interest-demand-analytics for organization [ID], event [ID]. Read only.

Create program-planning.md with audience engagement by ticket type/custom
list and interest/intent demand. Preserve intent labels and net-demand
direction. Explain overlapping segments and distinguish observed demand
from recommendations for sessions or networking formats.

Show source fields, denominators, collection date and unavailable data.
Suggest questions for the program team; do not create sessions, change
lists or claim these observations guarantee demand at the next event.

Set up a reporting token

In API → Organization tokens, add an enabled scope for each required analytics resource. Choose Read, the relevant Event access, Readable fields and permitted query filters. Add only the resources needed for this report; operational access to sessions or sponsors does not automatically grant their separate analytics resources.

For a first conference report, start with:

Primary resource Useful readable fields
Event analytics event-id, name, joined-registrants-count, networking-opt-in-rate, meeting-requests-count, accepted-meetings-count, meeting-acceptance-rate, engaged-registrant-rate
Session analytics event-id, track-id, title, start-time, rsvp-count, checked-in-rsvp-count, ratings-count, average-rating
Networking timeslot analytics, if needed event-id, networking-area-id, start-time, meetings-accepted-count, meeting-points-total-count, meeting-points-used-count, meeting-point-utilization-rate

Also allow metric-version, generated-at and time-zone where available. Use the linked resource references for any additional metrics or filters your chosen prompt needs. For an exhibitor report, a Sponsor statistics scope can restrict rows to specific sponsor IDs.

Configure BRELLA_API_BASE_URL and BRELLA_API_ACCESS_TOKEN in the agent’s trusted runtime. Use the API origin supplied by Brella. Never put the token in a prompt, dashboard source or shared file. See token scopes for the Admin walkthrough.

Collect a complete, dated snapshot

For one event, a record request avoids relying on a collection’s optional event_id filter. Set BRELLA_ORGANIZATION_ID and BRELLA_EVENT_ID to your actual IDs. This reads a single event summary:

curl --fail-with-body --silent --show-error \
  --header "Brella-API-Access-Token: ${BRELLA_API_ACCESS_TOKEN}" \
  --header 'Accept: application/vnd.brella.v4+json' \
  "${BRELLA_API_BASE_URL}/api/core/organizations/${BRELLA_ORGANIZATION_ID}/event-analytics/${BRELLA_EVENT_ID}"

Sessions and networking timeslots are event-level collections. This reads the first page of session metrics:

curl --fail-with-body --silent --show-error --globoff \
  --header "Brella-API-Access-Token: ${BRELLA_API_ACCESS_TOKEN}" \
  --header 'Accept: application/vnd.brella.v4+json' \
  "${BRELLA_API_BASE_URL}/api/core/organizations/${BRELLA_ORGANIZATION_ID}/events/${BRELLA_EVENT_ID}/session-analytics?page[number]=1&page[size]=100"

Continue through meta.total_pages, checking meta.current_page. Deduplicate by event context and JSON:API (type, id). Label interrupted or incomplete reads as partial. If you need track or area names, use the corresponding permitted resource; retain the IDs if names are unavailable.

The token controls returned fields. An omitted field is unavailable, not zero; an ID-only response cannot support the requested KPIs. Optional query filters outside the scope’s allowlist are ignored, so verify returned event IDs, dates and cohort membership. Required filters are always applied; see event comparisons. Do not assume a successful HTTP response proves an optional filter was applied.

Record endpoints, effective filters, event IDs, pages collected, retrieval time and metric metadata. generated-at records response generation, not a guaranteed source-data refresh time. Multiple API requests are separate reads, so a changing event can produce small differences between collections.

Reuse that snapshot when changing charts or report wording. Stay within 500 requests per token per minute and 500 requests per IP per minute, coordinating jobs that share either limit. Respect Retry-After on 429; see rate limits and responses and errors.

Interpret the results

Follow Analytics: interpret metrics for metric definitions, missing values, overlapping populations, event comparisons and the timeline verification caveat. Keep that guide beside the resource field reference when calculating a report.

Package the result

Download the Markdown report template as a starting structure. It is also included in the skill bundle as assets/event-report.md. A useful delivery contains:

  • Report: the question, findings, supporting numbers, recommendations and limitations.
  • Dashboard, if requested: a dated snapshot, clearly labelled charts, useful filters and an accessible data table. Check it at the intended screen size and keep missing values visible.
  • Source notes: endpoints and fields, requested versus observed coverage, pagination, time basis, metric versions and formulas. Retain only the data needed for reproducibility and the intended audience.

Open the files and check totals, chart labels and filters before handing them over. Shared outputs should contain only data that audience is authorized to receive. Respect suppressed sponsor demographic breakdowns; do not reconstruct them from individual records.

A static HTML dashboard can filter and explore its included snapshot without an API token. For automatic refresh, a separately configured trusted backend or scheduled job must hold the token, collect data within both rate limits and publish an appropriately protected output. The skill does not supply that infrastructure. Refresh or publication should happen only when requested and configured; a saved file is not automatically live or shared.

Last updated on September 9, 2026