Skip to content

DuckDuckGo Search API · source-payload endpoint

DuckDuckGo Search API for controlled SERP capture.

Set a query and documented DuckDuckGo filters, then receive a JSON envelope containing request metadata and the source SERP HTML payload. Your application owns extraction, validation, and schema maintenance.

Server-side GET request · engine=duckduckgo · Discuss your source-data workflow

  • Focused search controls Query, locale, interface, safety, time
  • Source preserved SERP HTML carried in JSON
  • Ownership explicit Your extractor, schema, and validation
  • Context attached Request metadata beside payload
Web data workflow · duckduckgo searchReady

q privacy research

kl en_US

kad en_US

kp -1

moderate

fielddf m
stackDuckDuckGo capture contract
stackFilter manifest
stackprivacy research
stacken_US
Illustrative request and response shape—not customer data. The source SERP HTML payload remains inside the JSON envelope for customer-owned extraction.

A clear handoff

Capture the source response without blurring who owns the data model.

WebScrapingAPI operates the documented DuckDuckGo request path. Your application receives the source payload and decides how to extract, validate, version, store, and use it.

01

Constrain the observation

Keep the query, locale, interface language, safe-search level, time range, and device beside each capture.

02

Retain the source

Receive the source SERP HTML payload inside a JSON envelope rather than assuming a fixed downstream schema.

03

Design your extractor

Select only the fields your workflow needs and validate them against representative payloads.

04

Version layout changes

Treat extraction rules and record schemas as application code that your team tests and maintains.

WebScrapingAPI Documented request execution

Response boundary Metadata + source SERP HTML

Your application Extraction + schema maintenance

DuckDuckGo web search

A focused endpoint for controlled source-SERP observations.

Use the DuckDuckGo engine for web search requests with the documented filter family. Validate actual payloads for the query combinations your product depends on.

Capture scope

Query context in, source page payload out.

The envelope keeps submitted-search metadata adjacent to the DuckDuckGo result payload so your pipeline can retain the provenance it needs.

Review the basic request

Locale

Country and language

Scope the search with a documented combined locale value.

Presentation

Interface language

Set the language used by DuckDuckGo controls and labels.

Policy

Safe search

Choose a documented safe-search level for the request.

Recency

Time range

Request a documented day, week, month, or year window, or omit the filter.

Presentation

Device

Select a documented device context for the requested result page.

Coverage boundary: DuckDuckGo can change the fields and markup exposed by its page. Test representative payloads and keep extraction assumptions inside a versioned customer-owned consumer.

Documented filter set

Make the search context explicit before you compare captures.

Begin with the required query. Add only the optional DuckDuckGo filters that belong to the observation you intend to reproduce.

q Required

Search query

Provide the terms DuckDuckGo should search and URL-encode spaces or special characters.

kl Optional

Country + language

Use a documented combined locale code, such as en_US, when the request needs that context.

kad Optional

Interface language

Choose the documented language for DuckDuckGo controls and labels.

kp Optional

Safe-search level

Set on, moderate, or off with the documented numeric value.

df Optional

Time range

Limit results to the past day, week, month, or year, or omit the filter for any time.

device Optional

Device context

Select a documented device value when the requested presentation context matters.

Parameter source of truth Confirm accepted values before production use.

Source-payload response

Treat the JSON envelope as a transport boundary—not your final record model.

The endpoint response is a JSON envelope containing request metadata and the source SERP HTML payload. Your application owns extraction, validation, and schema maintenance.

Documented shape

Metadata beside the payload

JSON

{ "search_parameters": { "search_engine": "duckduckgo", "query": "privacy research" }, "search_results": "<html>...source SERP HTML...</html>" }

Field presence and source markup can change. Store and inspect only what your workflow needs.

Consumer contract

Your team defines the stable layer.

  1. Inspect

    Check the HTTP outcome and expected envelope fields.

  2. Extract

    Read the elements required by your downstream use case.

  3. Validate

    Distinguish absent content, changed markup, and failed extraction.

  4. Version

    Record extractor and schema versions with derived data.

Ownership rule

WebScrapingAPI returns the documented envelope. Your application owns any extraction from the source SERP HTML payload and the maintenance of every downstream field contract.

