Skip to main content

Changelog

The GraphQL schema changelog is a list of recent and upcoming changes to our GraphQL API schema. It includes backwards-compatible changes, schema previews, and upcoming breaking changes.

Breaking changes include changes that will break existing queries or could affect the runtime behavior of clients. For a list of breaking changes and when they will occur, see our breaking changes labels.

Changes for 2024-10-16​

The phone numbers should be specified according to the E.164 number formatting (http://en.wikipedia.org/wiki/E.164) recommendation and should be prefixed with a +. For example, to verify the US phone number 415 555 0101, the phone number should be specified as +14155550101. The + is the required prefix and the US country code 1 prepended to the local subscriber number.

Reminder deprecated fields 2024-10-06​

Old deprecated Fields​

The following fields have been deprecated since few year/months and should be removed from your current GraphQL queries:

  • tags (Event Person): Replaced with a custom solution using the fields attribute.
  • secondJobTitle (Event Person): Use the main jobTitle field or create a custom field if necessary.
  • engagementScore (Event Person): Updated to withEvent.engagementScore to provide event-specific data.
  • attendeeOnPlannings (Event Person): Updated to withEvent.attendeeOnPlannings.
  • attendees (Plannings): Updated to withEvent.attendees.
  • booth (Exhibitor): Updated to withEvent.booth.
  • group (Group): Updated to withEvent.group.
  • advertisements (Exhibitor): Updated to withEvent.advertisements.
  • analytics (Event): Deprecated and replaced by the Analytics Export API.
  • imageUrl (AdvertisementRedirectUrl & AdvertisementExhibitor): Replaced with webImageUrl.

Recommendations​

Switch to Webhooks: Replace frequent lookup queries with webhooks for eventPerson, exhibitor, and plannings data to optimize performance and reduce API usage.

Changes for 2024-09-15​

Limitations have been updated, GraphQL APIs now has a cost and a query based limit, effective November. More info on the Limitations page.

Changes for 2024-07-01​

Several fields in our Analytics API available through the Content API are being deprecated and will be removed by the end of July. To ensure continued access to the required information, please use the Content API with the specific IDs mentioned below.


Analytics_Users
|- eventPerson @deprecated(reason: "Use Content API with eventPersonId to find the record.")

Analytics_SponsorShowArray
|- sponsor @deprecated(reason: "Use Content API with sponsorId to find the record.")

Analytics_Plannings
|- planning @deprecated(reason: "Use Content API with planningId to find the record.")

Analytics_Exhibitors
|- exhibitor @deprecated(reason: "Use Content API with exhibitorId to find the record.")

Analytics_EventViewShowArray
|- eventView @deprecated(reason: "Use Content API with eventViewId to find the record.")

Analytics_DocumentOpenArray
|- document @deprecated(reason: "Use Content API with documentId to find the record.")

Please update your integrations to fetch the necessary information using the Content API by the end of July. This change will enhance the efficiency and accuracy of data retrieval.

Changes for 2024-04-22​

The eventViews query will be discontinued on July 1, 2024, to improve performance and consistency.

You can now access the views via the listEventViews field in the Event type.

query EventViews($eventId: ID!) {
	event(id: $eventId) {
		id
		listEventViews {
			nodes {
				__typename
				... on EventViewInterface {
					id
					name
				}
			}
		}
	}
}

Changes for 2024-02-13​

The notifications query was removed on 18 July 2023 to enhance the performance and consistency of the Push Notification module. It has since been replaced by a new field, pushNotifications, in the Event type.

Example can be found here

Changes for 2024-01-10​

On the GraphQL mutation createProduct, we added an argument translations to add the ability to translate product name in any language. link to example

Changes for 2023-10-06​

On the GraphQL type Speaker, we added a link to the CommunityProfile and EventProfile of the speaker.

speakers {
  communityProfile {
    id
    ...
  }
  withEvent(eventId: ID!) {
    eventProfile {
      id
      ...
    }
  }
}

Changes for 2023-10-05​

Registration data is now available in People queries and mutations. The eventPerson query, the eventPeople query, and the importEventPeople mutation have a new node for registration.

Using the queries, you can retrieve details about each person that is registered as well as details regarding their ticket. Additionaly, you can filter the eventPerson by registeredAt and registrationStatus (Registered or Canceled).

When creating or updating a person using the importEventPeople mutation the registration status and ticket may be set. Tickets that have reached capacity will not be able to be set, but tickets that are before or after their valid dates will be allowed via the API. Setting the registration status also has limitations.

  • If there is no status it may be set to REGISTERED as long as a ticket is also provided.
  • If the status is already REGISTERED it may be changed to CANCELED, but may not be removed (set to blank).
  • If the status is already CANCELED it may be changed to REGISTERED as long as the assigned ticket is not at capacity.

Variables​

{
  "eventId": "RXZlbnRfMQ==",
  "filters": {
    "confirmationCode": ["regCode", "regCode2"],
    "registeredAt": "2023-08-24 12:30:00"
  }
}

Query​

query ListEventPeople($eventId: ID!, $filters: [ListEventPeopleFilter!]) {
  eventPeople(eventId: $eventId, filters: $filters) {
    __typename
    nodes {
      firstName
      registration {
        ticketType {
          id
          name
          quantity
          ticketsSold
          priceCentsFormated
        }
        registeredAt
        confirmationCode
      }
    }
  }
}

Changes for 2023-07-26​

Limitations of the GraphQL Content API changed, we refined cost based usage and added call based usage.

More info on the Limitations page.

Changes for 2023-07-25​

Introduce a new feature: the ability to filter meetings based on their last updated date.

Variables​

{
  "eventId": "RXZlbnDY1Nc4",
  "filters": {
    "status": ["PAST", "EXPIRED"],
    "lastUpdatedSince": "2023-07-24 10:10:11"
  }
}

Query​

query Meetings(
  $eventId: String!
  $filters: [MeetingFilterInput!]
  $page: Int = 1
  $pageSize: Int = 10
  $search: String
  $sort: [MeetingSortInput!]
) {
  meetings(
    eventId: $eventId
    filters: $filters
    page: $page
    pageSize: $pageSize
    search: $search
    sort: $sort
  ) {
    nodes {
      id
      status
      slot {
        id
      }
      location {
        id
        name
      }
      participants {
        id
      }
    }
    pageInfo {
      currentPage
      lastPage
      totalItems
    }
  }
}

Changes for 2023-07-20​

  • The importEventPeople & updateEventPerson mutations in the API now enforce non-empty values for the firstName and lastName fields, rejecting requests with empty values for these fields.
    • FIELD_EMPTY is reported in case empty values is provided

In the API, both the first and last names now undergo a trim operation, which means any input containing only empty spaces will be treated as empty.

Changes for 2023-06-23​

A new boolean parameter force have been introduced on importEventPeople. When set to true, this boolean will bypass the security checks of type CLIENT_ID_CONFLICT.

When the import is forced, it will allow:

  • Switching User from Community Profile; an Email is associated to a User, a User to a Community Profile and Client ID to a Community Profile. By default, we ensure that the pair (Email, Client ID) matches. We check that the User associated to the Email matches the User of the Community Profile retrieved by the Client ID. When the import is “forced”, we bypass this validation check which allows to switch any User from the Community Profile retrieved by the Client ID.
  • Using more than one Client ID per Community Profile; by default, we ensure that the same Client ID is used when referring to one User ’s Community Profile. When the import is “forced”, we allow the usage of several Client IDs per Community Profile. When the Client ID does not exist we add it. Note all Client ID should be unique inside the community.

When forcing import ?

  • Your Swapcard’s community is new, and no event already took place.
  • [OR] The people you are importing are new to Swapcard (ie. they do not already have an account).
  • [OR] You do not want to ensure people keeping their data (contacts, bookmarks, meetings, profile data, …) from previous events.
  • [AND] You do not have multiple events happening on the same time within your community. When NOT forcing import ?
  • You have several events running at the same time within your community.
  • [OR] Some users already have an account within your community and you want to ensure that they keep their data (contacts, bookmarks, meetings, profile data, …) from previous events.

Changes for 2022-11-04​

New error messages have been added on several mutations including (importEventPeople & upsertEventExhibitors), aiming to relace generic error message An internal error occured, please try again or report this error with this code: 35b5b68b-ce4f-4f1e-b60a-11ab3584d159 by the following.

  • BAD_INPUT: The field definition ID is not valid.
  • BAD_INPUT: This field definition requires the field "choices".
  • BAD_INPUT: This field definition requires the field "number".
  • BAD_INPUT: This field definition requires the field "date".
  • BAD_INPUT: This field definition requires the field "text".
  • BAD_INPUT: This field definition requires the field "texts".
  • BAD_INPUT: This field definition is not valid in this context. Error returned in case the field definition is for another entity type.

Changes for 2022-11-03​

P99 latency has been improved on upsertEventExhibitors mutation passing from ~18s to less than 1s execution time on multiple entities payload. The mutation doesn't lock the event anymore and can be used in a concurrency manner. Atomicity in the operation is preserved.

Schema Changes for 2022-09-19​

⚠️ Unique profile at Community level - Impact on clientId field for people​

The clientId is the unique identifier for the profile coming from the customer side. A profile is now unique at Community level.

Consequently, a clientID should be unique for a whole community, on all events. When importing people into Swapcard, it is mandatory to provide a clientId that is unique in the community, acting as a unique identifier of a person.