Asynchronous Requests
In this article, we’ll explain the difference between sync and async requests, highlight the benefits of the async flow, and describe key parameters with examples.
Async VS Sync requests
There are 2 ways for us to handle your Web Unlocker and SERP API requests:
-
default
Synchronous requests - Send a request and get a real-time response immediately -
Asynchronous requests - Send a request (without waiting for an immediate response) and retrieve the results later via our designated API endpoint. Callback times are usually up to 5 minutes but may take up to 8 hours during peak periods. Responses are stored for up to 48 hours from the time the request was sent.
Why should I use Async?
-
99.99% success rate
-
Stability
-
Flexibility - the ability to retrieve your requests at a later time of your choosing (and not have to wait for the response immediately after sending the request)
How it works
Sending requests and receiving responses with Async mode is a two-step flow:
-
Sending the request - This request includes the search parameters, returns a
response_ID
, and is a direct request (i.e. you will be billed for this request). -
Collecting the response - This request includes the
response_ID
and is free of charge (i.e. you will not be billed for this request). If you call for aresponse_ID
which is still being processed you will receive a 102 status code.
Getting started
Enable "Asynchronous requests"
Within your specific Web Unlocker or SERP API zone, under “Advanced settings”, enable the “Asynchronous requests” toggle.
[Optional] Setting up a webhook (POST or GET)
This is where you will get notified on the status of your future requests
Sending an async request
The request syntax is slightly different from that of synchronous requests and requires an API token for authentication. See a basic example below (for more request parameters see below):
You’ll receive a response to the above that contains an x-response-id
header with the ID of your request. This is the RESPONSE_ID
for this request which you will use when collecting your results in the next step.
You can easily save the RESPONSE_ID
in your script by initializing it along with your request like this:
Webhook notification
If you’ve set up a webhook, you’ll receive a notification immediately when the requests are ready with the following parameters: status
, response_id
, request_url
and hook_data
(optional - if you’ve used the webhook_data
parameter in your request).
Whitelist our webhook IPs
Our asynchronous webhooks delivery sends notifications from a pair of stable IP addresses, so please make sure to whitelist them:
100.27.150.189
18.214.10.85
Collecting your results
Using the RESPONSE_ID
received in step 3, send the following:
Initial request parameters
webhook_url | Defines the URL to which the job status notification will be sent. If you don’t want to setup a default webhook (above) or prefer the URL to be different per request, use this. |
webhook_method | POST or GET (Default). Defines the method with which job status notification will be delivered. |
webhook_data | Defines the data that will be sent with job status notification |
query | Defines the query object for the request and supports various Web Unlocker and SERP API parameters (i.e.country ) |
brd_json | SERP API only - To enable and configure parsing. By default, a SERP API request returns an unparsed structured HTML of the targeted SERP. If you would like to receive a parsed JSON response, add one of the following parameter values - brd_json=1 - Returns a single parsed JSON (instead of a raw HTML) - brd_json=html - Returns a single parsed JSON containing an additional “html” field (with the raw HTML) along with the other parsed fields query.brd_json could be used instead of this parameter |
multi | To run multiple queries within the same request (see below) |
Response/collection parameters
mandatory
response_id | Defines the job id. Received in the response to your initial async request. |
Multiple queries in a single request
Async supports sending 2 parallel query requests within one API request using the multi
parameter.
These parallel requests use the same peer IP and session and can be used for collecting additional data, comparison tests, etc. – e.g., making a pair of requests with different parameters/values. They use the same IP and session.
Conditions:
-
Supported only for a zone with Async enabled (as shown above)
-
Supported only for Google Search
-
Limited to 2 requests
-
Billed as 2 requests
multi
parameter usage:
multi
request example:
Collect the result
Use the response ID from the x-response-id
returned above to collect the result:
Was this page helpful?