API integration

Users with access to a specific Offer can view its details together with allowed propagation options (Link, iFrame, API).

For each Offer with API propagation enabled, PalDock automatically generates API documentation for affiliates. The documentation is derived directly from the Lead Structure (where input fields are defined). This makes it possible to generate and maintain API specs automatically (e.g., Swagger / OpenAPI), so partners can both read and test the integration before development.

PalDock uses a single endpoint for all requests and workspaces. In the payload, the tenant parameter specifies the workspace, and another field specifies the Offer. This means you don’t need different endpoints for different tenants or offers. With the Global Fields feature, the payload format stays almost the same across all offers, except when you add custom fields.

This setup makes things much easier. Affiliates can run many Offers, even from different workspaces, using just one endpoint. There’s no need to handle lots of different URLs and integrations. The PalDock API works the same way everywhere, so integrations are simple and consistent. Thanks to this, integrations are incredibly quick and affiliates can start sending their first leads on the very same day they get onboarded.

Process after Lead Submission

When a lead is submitted, the API response includes the RedirectURL. The affiliate’s frontend should redirect the customer there right away.

After that, additional internal screens (verification, thank-you page, final page, etc.) may be shown on the RedirectURL, depending on how the Offer is configured.

Depending on the Admin configuration, PalDock supports two response modes:

Basic Response – only status and redirectUrl

{  "redirectUrl": "https://google.com",  "status": "accepted",  "id": "1234",  "external_id": "4321"}

Detailed Response – full breakdown of how the lead was processed across cascade channels (see feature External Final Page for more info).

API Parameters

The most common parameters used in PalDock are:

  • Affiliate Click ID – a custom click identifier provided by the affiliate
  • Aff_s1 to Aff_s5 – custom fields where affiliates can pass their own IDs or values for tracking and reporting
  • External Redirect URL – an alternative URL where the user should be redirected after form submission (Feature External redirect URL must be enabled)
  • Test – marks the lead as a test so it will not be processed as a standard lead
  • Sync – Enables instant lead rejection (Feature Refuse leads must be enabled)

Parameters can be passed in the payload.

Tracking Lead Status (Approved or Rejected)

When affiliate sends a lead into PalDock via the Affiliate API, affiliate may want to know whether the lead was successfully processed (approved) or failed (rejected). PalDock provides several ways to retrieve this status.

Enable Refuse leads feature in Offer settings to use this feature.

1. Synchronous Response (Sync=1)

If affiliate includes the parameter Sync=1 in query or body of the request, PalDock will hold the API response until the offer evaluation is complete.

  • This can take several minutes, depending on the offer logic.
  • Affiliates must configure a sufficiently long timeout on their side.

Example response:

{  "id": "9e886baa-6804-4dfe-baf9-a065b66d7f87",  "status": "approved",  "redirect_url": "https://api.paldock.com/api/tenant/processes/12345"}

Although simple, it is the most effective solution.

2. Automatic S2S Postback (Recommended)

The most efficient option is to let PalDock send affiliate the status update automatically.

  • Include the parameter status_url in Affiliate API request.
  • If the parameter is present, PalDock will automatically send a status postback to the given URL once the lead status changes.
  • The payload is identical to the standard API response.

Example request with status_url:

{  "first_name": "John",  "last_name": "Doe",  "tenant": "tenant",  "status_url": "https://affiliate.com/postback/lead-status"}

Automatic postback sent by PalDock:

{  "id": "9e886baa-6804-4dfe-baf9-a065b66d7f87",  "status": "approved",  "redirect_url": "https://api.paldock.com/api/tenant/processes/12345"}

This solution is also good: no repeated polling, minimal delay, and automatic updates.

3. Polling Endpoint (Not Recommended)

Alternatively, affiliate can repeatedly query a dedicated endpoint with the lead id they received in the initial response.

Request:

{  "id": "9e886baa-6804-4dfe-baf9-a065b66d7f87"}

Response:

{  "id": "9e886baa-6804-4dfe-baf9-a065b66d7f87",  "status": "approved",  "redirect_url": "https://api.paldock.com/api/tenant/processes/12345"}

⚠️ This method requires calling the endpoint every few seconds until the status changes, which leads to unnecessary server load. We do not recommend using it in production.

API Features

  • Data feeds – API responses can include a feed_id to match against external data feeds (e.g., logos, names, or additional attributes). The response may also override certain fields from the data feed for a specific lead. This is useful in cases such as mortgages, where an individual customer might receive a dedicated interest rate. For full details, see the Data feed page.

Related articles

Offers > Lead and Click Capping
Offers > Filters
Offers > Auto submit
Offers > Pre-filling fields
Offers > AffiliateID rewrite
Offers > Data feeds
Offers > External Final Page
Offers > Process refused leads
Offers > Refuse leads
Offers > Distribution

Insights that
helps you grow