Send Batch Requests
Stay organized with collections
Save and categorize content based on your preferences.
This document shows how to batch API calls together to reduce the number of HTTP connections
your client has to make.
This document is specifically about making a batch request by sending an
HTTP request. If, instead, you're using a Google client library to make a batch request, see the client library's documentation.
Overview
Each HTTP connection your client makes results in a certain amount of overhead. The Google Ad Experience Report API supports batching, to allow your client to put several API calls into a single HTTP request.
Examples of situations when you might want to use batching:
- You've just started using the API and you have a lot of data to upload.
- A user made changes to data while your application was offline (disconnected from the Internet), so your application needs to synchronize its local data with the server by sending a lot of updates and deletes.
In each case, instead of sending each call separately, you can group them together into a single HTTP request. All the inner requests must go to the same Google API.
You're limited to 1000 calls in a single batch request. If you must make more calls than that, use multiple batch requests.
Note: The batch system for the Google Ad Experience Report API uses the same syntax as the OData batch processing system, but the semantics differ.
Batch details
A batch request consists of multiple API calls combined into one HTTP request, which can be sent to the batchPath specified in the API discovery document. The default path is /batch/api_name/api_version. This section describes the batch syntax in detail; later, there's an example.
Note: A set of n requests batched together counts toward your usage limit as n requests, not as one request. The batch request is separated into a set of requests before processing.
A batch request is a single standard HTTP request containing multiple Google Ad Experience Report API calls, using the multipart/mixed content type. Within that main HTTP request, each of the parts contains a nested HTTP request.
Each part begins with its own Content-Type: application/http HTTP header. It can also have an optional Content-ID header. However, the part headers are just there to mark the beginning of the part; they're separate from the nested request. After the server unwraps the batch request into separate requests, the part headers are ignored.
The body of each part is a complete HTTP request, with its own verb, URL, headers, and body. The HTTP request must only contain the path portion of the URL; full URLs are not allowed in batch requests.
The HTTP headers for the outer batch request, except for the Content- headers such as Content-Type, apply to every request in the batch. If you specify a given HTTP header in both the outer request and an individual call, then the individual call header's value overrides the outer batch request header's value. The headers for an individual call apply only to that call.
For example, if you provide an Authorization header for a specific call, then that header applies only to that call. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls unless they override it with Authorization headers of their own.
When the server receives the batched request, it applies the outer request's query parameters and headers (as appropriate) to each part, and then treats each part as if it were a separate HTTP request.
Response to a batch request
The server's response is a single standard HTTP response with a multipart/mixed content type; each part is the response to one of the requests in the batched request, in the same order as the requests.
Like the parts in the request, each response part contains a complete HTTP response, including a status code, headers, and body. And like the parts in the request, each response part is preceded by a Content-Type header that marks the beginning of the part.
If a given part of the request had a Content-ID header, then the corresponding part of the response has a matching Content-ID header, with the original value preceded by the string response-, as shown in the following example.
Note: The server might perform your calls in any order. Don't count on their being executed in the order in which you specified them. If you want to ensure that two calls occur in a given order, you can't send them in a single request; instead, send the first one by itself, then wait for the response to the first one before sending the second one.
Example
The following example shows the use of batching with the Google Ad Experience Report API.
Example batch request
POST /batch/v1?key=key HTTP/1.1
Content-Type: multipart/mixed; boundary=batch_aer
--batch_aer
Content-Type: application/http
Content-ID: id1
GET /v1/sites/http%3A%2F%2F/site1%2F HTTP/1.1
--batch_aer
Content-Type: application/http
Content-ID: id2
GET /v1/sites/http%3A%2F%2F/site2%2F HTTP/1.1
--batch_aer--
Example batch response
This is the response to the example request in the previous section.
HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=batch_aer
--batch_aer
Content-Type: application/http
Content-ID: response-id1
HTTP/1.1 200 OK
Content-Type: application/json
{
"reviewedSite": "site1",
"mobileSummary": {
"lastChangeTime": "2019-02-05T09:46:26.521747Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site1/",
"filterStatus": "OFF"
},
"desktopSummary": {
"lastChangeTime": "2019-02-07T23:07:29.017206Z",
"betterAdsStatus": "FAILING",
"enforcementTime": "2018-02-15T15:00:00Z",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site1/",
"filterStatus": "ON"
}
}
--batch_aer
Content-Type: application/http
Content-ID: response-id2
HTTP/1.1 200 OK
Content-Type: application/json
{
"reviewedSite": "site2",
"mobileSummary": {
"lastChangeTime": "2018-03-06T16:06:33.375851Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site2/",
"filterStatus": "OFF"
},
"desktopSummary": {
"lastChangeTime": "2018-03-06T16:06:33.375851Z",
"betterAdsStatus": "PASSING",
"reportUrl": "https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site2/",
"filterStatus": "OFF"
}
}
--batch_aer--
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-28 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-28 UTC."],[[["\u003cp\u003eBatching API calls reduces HTTP connection overhead by combining multiple calls into a single request.\u003c/p\u003e\n"],["\u003cp\u003eUse batching for scenarios like initial data uploads or synchronizing offline changes.\u003c/p\u003e\n"],["\u003cp\u003eA batch request uses \u003ccode\u003emultipart/mixed\u003c/code\u003e content type and can contain up to 1000 individual API calls.\u003c/p\u003e\n"],["\u003cp\u003eThe server responds with a \u003ccode\u003emultipart/mixed\u003c/code\u003e response, containing individual responses for each call in the batch.\u003c/p\u003e\n"],["\u003cp\u003eCalls within a batch are not guaranteed to execute in order, and each call counts towards your usage limit.\u003c/p\u003e\n"]]],["Batching combines multiple API calls into a single HTTP request to reduce overhead. It's useful for uploading large amounts of data or synchronizing offline changes. A batch request uses the `multipart/mixed` content type and contains nested HTTP requests, each with its own headers and body. The server processes each request individually, treating them as separate. Responses are returned in a `multipart/mixed` format, with each part corresponding to a request. A maximum of 1000 calls per batch is allowed.\n"],null,["# Send Batch Requests\n\nThis document shows how to batch API calls together to reduce the number of HTTP connections\nyour client has to make.\n\nThis document is specifically about making a batch request by sending an\nHTTP request. If, instead, you're using a Google client library to make a batch request, see the [client library's documentation](https://developers.google.com/api-client-library/).\n\nOverview\n--------\n\nEach HTTP connection your client makes results in a certain amount of overhead. The Google Ad Experience Report API supports batching, to allow your client to put several API calls into a single HTTP request.\n\nExamples of situations when you might want to use batching:\n\n- You've just started using the API and you have a lot of data to upload.\n- A user made changes to data while your application was offline (disconnected from the Internet), so your application needs to synchronize its local data with the server by sending a lot of updates and deletes.\n\nIn each case, instead of sending each call separately, you can group them together into a single HTTP request. All the inner requests must go to the same Google API.\n\nYou're limited to 1000 calls in a single batch request. If you must make more calls than that, use multiple batch requests.\n\n**Note** : The batch system for the Google Ad Experience Report API uses the same syntax as the [OData batch processing](http://www.odata.org/documentation/odata-version-3-0/batch-processing/) system, but the semantics differ.\n\n\nBatch details\n-------------\n\nA batch request consists of multiple API calls combined into one HTTP request, which can be sent to the `batchPath` specified in the [API discovery document](https://developers.google.com/discovery/v1/reference/apis). The default path is `/batch/`\u003cvar translate=\"no\"\u003eapi_name\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eapi_version\u003c/var\u003e. This section describes the batch syntax in detail; later, there's an [example](#example).\n\n**Note** : A set of \u003cvar translate=\"no\"\u003en\u003c/var\u003e requests batched together counts toward your usage limit as \u003cvar translate=\"no\"\u003en\u003c/var\u003e requests, not as one request. The batch request is separated into a set of requests before processing.\n\n### Format of a batch request\n\nA batch request is a single standard HTTP request containing multiple Google Ad Experience Report API calls, using the `multipart/mixed` content type. Within that main HTTP request, each of the parts contains a nested HTTP request.\n\nEach part begins with its own `Content-Type: application/http` HTTP header. It can also have an optional `Content-ID` header. However, the part headers are just there to mark the beginning of the part; they're separate from the nested request. After the server unwraps the batch request into separate requests, the part headers are ignored.\n\nThe body of each part is a complete HTTP request, with its own verb, URL, headers, and body. The HTTP request must only contain the path portion of the URL; full URLs are not allowed in batch requests.\n\nThe HTTP headers for the outer batch request, except for the `Content-` headers such as `Content-Type`, apply to every request in the batch. If you specify a given HTTP header in both the outer request and an individual call, then the individual call header's value overrides the outer batch request header's value. The headers for an individual call apply only to that call.\n\nFor example, if you provide an Authorization header for a specific call, then that header applies only to that call. If you provide an Authorization header for the outer request, then that header applies to all of the individual calls unless they override it with Authorization headers of their own.\n\nWhen the server receives the batched request, it applies the outer request's query parameters and headers (as appropriate) to each part, and then treats each part as if it were a separate HTTP request.\n\n### Response to a batch request\n\nThe server's response is a single standard HTTP response with a `multipart/mixed` content type; each part is the response to one of the requests in the batched request, in the same order as the requests.\n\nLike the parts in the request, each response part contains a complete HTTP response, including a status code, headers, and body. And like the parts in the request, each response part is preceded by a `Content-Type` header that marks the beginning of the part.\n\nIf a given part of the request had a `Content-ID` header, then the corresponding part of the response has a matching `Content-ID` header, with the original value preceded by the string `response-`, as shown in the following example.\n\n**Note**: The server might perform your calls in any order. Don't count on their being executed in the order in which you specified them. If you want to ensure that two calls occur in a given order, you can't send them in a single request; instead, send the first one by itself, then wait for the response to the first one before sending the second one.\n\nExample\n-------\n\nThe following example shows the use of batching with the Google Ad Experience Report API.\n\n### Example batch request\n\n```\n\n POST /batch/v1?key=key HTTP/1.1\n Content-Type: multipart/mixed; boundary=batch_aer\n\n --batch_aer\n Content-Type: application/http\n Content-ID: id1\n\n GET /v1/sites/http%3A%2F%2F/site1%2F HTTP/1.1\n\n --batch_aer\n Content-Type: application/http\n Content-ID: id2\n\n GET /v1/sites/http%3A%2F%2F/site2%2F HTTP/1.1\n\n --batch_aer--\n \n```\n\n### Example batch response\n\nThis is the response to the example request in the previous section. \n\n```\n\n HTTP/1.1 200 OK\n Content-Type: multipart/mixed; boundary=batch_aer\n\n --batch_aer\n Content-Type: application/http\n Content-ID: response-id1\n\n HTTP/1.1 200 OK\n Content-Type: application/json\n\n {\n \"reviewedSite\": \"site1\",\n \"mobileSummary\": {\n \"lastChangeTime\": \"2019-02-05T09:46:26.521747Z\",\n \"betterAdsStatus\": \"PASSING\",\n \"reportUrl\": \"https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site1/\",\n \"filterStatus\": \"OFF\"\n },\n \"desktopSummary\": {\n \"lastChangeTime\": \"2019-02-07T23:07:29.017206Z\",\n \"betterAdsStatus\": \"FAILING\",\n \"enforcementTime\": \"2018-02-15T15:00:00Z\",\n \"reportUrl\": \"https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site1/\",\n \"filterStatus\": \"ON\"\n }\n }\n\n --batch_aer\n Content-Type: application/http\n Content-ID: response-id2\n\n HTTP/1.1 200 OK\n Content-Type: application/json\n\n {\n \"reviewedSite\": \"site2\",\n \"mobileSummary\": {\n \"lastChangeTime\": \"2018-03-06T16:06:33.375851Z\",\n \"betterAdsStatus\": \"PASSING\",\n \"reportUrl\": \"https://www.google.com/webmasters/tools/ad-experience-mobile?siteUrl=http://site2/\",\n \"filterStatus\": \"OFF\"\n },\n \"desktopSummary\": {\n \"lastChangeTime\": \"2018-03-06T16:06:33.375851Z\",\n \"betterAdsStatus\": \"PASSING\",\n \"reportUrl\": \"https://www.google.com/webmasters/tools/ad-experience-desktop?siteUrl=http://site2/\",\n \"filterStatus\": \"OFF\"\n }\n }\n\n --batch_aer--\n \n```"]]