This page contains the setup guide and reference information for the Visit by GES integrations.

This integration is part of Free, Starter, Professional, Enterprise subscription. Contact your Account Manager for more information.

Your Visit event has been successfully linked with your Swapcard event.

You have the flexibility to adjust your integration settings according to the specific data requirements. It's crucial to highlight that the synchronization will only begin when you manually start the integration process and finish the necessary mapping.

The Visit by GES integration supports the following sync modes :

Visit manages incremental synchronization through a Revision mechanism. This mechanism is stateful, requiring Swapcard to keep track of the previously returned revision to retrieve newly created or updated records in Visit.

In a stateful revision mechanism, Swapcard must maintain awareness of the revision number from the last successful synchronization. This enables the integration to request records created or updated since the last synchronization date.

Common integration practices often adopt a time-based approach, where all records created or updated based on the last successful synchronization date are requested. However, Visit's API restrictions may result in certain records being overlooked during incremental sync.

In case of discrepancies between Visit and Swapcard, it is advisable to perform a Full Refresh - Overwrite. This ensures a comprehensive synchronization, addressing any potential gaps in the incremental sync process.

This integration is supporting the following Visit by GES streams

The Visit by GES integration does NOT capture deletions for records in the Visitors, Partners streams.

When a record is deleted on Visit, it needs to be MANUALY deleted on Swapcard accordingly.

The list of available objects for mapping in the Visit by GES integration is generated through various streams.

As the Vist by GES JSON API does not support the retrieval of Registration Types at Event Level and returning all the Registration Types, as recommanded by Visit GES the Swapcard integration employs a combination of the n200 legacy XML API and the Visit JSON API endpoint.

For each Registration Types XML of types visitor and partner, the Swapcard integration creates the appropriate objects to be mapped.

In the context of integration functionalities, records are automatically linked with their corresponding records within Swapcard. For instance, if Visitors are associated with Partners on Visit, the integration will replicate these dependencies within Swapcard.

The Visit by GES integration automatically links the Visitors from Visit by GES with their respective Partners from Visit by GES.

The integration utilizes the partner.id field from the Visitors stream.

The id of Partners is employed as the main identifier to uniquely link records and store them within the Client Id field on the Swapcard side.

The visitConnectURL field is frequently employed by customers to grant direct access to Vist by GES badges. To facilitate seamless integration in embedded mode, Swapcard automatically includes embedded=true query parameters for proper embedding.

The questions field in the Visitors section serves as a means for Swapcard integration to implement a custom fields approach. This is commonly used to fetch registration form inquiries.

The mapping of questions between the answers in the Visitors section and the questions in the Event section relies on the name of the questions. Unfortunately, this method is susceptible to mismatches. Regrettably, Visit by GES currently lacks a unique identifier for questions.

The Visit by GES integration is designed to operate smoothly within typical usage scenarios and should generally not encounter limitations imposed by the Visit by GES API. However, its functionality is dependent on the capabilities of the Visit by GES API. If you encounter rate limits issues, kindly contact the Visit by GES support team for assistance.

Integration with Visit by GES is subject to limitations imposed by the provider's API when it comes to incremental updates. For more details, please consult the Managing Incremental Sync in Visit by GES section.

The recently developed Visit by GES API lacks support for Registration Types, as indicated in Object Mappings, which may result in potential challenges when attempting to retrieve registration uniform types.

Please be aware that any enhancements to this integration, which encompass any requirements not covered by the existing integration state, will be subject to custom development processes and associated costs.