Request to maintained record

Build the capture and extraction lifecycle as separate stages.

Keeping the endpoint response separate from your business schema makes ownership, validation, and layout-change handling easier to reason about.

  1. 01

    Define context

    Select the query and only the documented filters required by the observation.

  2. 02

    Send and validate

    Call server-side, inspect the HTTP status, and confirm the expected source-payload envelope.

  3. 03

    Extract and version

    Apply your tested rules, validate required fields, and attach your schema version.

Integration

Start with one DuckDuckGo request and an explicit failure path.

Keep credentials server-side, URL-encode request values, set a bounded timeout, inspect unsuccessful HTTP states, and validate the envelope before extraction.

Request brief

Test the context your consumer will maintain.

Begin with one representative query and a small, documented filter set. Save the source payload separately from derived records while the extractor is under test.

Secret
WSA_API_KEY stays server-side
Engine
engine=duckduckgo
Filter example
kl=en_US
Consumer
Check status, envelope, then source
: "${WSA_API_KEY:?WSA_API_KEY is required}" curl --get --fail-with-body --max-time 120 \ "https://serpapi.webscrapingapi.com/v2" \ --data-urlencode "api_key=$WSA_API_KEY" \ --data-urlencode "engine=duckduckgo" \ --data-urlencode "q=privacy research" \ --data-urlencode "kl=en_US" \ --data-urlencode "kad=en_US" \ --data-urlencode "kp=1" \ --data-urlencode "df=w" \ --data-urlencode "device=desktop"

Safe starting point

Each example keeps the key server-side, sends the documented engine and query, uses a bounded timeout, and exposes unsuccessful HTTP outcomes.

Product choice

Choose by how much of the source-to-schema workflow you want to own.

DuckDuckGo Search API handles the documented engine request and source-payload envelope. Adjacent products shift responsibility toward access infrastructure or managed data delivery.

Production evaluation

Validate payload fit before selecting a plan.

Test ordinary, localized, time-filtered, empty, changed-layout, and unsuccessful cases. Current pricing and plan descriptions remain the commercial source of truth.

Evaluation matrix

Count contexts and maintenance work together.

Illustrative workload formula

Queries × Filter sets × Run frequency + Extractor tests

This is an evaluation model, not a billing formula. Include source retention, schema validation, and layout-change handling in your production design.

Go-live questions

Context

Which filter combinations matter?

Contract

Which source fields must be present?

Quality

How are markup changes detected?

Recovery

Which failures may be retried?

Ownership

Who maintains extractor and schema?

Discuss production requirements

FAQ

DuckDuckGo Search API questions for a grounded evaluation.

Use the current documentation and representative source payloads as the implementation source of truth.

Browse DuckDuckGo documentation

What does DuckDuckGo Search API return?

The endpoint returns a JSON envelope containing request metadata and the source SERP HTML payload. It does not define your downstream record schema; your application owns extraction and schema maintenance.

Who owns extraction when the DuckDuckGo layout changes?

Your team owns extraction rules, validation, and schema maintenance for the source SERP HTML payload. When DuckDuckGo changes its page, test your extractor against representative responses before promoting changes.

Which DuckDuckGo filters can I control?

The documented controls used on this page are q for the query, kl for country and language, kad for interface language, kp for safe search, and df for a time range. Omit optional filters you do not need.

Is the source payload already shaped to my schema?

No. The response preserves the source SERP HTML payload inside a JSON envelope. Your application decides which fields to extract, how to model them, and how to version the resulting schema.

How should my application handle unsuccessful requests?

Check the HTTP status before reading the body, retain enough request context to investigate failures, and use bounded retry behavior appropriate to your workflow. Treat response parsing and validation as explicit application steps.

When should I consider Managed Data instead?

Choose the API when your team wants request-time capture and will operate extraction, schema, storage, and scheduling. Consider Managed Data when you want to scope an agreed query set, cadence, schema, quality process, and delivery with WebScrapingAPI.

Your first source capture

Test one DuckDuckGo query against the schema your team intends to maintain.

Start with the documented endpoint, or speak with our team about an agreed managed data workflow.