CDS

CDS

CDS is a registration and lead-management platform for events and trade shows, provided by Convention Data Services. It handles attendee registration, badge production, and on-site data capture for large exhibitions across North America. Their website: https://www.cdsreg.com.

What we integrate

• Entities synced: Visitors

• Direction: One-way — CDS is the source, ExpoPlatform receives

• Sync method: Scheduled polling (Auto-Update), every five minutes

The integration fetches registrations from CDS and creates or updates the corresponding visitor records in ExpoPlatform. It supports both new registrations and updates to existing ones — including changes to a registrant's registration class.

Prerequisites

To set up the CDS integration, you'll need:

• A CDS API key (AuthKey) — provided by the CDS account team for your event

• The registration class codes (RegClass) for the categories you want to sync (e.g. VIS for visitors, SPK for speakers)

The CDS API endpoint is fixed — no host configuration is required.

How to set up the CDS integration

The setup can be done by a client with superadmin access, or by the ExpoPlatform API team on the client's behalf.

1. Configure credentials

1. Go to Admin → Integrations → CDS

2. Open the Credentials tab

3. Enter the CDS AuthKey provided by the CDS account team

4. Save

2. Configure visitor settings

Open the Visitor Settings tab. This is where the shared settings for CDS are configured:

• Identity Matching — CDS matches visitors by email address only. No other option is available for this integration.

• Initial Account Status — the ExpoPlatform account status assigned when a visitor is first imported.

• Registration Email — whether to send an ExpoPlatform welcome email on first registration.

• Category Mapping — map CDS registration class codes to ExpoPlatform visitor categories. Important: on CDS, the mapping also scopes what gets fetched — only mapped registration classes are requested from the CDS API. A class not in the mapping is never even retrieved. If the mapping is empty, the sync refuses to start.

Two CDS-specific parameters appear alongside the shared settings:

• Order Type — selects which CDS record types to request. Options: 0 - Visitors, 1 - Exhibitors, 2 - Both (default). The default includes team-member records alongside visitors. Change only if you need to narrow the fetch.

• Include Items — when checked, asks CDS to include item-level data in each response record. Default is off. Typically left off; enabling it makes responses larger without changing how records are processed.

Neither option affects identity matching, category mapping, or any downstream behaviour.

3. Configure field mapping

Open the Field Mapping tab and review the default mapping (documented on the CDS Visitor Field Mapping sub-page). Adjust or extend it as needed.

Only the fields present in the active mapping are requested from CDS — everything else is ignored.

4. Trigger the first sync

Once credentials, settings, and mapping are in place:

1. Open the Auto Sync tab

2. Click Trigger a full resync on the visitor subscription card

This runs the initial import — fetching every matching registration from CDS and creating the corresponding ExpoPlatform visitors. From this point on, the scheduler runs incremental syncs every five minutes.

What to expect

Each polling run pages through the CDS registration list in batches of 500 records. All pages must be retrieved before the run is considered complete.

• Full resync on a large event can take several minutes depending on registration volume

• Incremental runs (every five minutes after the first successful sync) fetch only registrations created or updated since the previous run — typically much faster

• An update to an existing registration — including a registrant being re-classed into a synced registration class — puts the record back inside the next incremental window; no full resync needed

Progress is visible in the Auto Sync tab: the Current Sync Job panel tracks the run live, and the sync history lists one row per job. See Monitoring a Sync for the full picture.

Fetching updates — how it works

CDS supports "modified since" queries, so every incremental run asks CDS for registrations created or updated since the previous run's start time.

• The stored marker is EP's clock (UTC), and the CDS filter parameter is also UTC — no timezone configuration is needed

• Consecutive runs overlap slightly by the previous run's duration, so nothing falls between them; unchanged re-fetches are skipped automatically

• An incremental run that finds nothing still advances the marker to its own start time

• A failed run leaves the marker untouched — the next run re-covers everything since the last success

Do not be misled by CDS timestamps inside records. CDS returns timestamp fields (LastUpdate, Modified_TS, UpdateDate) in the event's local time, while the sync boundary filter is UTC. Records showing local timestamps that look shifted against the sync window are expected — the filter operates on UTC values, not on the display fields.

Identity matching: email-only

CDS records don't carry a stable external ID that persists across sync runs. Visitors are matched solely by email address.

If two registrations from different batches share the same email address, the second record will update the first rather than create a new visitor. There's no skip result or warning logged for this. Verify that registration data in CDS uses unique emails per attendee.

Known limitations

• Email-only identity matching means visitors cannot be reliably de-duplicated if CDS contains duplicate email addresses

• No real-time push — CDS updates appear only after the next scheduled polling run (up to five minutes' delay)

• A full resync retrieves all pages before results are complete; a run interrupted partway may not process some pages until the next scheduled run

• The CDS API endpoint is fixed — if CDS changes their API address, a code deployment is required

• The CDS API returns HTTP 200 even for error conditions — Success: false in the response body indicates an API-level error. This appears in the Logs → Requests sub-tab with the error detail from CDS.

Monitoring

• Sync run status and counts: Admin → Integrations → CDS → Auto Sync tab

• Per-record outcomes: Admin → Integrations → CDS → Logs → Visitors

• CDS API errors and rate-limit responses: Admin → Integrations → CDS → Logs → Requests

• Scheduler and lifecycle events: Admin → Integrations → CDS → Logs → System

See Reading Logs for how to use each sub-tab.

Troubleshooting quick reference

See Troubleshooting for the full symptom-based diagnostics guide.

Sub-pages

• CDS Visitor Field Mapping — the default field mapping plus the CDS-specific External QR composite field