Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Storage supports multiple versions. To make a request against the storage services, you must specify the version that you want to use for that operation, unless the request is anonymous.
As of June 5, 2025, the latest fully deployed version of the Azure Storage service is 2025-11-05. 2025-07-05 and 2025-05-05 are also broadly deployed, as indicated in the following table. All versions are GA quality.
If the table indicates an x-ms-version is enabled in a region, all previous x-ms-versions are also enabled. Attempting to use a service version that isn't fully deployed in your storage account's region might generate a x-ms-version mismatch error.
x-ms-version |
Region Availability | SDK Support |
|---|---|---|
2025-05-05 |
asiaeast asiasoutheast australiac australiac2 australiaeast australiasoutheast austriae belgiumc brazilse brazilsouth canadacentral canadaeast chilec denmarke europenorth europewest francec frances germanyn germanywc indiacentral indiasouth indiawest indonesiac israelc israelnw italyn japaneast japanwest jioinc jioinw koreacentral koreasouth malaysias malaysiaw mexicoc newzealandn norwaye norwayw polandc qatarc southafrican southafricaw spainc swedenc swedens switzerlandn switzerlandw taiwann taiwannw uaec uaen uksouth ukwest uscentral uscentraleuap useast useast2 useast2euap usnorth ussouth ussouth2 ussoutheast ussoutheast3 ussoutheast5 ussouthwest uswest uswest2 uswest3 uswestcentral |
Latest GA |
2025-07-05 |
australiac australiac2 australiaeast austriae belgiumc brazilse brazilsouth canadacentral canadaeast chilec denmarke europenorth europewest francec frances germanyn germanywc indiacentral indiasouth indiawest indonesiac israelc israelnw italyn japaneast japanwest jioinc jioinw koreasouth malaysias malaysiaw mexicoc newzealandn norwaye norwayw polandc qatarc southafrican spainc swedenc swedens switzerlandn switzerlandw taiwann taiwannw uaec uaen uksouth ukwest uscentraleuap ussouth2 ussoutheast ussoutheast3 ussoutheast5 ussouthwest uswestcentral |
Beta |
2025-11-05 |
australiac australiac2 australiaeast belgiumc brazilse brazilsouth chilec denmarke francec frances germanywc indiacentral indiasouth indiawest indonesiac israelnw italyn japaneast jioinc jioinw koreasouth malaysias malaysiaw mexicoc newzealandn norwayw polandc qatarc spainc swedenc swedens switzerlandn switzerlandw taiwann taiwannw uaec uaen ukwest ussouth2 ussoutheast ussoutheast3 ussoutheast5 ussouthwest uswestcentral |
Beta |
The default x-ms-version being used by the Azure Storage data plane SDKs can be found in the changelogs in the following table:
The data plane Storage SDKs don't perform GA releases to the other official package feeds until the default x-ms-version for the release in question has full rollout in all regions. Therefore, the latest GA SDK release from the official package managers can safely be used in any region.
The latest version of the Azure storage services is 2025-11-05, and we recommend that you use it where possible. For a list of all other supported versions, and for information about using each version, see Previous Azure Storage service versions.
The 2025-11-05 service version includes the following features:
- The following APIs now return
x-ms-copy-source-status-codeandx-ms-copy-source-error-code. For more information, see Status and Error Codes.
Specify service versions in requests
How you specify the version of the storage services to use for a request relates to how that request is authorized. The following sections describe authorization options and how the service version is specified for each.
Requests that use an OAuth 2.0 token from Microsoft Entra: To authorize a request with Microsoft Entra ID, pass the
x-ms-versionheader on the request with a service version of 2017-11-09 or higher. For more information, see Call storage operations with OAuth tokens in Authorize with Microsoft Entra ID.Requests that use Shared Key or Shared Key Lite: To authorize a request with Shared Key or Shared Key Lite, pass the
x-ms-versionheader on the request. When using Azure Blob Storage, you can specify the default version for all requests by calling Set Blob Service Properties.Requests that use a shared access signature (SAS): You can specify two versioning options on a shared access signature. The optional
api-versionheader indicates which service version to use to execute the API operation. The requiredSignedVersion (sv)parameter specifies the service version to use to authorize the request made with the SAS. If theapi-versionheader isn't specified, the value of theSignedVersion (sv)parameter also indicates the version to use to execute the API operation.Requests that use anonymous access: When utilizing anonymous access against Blob Storage, no version is passed in. The heuristics for determining which version to use for the request are described in the next sections.
Authorize requests by using Microsoft Entra ID, Shared Key, or Shared Key Lite
To authorize a request with Microsoft Entra ID, Shared Key, or Shared Key Lite, specify the x-ms-version header on the request. The x-ms-version request header value must be specified in the format YYYY-MM-DD. For example:
Request Headers:
x-ms-version: 2020-04-08
The following rules describe how these requests are evaluated to determine which version to use to process the request.
If a request has a valid
x-ms-versionheader, the storage service uses the specified version. All requests to Azure Table Storage and Azure Queue Storage that don't use a shared access signature must specify anx-ms-versionheader. All requests to Blob Storage that don't use a shared access signature must specify anx-ms-versionheader unless the default version is set, as described in the next paragraph.If a request to Blob Storage doesn't include an
x-ms-versionheader, but the account owner sets a default version by using the Set Blob Service Properties operation, the specified default version is used as the version for the request.
Authorize requests by using a shared access signature
A shared access signature (SAS) that's generated by using version 2014-02-14 or later supports two versioning options:
The
api-versionquery parameter defines the REST protocol version to use for processing a request that's made by using the SAS.The
SignedVersion (sv)query parameter defines the SAS version to use for authorization.
The SignedVersion query parameter is used for authorization when a client makes a request by using the SAS. Authorization parameters such as si, sr, sp, sig, st, se, tn, spk, srk, epk, and erk are all interpreted by using the specified version.
REST protocol parameters such as rscc, rscd, rsce, rscl, and rsct are enforced by using the version provided in the api-version parameter header. If the api-version header isn't specified, the service version provided for SignedVersion is used.
The api-version parameter isn't part of the string-to-sign in the authorization header, as described in Create a service SAS.
The following table explains the versioning scheme that's used by the service for authorization and for calling the REST protocol when the SignedVersion parameter is set to version 2014-02-14 or later.
| Value of api-version parameter | Version used for authorization | Version used for protocol behavior |
|---|---|---|
| Not specified | Version specified in the sv parameter |
Version specified in the sv parameter |
Any valid storage services version in format XXXX-XX-XX |
Version specified in the sv parameter |
Valid storage services version XXXX-XX-XX |
Example 1
The following sample request calls List Blobs with sv=2015-04-05, and without the api-version parameter.
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d
In this case, the service authenticates and authorizes the request by using version 2015-04-05, and it runs the operation by using version 2015-04-05.
Example 2
The following sample request calls List Blobs with sv=2015-04-05 and with the api-version parameter.
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2015-04-05&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d&api-version=2012-02-12
Here, the service authorizes the request by using version 2015-04-05, and it runs the operation by using version 2012-02-12.
Note
The .NET Storage client library always sets the REST protocol version (in the api-version parameter) to the base version.
Requests via anonymous access
Requests that are made via anonymous access are handled differently, depending on the type of storage account they're made against.
General-purpose storage accounts
If an anonymous request to a general-purpose storage account doesn't specify the x-ms-version header, and the default version for the service isn't set by using Set Blob Service Properties, the service uses the earliest possible version to process the request. If the container was made public using the Set Container ACL operation using version 2009-09-19 or later, the request is processed by using version 2009-09-19.
For Blob Storage accounts
If an anonymous request to a Blob Storage account doesn't specify the x-ms-version header, and the default version for the service isn't set by using Set Blob Service Properties, the service uses the earliest possible version to process the request. For a Blob Storage account, the earliest possible version is 2014-02-14.
Known issues
This section details known issues for the Azure Storage REST APIs.
InvalidHeaderValue error message
In rare scenarios, applications making direct REST API calls can receive an InvalidHeaderValue error message. The error looks similar to the following sample:
HTTP/1.1 400 The value for one of the HTTP headers is not in the correct format.
Content-Length: 328
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
x-ms-request-id: <REMOVED>
Date: Fri, 19 May 2023 17:10:33 GMT
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidHeaderValue</Code><Message>The value for one of the HTTP headers is not in the correct format.
RequestId:<REMOVED>
Time:2023-05-19T17:10:34.2972651Z</Message><HeaderName>x-ms-version</HeaderName><HeaderValue>yyyy-mm-dd</HeaderValue></Error>
Using an earlier REST API version to attempt to resolve the issue is recommended. If the issue persists, or if the recommendation isn't feasible, please open a support ticket to discuss further options.