URL parameters allow users to configure apps to pass identification and authorization data for attendees via query string variables. This is a simple way to integrate attendee information from another data source, like an event app, to save attendees from having to enter duplicate information.


How it works

This functionality works through a querystring in the URL for an app. For example:


The first part of the querystring, “identify”, tells Conferences i/o to initiate the URL identification routine. Subsequent variables are mapped to the user object that exists in Conferences i/o. A full list of URL parameters is available below, and can be used to do things like pass a shared App or Moderation password.


After the identification routine runs, the URL is reloaded without the querystring, meaning that the querystring will not remain visible to the attendee.


Default identification and authorization parameters

Note: All of the following parameters are optional.

NameMaps to attendee name field
first_nameFirst Name (a default field)
last_nameLast Name (a default field)
emailEmail Address (a default field)
name (legacy)Legacy attribute. Will be mapped and duplicated into first name and last name fields.
field1Maps to attendee custom field #1
field2 Maps to attendee custom field #2
field3 Maps to attendee custom field #3
field4Maps to attendee custom field #4
field5 Maps to attendee custom field #5

app_passwordIf your app uses an App Password, you can submit it here so that the Attendee does not have to enter it.
moderator_passwordWill authenticate attendee as a moderator. URL must point to a Session.
admin_passwordWill authenticate attendee as an administrator.
cnf_idA unique identifier for an attendee. ( See the section on this below for more information.)


How does Conferences i/o know what “field1”, “field2”, etc, are?


These fields are the “Attendee Required Fields” which are editable in the administration area of your App. If you’ve defined Attendee Required Field #1 as “Member ID”, and you pass an attendee’s member ID value as field1 in the identification querystring, Conferences i/o will map that value and provide it under the appropriate heading in any reporting.



Additional parameters, and customized data


In some cases, you may not be able to customize the field names passed to Conferences i/o, or you may want more fields available in data exporting. Any additional parameters passed via URL will also be mapped to the user object in Conferences i/o, and can be made available to data exporting. The specific fields  referenced above are,  however, the only ones that can be mapped to Conferences i/o’s Attendee Required Fields.



Customized user identifiers


The cnf_id field available as a URL parameter does more than just pass a private user identifier, it also makes it possible to authenticate to a particular user profile. In a more advanced use case, multiple attendees may be using the same device, or the same attendee using multiple devices. When passing a cnf_id parameter as part of the identification routine (in the URL), Conferences i/o will recognize this and assign that profile to the attendee when they join.


This functionality may raise concerns when using identifiers that expose business logic (such as incrementing numbers). Conferences i/o recommends using universally unique identifiers (UUID) or hashed identifiers when passing cnf_id via URL.



Can this data be spoofed?


Yes. Because there is no signing request, someone could spoof identification data by altering the querystring variables. If security is important to our organization, we recommend using one of our more secure approaches to authorizing and identifying users. Please contact for more information about these alternatives.

Bypassing check-in confirmation with the auto_checkin parameter

To bypass check-in confirmation, add auto_checkin as a URL parameter to any session URL. 

For example:

In the above URL, we are passing along identifying information about the learner as URL parameters, and then we're appending the auto_checkin parameter to trigger the check-in bypass.

What are the requirements for bypassing to work?

auto_checkin only works when all of these are true:

  • Standard check-in mode is being used.
  • Check-in is required for the session.
  • The session does not have a check-in code.
  • All required information fields for the learner have data.

What happens if the requirements aren't met?

If standard check-in mode is not enabled, or if check-in is not required for the session, no check-in will be created.

If any of the required fields are missing or empty (blank), or if the session has a check-in code, then the learner will be brought to the confirmation screen.

For example, in this URL you will see that the last_name parameter has been left empty:

(Note that you may need to paste that link into a private browsing window to see the intended outcome.) 

What happens if a learner is already checked in?

If a learner is already checked into the session you've linked to, auto_checkin is ignored. The learner simply returns to the session dashboard.

In practice, when would I want to use the auto_checkin URL parameter?

If you're embedding Conferences i/o into your own application or service, you might use auto_checkin to save learners the hassle of confirming their information.

Bypassing check-out confirmation with the auto_checkout parameter

Check-out confirmation can also be bypassed via the URL, though this is not required and the practical use case of this is less common.

Note that this only works if an attendee is already checked-in to a session, and if there's no checkout code for the session. (It won't create a check-in and then immediately check-out that learner.)

The URL structure for check-out looks like this:

After check-out, the attendee will be returned to the session dashboard. There is currently no way to alter the direction they end up going.