We’re excited to bring you a guest post from the event mobile app experts at TripBuilder Media. They’ve created a helpful guide to event app integration terms that will simplify potentially confusing jargon. If you’re interested in learning more about finding the ideal event mobile solution for your event, be sure to check out the webinar we’re hosting with TripBuilder Media later this month. Details and registration can be found here.

Information in a third-party database—posters, schedules, attendees, exhibitors and more—can easily be integrated into your event app. There are several reasons why you’d want to do this, such as if you have an extreme amount of data or if you have data that changes very frequently. With integration, you have a single source of data and you don’t have to double enter information into the event app content management system. Integration saves you time!

How does integrating with your event app work? We build a “bridge” between your event app’s database and your third-party database (whether it be an abstract management company, registration company or any other database) to pull in data from specific modules. We also set up a periodic check for updates so any new information or changes the end user makes in the third-party database are automatically reflected in the app.

When you’re integrating your event app with your other databases, you may run into some potentially confusing jargon. Here are ten terms you may hear and what they mean in plain English:

1. API: An API (Application Programming Interface) allows communication between two or more platforms to transfer specific pieces of information. In the mobile event app world, this allows important pieces of data such as schedules, attendee profiles, etc. to be made available to 3rd parties.
2. Cron Job: An automated procedure used to periodically check the database and pick up updates at a designated interval of time.
3. Web Services: Allows the exchange of data over the internet from different applications and sources.
4. XML, JSON and REST: The three different formats that a web service can send data in. Each format is sending the same data but some vendors have a preferred format.
5. Table: A table is a set of data made up of specific fields. For example, you may have a Table for your session data. The fields that make up that Table may be, “Session Name”, “Session Time”, etc.
6. Field Mapping: Each database will have different fields with different field names. It is important to understand how each field is structured and named to appropriately pull the data to the correct place.
7. Database Call: To pull data and updates, the receiver makes a “call” to the host database to retrieve information.
8. Deletion Flag: A deletion flag is used to tell the receiving database that a record (such as a session) should no longer be active. Instead of completely removing the record form the original database, a deletion flag should be sent.
9. Unique ID: Every record in a database, whether it is a session or attendee, has a unique identifier to prevent duplicates. This is particularly necessary when, for example, two attendees have the same name or there are multiple versions of the same session.
10. Show Code/Event ID: This typically comes into play when you have more than one event’s data stored in the same database. The Show Code or Event ID allows you to pull in the data only related to one specific event.

Want to learn more about event tech integration? You wont' want to miss Hubb's handy Integration Cheat Sheet!