HTTP Element

HTTP request sends data to external services or offers. Each request defines:

• Name – the identifier of the request, used for reference in other parts of the integration.
• Method – the HTTP method (e.g. GET, POST, PUT, PATCH, DELETE).
• Cascade type – a special setting for Offer Cascade that defines the request’s role in the flow.
• Endpoint – the target API URL where the request is sent.
• Format – the data format of the request body or parameters (e.g. JSON, form-data, x-www-form-urlencoded).

Method

The method defines how data is sent and must match what the third-party API expects.

⚠️ A common mistake is selecting the wrong method: even with the correct URL, a GET instead of a POST (or vice versa) will cause the request to fail. Some integrations also mix methods within the same flow, so using the wrong one at any step breaks the integration.

• GET – retrieves or validates data. Parameters are sent in the URL (query string); no request body is used. Commonly used for validations (e.g. checking an email or lead status).
• POST – creates or submits new records. Data is sent in the request body, usually in JSON or form-data. This is the most common method for sending leads.
• PUT – replaces an existing record with new data. Used less frequently, only if the advertiser’s API requires a full update.
• PATCH – partially updates an existing record. Useful when the API allows updating only certain fields instead of overwriting the whole record.
• DELETE – removes a record. In the context of leads, it can be used for cancellation or retraction.

Cascade type

The Cascade type is an optional setting used in the Offer Cascade. It determines how a request behaves when the integration is executed within a cascade.

Supported values:

• ping
• post
• post verification

If no cascade type is selected and the integration is used in a cascade, the Start Trigger will automatically be treated as POST. However, without specifying a cascade type you cannot define more than one Start Trigger – the system would not know which one to use first.

By assigning a cascade type, you can create a separate Start Trigger for each chosen type. This is useful because some flows require a ping, others only a post or any other type.

Endpoint

The Endpoint is the API URL where the request is sent.

Best practice: Define the base URL as a parameter instead of hardcoding it. This lets you reuse it across requests (e.g. {endpoint}/register-lead) and avoid repetition. Parameters also support testing values, so you can set a testing endpoint for safe validation without changing the production setup.

Format

The Format defines how request data is packaged and sent to the endpoint. Choosing the correct format is essential, since the third-party API will only accept requests in the format it expects.

Supported formats include:

• JSON – data is sent as a JSON object in the request body. Most modern APIs use this format.
• form-data – data is encoded as multipart form-data, typically used for file uploads or form-like submissions.
• x-www-form-urlencoded – data is encoded as key=value pairs joined with &. This format is common in legacy APIs and simple form submissions.
• x-www-form-urlencoded + JSON – a hybrid format where parameters are URL-encoded but can also include JSON payloads for complex fields.
• login-pass-data – a special format where credentials (username/password) are included alongside request data, often for APIs that don’t use token-based authentication.

Best practice: Always check the API documentation of the external service to confirm the required format. Using the wrong format will cause requests to fail even if the endpoint and method are correct.

The formats listed above apply to the entire request, but each individual field can also have its own format and nesting (for example using dot notation for objects or arrays). For details on how to structure fields, see Field Format.

Structure

Each request in the Connection Creator follows a common structure. Depending on the method and format, it can include:

• URL parameters – values appended to the endpoint URL (e.g. ?id=123&status=active). Typically used with GET requests, but can also complement POST/PUT requests.
• Headers – metadata sent along with the request, such as Content-Type, Authorization, or custom keys required by the third-party API.
• Body – the main data payload, available for methods like POST, PUT, or PATCH. Its format (JSON, form-data, x-www-form-urlencoded, etc.) depends on the integration requirements.

Type of field

When mapping data, each field can have a different type that defines how its value is provided:

• Constant – a fixed value defined by the user. Useful for tokens, static identifiers, or values that never change. Example: status = “active”. It can also reference a lead’s data by using the field’s system name with the prefix data_, e.g. data_first_name.
• Object – loads a value directly from the form structure (a field submitted by the lead). The parameter is selected from a multiselect list of available fields. Example: {phone} takes the value from the lead’s phone field.

Authentication

If the integration requires authentication, use the Authentication elements together with parameters such as tokens, API keys, or credentials. By defining these values as parameters, you can reuse them across requests and easily switch between testing and production environments without editing each request manually.

Modifying data

If you need to adjust or transform values before they are sent in an HTTP request, use Modify Field. This allows you to clean, format, or enrich data (for example, adding a country prefix to a phone number, formatting dates, or encoding values) before the request is executed.

Next Steps

After a request is executed, you can define what happens next. In Offer Cascade, the most common ones are:

• Set Variable – store a value from the response into a PalDock variable (e.g. external ID, token, redirect URL) for use later in the flow.
• Finish – by finishing the request, the user is redirected to a specific URL based on the response (e.g. thank-you page, external landing page, redirect URL).