Bulk Data Extraction — Guide for Data Lake Teams
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.
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