Web services
About integrating QUESTIONSTAR with web services
With web services, you can connect your surveys to other systems and trigger automated processes. QUESTIONSTAR lets you launch web service calls directly from the questionnaire — without any programming. This means data can be transferred to external systems in real time, or specific actions can be triggered automatically.
A web service can be called in the following situations:
- After the survey is completed → Ideal for automated follow-up: for example, creating an entry in a CRM system, unlocking a bonus, or sending a voucher by email.
- When a quota is reached or on screenout → Perfect for informing external systems directly during quota control — for instance to redirect into other panels, for incentive logic, or to manage campaigns.
- As part of Notifications about certain events → This allows processes to be triggered automatically in the background, for example on a specific answer or score — such as opening a support ticket, sending an alert, or starting a workflow in a marketing automation tool.
Typical use cases from everyday business:
- A lead fills out a short qualification questionnaire — the data is sent straight to your CRM system.
- A customer rates support negatively — a task is automatically created in the ticketing system.
- An internal training survey shows a knowledge level < 70% — a reminder for follow-up training is sent automatically.
- After successful participation in a campaign — a voucher is automatically generated and sent.
With the web service feature in QUESTIONSTAR, scenarios like these can be handled elegantly and automatically. In this article, we'll show you how to configure web service calls and put them to good use.
Configuring a web service call
When setting up a web service call in QUESTIONSTAR, you can define the following settings:

- Target URL (endpoint) Enter the URL of the web service the data should be sent to.
Request method Choose which HTTP method should be used to transmit the parameters to the endpoint. The available methods are:
- GET – parameters are passed in the URL. Suitable, for example, for simple tracking purposes or calls where no sensitive data is transmitted.
- POST – parameters are transmitted in the request body. Suitable for structured data transfers, e.g. for passing answers or customer data.
- PUT – usually used to update existing resources.
Request type (content type) If you use POST or PUT, you can additionally specify the format in which the data is sent:
application/json– parameters are passed as a JSON object. Ideal for modern APIs that expect structured data.application/x-www-form-urlencoded– the classic web form format. Frequently used with older or simpler APIs.Tip: Use
application/jsonif your web service expects a JSON object, e.g.:{ "email": "john@example.com", "score": 5 }
Usex-www-form-urlencodedif the web service needs simple key-value pairs in the formemail=john@example.com&score=5.
Add Query Parameter Add a separate parameter for each piece of information you want to send to the web service. For each parameter, you define:
- Parameter Name – i.e. the name your web service expects.
- Value source – i.e. where the parameter value should come from.
- Value – which value is sent (statically definable or dynamically selectable, depending on the value source).
The following options are available as sources for parameter values:
- Text – for static values such as fixed survey identifiers, campaign IDs, or API tokens (be careful with GET, since tokens are transmitted in visible form!).
- Answer to a question – to pass a specific respondent answer to the web service.
- Custom variable – for example, a calculated scale or a score from a psychological test (e.g. "BurnoutIndex", "TeamFitScore").
- A/B test version – the version (A, B, C, …) that a respondent received in the A/B test. Helpful for analyzing test effects.
- URL parameter – values that were passed via the URL when the questionnaire was opened (e.g. respondent ID, campaign, tracking code).
- Contact List Field – e.g. last name, first name, email address, or individual fields such as department, region, customer status, etc.
Send answers as – for parameters of the type "Answer to a question", you can specify how the answers are transmitted:
- Coded values (default) – e.g. 5 for "Very satisfied"
- Text values – e.g. "Very satisfied"
- Remove parameter – you can add as many parameters as you like, delete existing ones, and reorder them at any time.
- Save – Click "Save" to save the web service call. The web service is then called automatically on the corresponding event (e.g. end of survey, quota event, condition for a notification).
Sending answers as JSON or as form data — what's the difference?
When you send POST or PUT requests via web services, QUESTIONSTAR gives you a choice of the format in which the data is transmitted. You make this choice via the so-called request type (content type):
1. application/json
The data is sent as a structured JSON block — this is the modern standard for most web APIs. Ideal when your target system (e.g. an internal tool or a cloud service) understands JSON and expects cleanly structured data.
Example:
{
"email": "jane.doe@example.com",
"score": 7,
"region": "Nord"
}✅ Advantages:
- Very readable and easy to structure
- Ideal for systems with more complex data structures
- Less prone to errors during processing
🔧 Typical uses:
- RESTful APIs
- Integration into internal tools or middleware
- Passing complete data sets
2. application/x-www-form-urlencoded
The data is sent as classic key-value pairs in a URL-encoded form — as with HTML forms. This format is compatible with almost all systems, including older or simple APIs.
Example:email=jane.doe%40example.com&score=7®ion=Nord
✅ Advantages:
- Broad compatibility with many web services
- Well suited for simple parameter transfers
🔧 Typical uses:
- Connecting to older web services
- Systems that expect form processing
- Simple integrations without structured data
When to use which format?
| Situation | Recommendation |
|---|---|
| Your web service uses modern REST standards | JSON |
| You are transmitting several structured data objects | JSON |
| You are integrating an older or external system | Form data |
| The web service expects data as from an HTML form | Form data |
Tip: If you're unsure which format your web service needs, check the technical documentation of the target system or test both formats — QUESTIONSTAR supports both flexibly.