---
url: "https://questionstar.com/help/integrations/web-services/"
title: "Webhooks and web services — pass survey data in real time"
description: "Per response, at the end of the survey, or conditionally: send data as JSON to your own API. Webhook setup, payload examples, error handling."
lastmod: "2026-07-14"
type: "help"
---

# Web services

Send survey data as JSON to your own API in real time — per response, at survey end, or on a condition. No code.

## 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](/help/survey-settings/end-of-survey)** → 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](/help/publishing/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:

![Set up a web service](/api/media/file/Webservice-einrichten.png)

1. **Target URL (endpoint)** Enter the URL of the web service the data should be sent to.
2. **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.
3. **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/json` if your web service expects a JSON object, e.g.:
> `{ "email": "john@example.com", "score": 5 }`
> Use `x-www-form-urlencoded` if the web service needs simple key-value pairs in the form `email=john@example.com&score=5`.

4. **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.
5. **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"
6. **Remove parameter** – you can add as many parameters as you like, delete existing ones, and reorder them at any time.
7. **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](/help/survey-settings/end-of-survey), quota event, condition for a [notification](/help/publishing/notifications)).

## 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:**
> 
> ```json
> {
>       "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&region=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.