---
title: "POST /v1/services/{serviceName}/rollouts"
method: POST
path: "/v1/services/{serviceName}/rollouts"
tags: ["services"]
---

# POST /v1/services/{serviceName}/rollouts

`POST /v1/services/{serviceName}/rollouts`

Creates a new service configuration rollout. Based on rollout, the Google Service Management will roll out the service configurations to different backend services. For example, the logging configuration will be pushed to Google Cloud Logging. Please note that any previous pending and running Rollouts and associated Operations will be automatically cancelled so that the latest Rollout will not be blocked by previous Rollouts. Only the 100 most recent (in any state) and the last 10 successful (if not already part of the set of 100 most recent) rollouts are kept for each service. The rest will be deleted eventually. Operation

## Path parameters

- `serviceName` string, required

## Request body

- Rollout — A rollout resource that defines how service configuration versions are pushed to control plane systems. Typically, you create a new version of the service config, and then create a Rollout to push the service config.
  - `rolloutId` string — Optional. Unique identifier of this Rollout. Must be no longer than 63 characters and only lower case letters, digits, '.', '_' and '-' are allowed. If not specified by client, the server will generate one. The generated id will have the form of , where "date" is the create date in ISO 8601 format. "revision number" is a monotonically increasing positive number that is reset every day for each service. An example of the generated rollout_id is '2016-02-16r1'
  - `serviceName` string — The name of the service associated with this Rollout.
  - `createTime` string, google-datetime — Creation time of the rollout. Readonly.
  - `deleteServiceStrategy` DeleteServiceStrategy — Strategy used to delete a service. This strategy is a placeholder only used by the system generated rollout to delete a service.
  - `createdBy` string — The user who created the Rollout. Readonly.
  - `status` 'ROLLOUT_STATUS_UNSPECIFIED' | 'IN_PROGRESS' | 'SUCCESS' | 'CANCELLED' | 'FAILED' | 'PENDING' | 'FAILED_ROLLED_BACK' — The status of this rollout. Readonly. In case of a failed rollout, the system will automatically rollback to the current Rollout version. Readonly.
  - `trafficPercentStrategy` TrafficPercentStrategy — Strategy that specifies how clients of Google Service Controller want to send traffic to use different config versions. This is generally used by API proxy to split traffic based on your configured percentage for each config version. One example of how to gradually rollout a new service configuration using this strategy: Day 1 Rollout { id: "example.googleapis.com/rollout_20160206" traffic_percent_strategy { percentages: { "example.googleapis.com/20160201": 70.00 "example.googleapis.com/20160206": 30.00 } } } Day 2 Rollout { id: "example.googleapis.com/rollout_20160207" traffic_percent_strategy: { percentages: { "example.googleapis.com/20160206": 100.00 } } }
    - `percentages` object — Maps service configuration IDs to their corresponding traffic percentage. Key is the service configuration ID, Value is the traffic percentage which must be greater than 0.0 and the sum must equal to 100.0.

## Response `200`

Successful response

---

[API](https://skmtc.net/google/apis/servicemanagement.md) · [All operations](https://skmtc.net/google/apis/servicemanagement/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/google/servicemanagement/versions/b1952da149f2/schema)