Recommended workflow
1
Find candidate events
Search the event catalog, rank events, or apply profile matching to identify a shortlist.
2
Inspect the event
Fetch the event detail and confirm the event identity, date, venue, source URL, and available data counts.
3
Preview exhibitors or personnel
Call event-scoped list endpoints. If the event is locked, read the
semantics object to understand preview limits.4
Choose and precheck the access layer
Use base event unlock for exhibitor and personnel coverage, visitor unlock after base access, or full-access unlock for both layers. Precheck before each paid action.
1. Search events
2. Fetch event detail
name, dateStart, dateEnd, venue, country, url, and any count fields returned by the API.
3. Preview event-scoped data
semantics to decide whether to unlock base event coverage. semantics.accessMode does not describe the separate Visitor layer, so do not infer Visitor access from pagination or "full" base access alone.
4. Unlock base event access
alreadyUnlocked is true, the event was already available and creditsUsed is 0.
5. Add visitor access or unlock both layers
Visitor access is separate from base event access:POST /external/events/:id/visitors/unlockcosts3000credits and requires base event access, an active subscription, and registered Visitor data for the event.POST /external/events/:id/full-access/unlockatomically charges only for missing layers:2000for base event access plus3000for visitor access.
allowed is true, show the returned credits to the user, and refresh the balance after execution. Read detail.visitor_data_available instead of inferring availability from the event category or list counts. If full-access precheck returns no_contacts_available because Visitor data is unavailable, use base event unlock when exhibitor and personnel coverage is still needed.
Common mistakes
- Unlocking before checking preview results. Preview first to verify the event has relevant records.
- Using only the event name as your local key. Store
idoreventIdso follow-up calls are deterministic. - Treating
402 Payment Requiredas a generic failure. It usually means your integration needs to pause, notify the user, or ask them to add credits. - Ignoring
semantics. It tells you whether a list is in preview mode or has full access. - Calling visitor unlock before base event access. Precheck returns
state_conflictin that state. - Treating base event access and visitor access as the same layer. They have separate access records and credit costs.
- Treating Social Signals as official registration evidence. Only the Visitor label represents registered attendees in the current source taxonomy.
Related endpoints
List events
Browse events with filters and pagination.
Unlock event
Spend credits to access full exhibitor and personnel coverage.
Unlock visitor access
Add visitor records after base event access.
Unlock full access
Atomically unlock missing base and visitor layers.
List event exhibitors
Fetch exhibitors for a selected event.
List event personnel
Fetch people associated with a selected event.
Attendee source types
Map product attendee labels to API
sourceType values.