Cloud Tasks handlers can be run on any HTTP endpoint with an external IP address such as GKE, Compute Engine, or even an on-premises web server. Your tasks can be executed on any of these services in a reliable, configurable fashion.
This page demonstrates how to programmatically create basic HTTP target tasks and place them in Cloud Tasks queues. The quickstart demonstrates how to do this using the Google Cloud CLI.
For tasks that have HTTP targets (as opposed to explicit App Engine targets, which are less common), there are two ways to create tasks:
CreateTask method: You must explicitly create a task object. Use this
method if the tasks in your queue have different routing configurations. In
this case, you specify routing at the task level and cannot use queue-level
routing. This approach uses the CreateTask method.
BufferTask method: Use this method if your queue is set up to
buffer tasks in front of a service. The queue must have queue-level routing.
This approach uses the BufferTask method.
CreateTask methodThis section discusses creating a task by constructing the task object. You use
the CreateTask method.
When you create a task using the CreateTask method, you explicitly create and
define the task object. You must specify the service and handler that process
the task.
Optionally, you can pass task-specific data along to the handler. You can also fine-tune the configuration for the task, like scheduling a time in the future when it should be executed or limiting the number of times you want the task to be retried if it fails (see Advanced configuration).
The following examples call the CreateTask method to create a task using the
Cloud Tasks client libraries.
Note the pom.xml file:
Note the package.json file:
Note the composer.json file:
Note the requirements.txt file:
BufferTask methodThis section discusses creating a task by sending an HTTP request. The method
you use is called BufferTask.
The BufferTask method is subject to the following limitations:
Client libraries: The BufferTask method is not supported in client
libraries.
RPC API: The BufferTask method is not supported in the RPC API.
Task-level routing: This method does not support task-level routing. Since there is nowhere to add routing information when creating a task this way, you must use queue-level routing (otherwise the task has no routing information). If your queue does not already use queue-level routing, see Configure queue-level routing for HTTP tasks.
BufferTask methodThe following examples show how to create a task by sending an HTTP POST
request to the Cloud Tasks API
buffer endpoint.
The following code snippet shows an example of task creation using with the
BufferTask method using curl:
curl -X HTTP_METHOD\ "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID/tasks:buffer" \
Replace the following:
HTTP_METHOD: the HTTP method for your request; for
example GET or POST.PROJECT_ID: the ID of your Google Cloud project.
You can get this by running the following in your terminal:
gcloud config get-value project
LOCATION: the location of your queue.QUEUE_ID: the ID of your queue.Cloud Tasks can call HTTP target handlers that require authentication if you have a service account with the appropriate credentials to access the handler.
You can use your current service account if you grant it the appropriate roles. These instructions cover creating a new service account specifically for this function. The existing or new service account used for Cloud Tasks authentication must be in the same project as your Cloud Tasks queues.
In the Google Cloud console, go to the Service Accounts page.
If necessary, select the appropriate project.
Click Create service account.
Give your service account a name. Note the related email address that is generated in the console. You will search for this email in a subsequent step. To copy the email, click Copy to clipboard . You can also add a description of what the account is for.
Click Create and continue.
In the Select a role list, search for and select Cloud Tasks Enqueuer (Beta). This role gives the service account permission to add tasks to the queue.
If you are using a Google Cloud handler, click + Add another role to grant the service account the role associated with accessing the service where your handler is running. Each service within Google Cloud requires a different role. For example, to access a handler on Cloud Run, grant the Cloud Run Invoker role.
To finish creating the service account, click Done.
To allow Cloud Tasks to create authentication tokens using the
service account you just created, you must grant the
Service Account User
(roles/iam.serviceAccountUser) role to the Cloud Tasks
primary service agent on the service account you
just created.
In the Google Cloud console, go to the Service accounts page.
In the row for the service account you just created, select the checkbox, and then click Manage access.
In the Manage Access pane, click Add principal.
In the New principals list, search for and select the
Cloud Tasks service agent which will have an email address in
the format
service-PROJECT_NUMBER@gcp-sa-cloudtasks.iam.gserviceaccount.com.
In the Select a role list, search for and select the Service Account User role.
Click Save.
To authenticate between Cloud Tasks and an HTTP target
handler that requires such authentication, Cloud Tasks creates
a header token. This token is based on the credentials in the
Cloud Tasks Enqueuer service account, identified by its email address. The
service account used for authentication must be part of the same
project where your Cloud Tasks queue resides. The request, with the
header token, is sent from the queue to the handler by HTTPS. You can use either
an ID token
or an access token.
ID tokens should generally be used for any handler running on Google Cloud,
for example, on Cloud Run functions or Cloud Run. The main exception is
for Google APIs hosted on *.googleapis.com: these APIs expect an access token.
You can configure authentication at the queue level, or at the task level. To configure authentication at the queue level, see Limiting access to single queues. If authentication is configured at the queue level, this configuration overrides configuration at the task level. To configure authentication at the task level, specify either an ID (OIDC) token or access (OAuth) token in the task itself.
CreateTask methodThe following examples use the CreateTask method with the
Cloud Tasks client libraries to create a task that also
includes the creation of a header token. ID tokens are used in the examples.
To use an access token, replace the OIDC parameter with the language appropriate
OAuth parameter in constructing the request.
Note the pom.xml file:
Note the package.json file:
Note the requirements.txt file:
BufferTask methodThe following examples use application default credentials to authenticate when
using the BufferTask method for creating a task.
curl -X HTTP_METHOD\ "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID/tasks:buffer" \ -H "Authorization: Bearer ACCESS_TOKEN"
Replace the following:
HTTP_METHOD: the HTTP method for your request; for
example GET or POST.PROJECT_ID: the ID of your Google Cloud project.
You can get this by running the following in your terminal:
gcloud config get-value project
LOCATION: the location of your queue.QUEUE_ID: the ID of your queue.ACCESS_TOKEN: your access token. You can get this by
running the following in your terminal:gcloud auth application-default login
gcloud auth application-default print-access-token
In the following code sample, provide your authentication token value.
HTTP Target task handlers are very similar to App Engine task handlers, with the following exceptions:
Headers: an HTTP target request has headers set by the queue, which contain task-specific information your handler can use. These are similar to, but not identical with, the headers set on App Engine task requests. These headers provide information only. They should not be used as sources of identity.
If these headers were present in an external user request to your app, they are replaced by the internal ones. The sole exception is for requests from logged-in administrators of the application, who are allowed to set headers for testing purposes.
HTTP target requests always contain the following headers:
| Header | Description |
|---|---|
X-CloudTasks-QueueName |
The name of the queue. |
X-CloudTasks-TaskName |
The "short" name of the task, or, if no name was specified at creation, a unique system-generated id. This is the my-task-id value in the complete task name, ie, task_name = projects/my-project-id/locations/my-location/queues/my-queue-id/tasks/my-task-id. |
X-CloudTasks-TaskRetryCount |
The number of times this task has been retried. For the first attempt, this value is 0. This number includes attempts where the task failed due to 5XX error codes and never reached the execution phase. |
X-CloudTasks-TaskExecutionCount |
The total number of times that the task has received a response from the handler. Since Cloud Tasks deletes the task once a successful response has been received, all previous handler responses were failures. This number does not include failures due to 5XX error codes. |
X-CloudTasks-TaskETA |
Initially, the originally scheduled time of the task, specified in seconds since January 1st 1970. Note that it represents the expected dispatch time. On retries, it is updated closer to the current time and can be used to measure delivery latency. It should not be used for task deduplication. |
In addition, requests from Cloud Tasks might contain the following headers:
| Header | Description |
|---|---|
X-CloudTasks-TaskPreviousResponse |
The HTTP response code from the previous retry. |
X-CloudTasks-TaskRetryReason |
The reason for retrying the task. |
You can manually add the
Cloud Tasks Service Agent
(roles/cloudtasks.serviceAgent) role to your Cloud Tasks service
account which is the
primary service agent for
Cloud Tasks.
This is necessary only if you enabled the Cloud Tasks API prior to March 19, 2019.
In the Google Cloud console, go to the IAM page.
Click Grant access. The Grant access pane opens.
In the Add principals section, add an email address in this format:
service-PROJECT_NUMBER@gcp-sa-cloudtasks.iam.gserviceaccount.com
Replace PROJECT_NUMBER with your
Google Cloud project number.
In the Assign roles section, search for and select Cloud Tasks Service Agent.
Click Save.
Find your project number:
gcloud projects describe PROJECT_ID --format='table(projectNumber)'
Replace PROJECT_ID with your project ID.
Copy down the number.
Grant the Cloud Tasks service account the Cloud Tasks Service Agent role, using the project number you copied down:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:service-PROJECT_NUMBER@gcp-sa-cloudtasks.iam.gserviceaccount.com \ --role roles/cloudtasks.serviceAgent
Replace the following:
PROJECT_ID: your Google Cloud project
ID.PROJECT_NUMBER: your Google Cloud
project number.There are a number of task attributes that you can configure. For a full list, see the task resource definition. For example, you can customize the following attributes:
CreateTask only and not supported for BufferTask.You can also configure queue attributes such as routing overrides, rate limits, and retry parameters. These configurations are applied to all tasks in a queue. For more information, see Configure Cloud Tasks queues.
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 2026-06-09 UTC.