Upcoming feature and API change: Questionnaires

Today, we'd like to share some great news with you about an upcoming feature that we have been working on for a while.

Usually, we only share news about features when they are fully ready and available, but this time is different: We are unfortunately not able to roll out the change without a disruption to users of our API since the new feature requires a significant change to our data model. We know that breaking changes to the API are quite disruptive and we try to avoid them as much as possible.

We are currently planning the change to roll out on 8 December 2026 (late evening). Should this date change, we will update this blog post.

What we are building

pretix includes a feature called "Questions" that allows to create customized fields. These fields will then be shown during ticket purchase or ticket scanning for the user to fill out. Additionally, pretix provides a feature of "personalized tickets" that causes the system to ask for attendee names, email addresses, company names, or addresses. Questions are a powerful tool already, but we are reworking them to become so much more:

• Additionally to questions asked for every ticket, you will be able to ask questions only once for the entire order. This is useful e.g. for statistical information you do not want to ask your group customers multiple times.

• You will be able to create groups of questions that you can then assign to products. These will be called "questionnaires" and make life a lot easier when dealing with large numbers of products.

• You will be able to make the same question required or optional in different questionnaires. This way, you could e.g. make the "company" field a required field for all buyers of your Business ticket and optional for everyone else. Still, it remains one field to include in a badge layout or export!

• You will be able to customize the label and text of questions based on the questionnaire, which again is based on the purchased product. In the same way, you will be able to customize labels of system-provided questions like name or email address.

• You will be able to ask for partial attendee addresses, such as only zip code and country with no street.

• You will be able to insert blocks of explanatory text between questions.

• You will be able to ask questions only on specific sales channels.

And this is only the beginning!

What is changing

In a nutshell, the system will change like this:

• What is currently a "question" will become a "data field". In itself, a data field is not visible to your customers, it only specifies what type of data can be stored in the field and where it is shown.

• Data fields will exist both for each order position as well as for orders as a whole.

• A new concept "Questionnaire" is introduced. A questionnaire controls what is actually presented to your users and how. Each questionnaire consists of a set of rows, that can (a) reference a user-defined data field (b) reference a system-provided field or (c) contain static explanatory text. Questionnaires are mapped to sales channels and products.

Who is affected

Your API usage will no longer work if you do one of the following things:

• Create and modify questions through the API. This will no longer work and you will need to use the new APIs.

  The API for retrieving questions will continue to work as long as you do not utilize the new features. If you configure questionnaires that are incompatible with the old data model, the compatibility API endpoints will stop working.

• Rely on the event settings API to read or change attendee_*_asked and attendee_*_required properties -- these will no longer exist.

• Rely on the personalized attribute of products behaving exactly as before: this will no longer be a real field, but return synthetic values (see below). It's default changes to false.

• Rely on the order position resource to not contain additional objects in the answers key. The compatibility layer will return additional answer objects with artificial id values for the system data fields, as well as for data fields referenced in multiple questionnaires.

We expect this to affect only a small number of customers only for non-business critical processes. If in doubt, please contact us.

Who is not affected

All existing questions will automatically be transformed into data fields and questionnaires will automatically be created to match your current behavior. The API will provide a compatibility layer that translates between the old and new concepts as much as possible.

Specifically:

• pretixSCAN and pretixPOS stay fully functional without an app update. To be able to use all new features, you will need to upgrade to new versions of pretixSCAN and pretixPOS first, which will be published before the rollout date.

• The API for checking in a ticket will not change in backwards-incompatible ways, except for the id values of the returned questions.

• The API for creating orders will not change in backwards-incompatible ways.

• The API for retrieving order positions will not change in backwards-incompatible ways. Both existing question id values as well as id values generated by the compatibility layer will be accepted.

• The API for managing question options will move to a new URL but the old URL will remain available for a while.

How you can prepare

If you use our API, please review if you are using any of the deprecated APIs and are affected by the changes. If you are, please prepare for these changes going into effect on the date specified above. Depending on the criticality of your API usage, this might mean preparing a change of your code based on our new documentation on the same day or any time after. If you need assistance testing your changes, please reach out to us.

API changes in detail

We have already updated our API documentation to include the upcoming changes. Due to the changes in our data model, we have to remove or deprecate some aspects of the existing API.

Data fields New resource

API documentation

In database terminology, in a "table" of orders or order positions, data fields are additional "columns" you can add to the table, allowing additional data to be stored per-order or per-position, in a structured form. They can be filled in by the customer if referenced from a questionnaire, or filled in programmatically.

Data fields are the successor of questions, each question is automatically migrated to a per-ticket data field.

• Different from questions, data fields are not directly customer-facing, and are not attached to products (they don't have the question, help_text, or items fields questions had).
• Same as with questions, you configure the data type (e.g. text, number, date/time, or a choice between multiple options), and optional value restrictions (e.g. maximum length of text).

Questionnaires New resource

API documentation

Questionnaires connect data fields with products and orders. Each questionnaire has a type, specifying whether it's per-order or per-ticket and at which point of the order lifecycle it's asked (before or after purchase, during check-in at the venue). It also has a list of items, connecting it to the products for which its questions are asked. A list of objects in the rows field configures which questions to ask, where to store the answers, and more.

Items (also known as products)

API documentation

• Compatible in most configurations The personalized field is deprecated.
  
  Personalization is now configured by attaching a questionnaire asking for the relevant information to the product. For example, you can use the "Attendee data" questionnaire that is created by default on new events.
  
  For compatibility with existing applications:
  

  • setting the field when creating a new product will attach the Compatibility Personalization Questionnaire to the new product.
  • when reading a product, it is reported as true if any attached questionnaire asks for attendee_name and/or attendee_email.
  • when updating a product, the field cannot be changed.

• New attribute Items get a new optional questionnaires attribute, which is a list of the IDs of all attached questionnaires.

The Compatibility Personalization Questionnaire is a questionnaire with a special internal flag that is created automatically when creating a new event, when creating a product with personalized = true, and in some cases during the migration.

Questions Breaking changes

API documentation

The questions resource becomes read-only and is deprecated altogether. The read-only endpoints are only provided for compatibility with existing applications and should not be used in new development. New applications must use the data fields and questionnaires resources.

It only supports per-ticket questions. Per-order questions can only be retrieved using the new API.

This resource will only work on events where the questionnaire configuration is compatible with the old data model. If incompatible configuration is detected, these endpoints return HTTP 410. Examples for incompatible configuration are:

• Referencing the same data field in multiple questionnaires with different labels, help texts, required statuses or question dependencies.
• Multiple questionnaires containing the same data fields in different order.
• Referencing a data field in two questionnaires, one of which is asked on purchase, the other asked on check-in.

Question options Compatible change

API documentation

The question options resource is renamed to data field options. Old endpoint names are deprecated, but will continue working for the time being.

For managing options on per-order data fields, use the following resource:

/api/v1/organizers/(organizer)/events/(event)/datafields/order/(datafield-identifier)/options/

For managing options on per-ticket data fields, use the following resource:

/api/v1/organizers/(organizer)/events/(event)/datafields/position/(datafield-identifier)/options/