Skip to main content
All parameters work on both GET /api/v1/search (as query string parameters) and POST /api/v1/search (as JSON body fields). POST is preferred for location-bearing requests.
Most integrations only need q and searchMode. The filtering and output parameters below are available when you need more control.

Core parameters

Intent values

When not set, the API auto-detects intent from the query. You can force a specific intent using common aliases: The API also accepts full intent names (e.g., FallbackSearchIntent, VideoSearchIntent) and resolves matches flexibly through exact match, case-insensitive match, and substring match.

Output parameters

metadata=full adds latency because it fetches additional data from each result page. Use it only when you need contentType or reader data.

Locale and safety parameters

Date filtering

Use either dateRange for relative filtering or dateFrom/dateTo for absolute date ranges. See filtering for examples and details.

Domain filtering

Both support wildcards: *.example.com matches all subdomains. See filtering for examples and details.

Term filtering

Content filtering

Behavior parameters

Location parameters

Location can be passed as flat keys on GET or POST. Prefer POST for location-bearing requests — a request body keeps coordinates out of URL query strings and access logs.

Examples

Deep mode with extracts

Filtered by date and domain

Multi-query search accepts a JSON array of up to 5 queries and returns combined results in a single response. URL-encode the JSON array when passing it as a query parameter.

Next steps

Search modes

Automatic effort by default, manual control when you want it.

Filtering

Domain, date, and content filtering in depth.

Query operators

In-query operators like site: and filetype:.

Response format

Response structure and result types.