For Data Lake Teams & Bulk Fetches from ExpoPlatform
This guide is intended for data engineering and data lake teams who need to extract event data from ExpoPlatform in bulk — for example, to feed a data warehouse, BI tool, or analytics pipeline.
This guide covers read-only operations only. All endpoints listed here use the HTTP GET method. No data is written to the platform.
Prerequisite: Make sure you've read Understanding the ExpoPlatform Data Environment before starting. The environment architecture, global vs local field scope, and cascade behaviour described there apply to the data you'll be extracting.
Authentication
All requests require a valid API key passed in the Authorization header:
Authorization: Bearer your_api_key_here
Please confirm your API key and event_id with your assigned ExpoPlatform API Manager before starting.
Available bulk endpoints
|
Endpoint |
Data |
Pagination |
Incremental sync (timestamp) |
|---|---|---|---|
|
|
All participants with full profile data |
Yes — |
Yes — |
|
|
Deleted/detached participants |
Yes — |
Yes — |
|
|
All exhibitors with full profile data |
Yes — |
Yes — |
|
|
Lightweight exhibitor ID map with owner and member account IDs |
No — full map in one response |
No |
|
|
Meeting records with status, participants, timestamps |
Yes — |
Yes — |
|
|
Product category catalogue |
No — full list in one response |
Yes — |
|
|
All halls for the event |
No |
No |
|
|
All stands for a given hall |
No |
No |
Pagination
Shape 1 — page / last_page (participants, exhibitors)
Iterate by incrementing page from 1 until page equals last_page.
Shape 2 — current / next / last (meetings)
Iterate by incrementing page until next is null.
Recommended page sizes
|
Endpoint |
Parameter |
Maximum |
Recommended |
|---|---|---|---|
|
participants list |
|
500 |
200–500 |
|
exhibitors list |
|
300 |
300 |
|
meetings export |
|
500 |
200–500 |
Incremental sync
All major list endpoints support a timestamp (or equivalent) parameter that filters results to records updated after a given Unix timestamp.
Recommended sync pattern
-
Initial load: Full extract without a timestamp filter
-
Store the sync time: Record the Unix timestamp at which the sync started
-
Subsequent runs: Pass the stored timestamp as the filter parameter
-
Update your store: Upsert returned records by their
idfield -
Repeat: Update the stored timestamp and repeat from step 3
Use the timestamp at which your sync job started (not ended) to avoid missing records updated during the run.
Timestamp parameters per endpoint
|
Endpoint |
Parameter |
Format |
|---|---|---|
|
|
|
Unix timestamp (integer seconds) |
|
|
|
Unix timestamp (integer seconds) |
|
|
|
Unix timestamp (integer seconds) |
|
|
|
Unix timestamp (integer seconds) |
Handling deletions
Incremental sync only returns updated records — not deleted ones. Use the dedicated deleted list endpoints.
Deleted participants
GET /api/v2/participants/{eventId}/deletedList?timestamp=1700000000&page=1&per_page=500
There is no equivalent deleted endpoint for exhibitors in V2. Detect exhibitor deletions by comparing the set of IDs returned by GET /api/v2/exhibitor/getList between runs.
Reference data
Fetch once per event setup and cache locally:
|
Endpoint |
Data |
|---|---|
|
|
Product category hierarchy |
|
|
Participant category list |
|
|
Hall list with IDs and names |
|
|
Full country list with ISO codes |
Recommended extraction order
To ensure foreign key relationships can be resolved:
-
Reference data first: categories, participant categories, countries, halls
-
Exhibitors:
GET /api/v2/exhibitors/{eventId}/list -
Participants:
GET /api/v2/participants/{eventId}/list -
Meetings:
GET /api/v2/meetings/export -
Deletions:
GET /api/v2/participants/{eventId}/deletedList