Put Message operation adds a new message to the back of the message queue. A visibility time-out can also be specified to make the message invisible until the visibility time-out expires. A message must be in a format that can be included in an XML request with UTF-8 encoding. The encoded message can be up to 64 kibibytes (KiB) in size for version 2011-08-18 and later, or 8 KiB for earlier versions.
You can construct the
Put Message request as follows. We recommend that you use HTTPS. Replace myaccount with the name of your storage account, and
myqueue with the name of your queue:
|Method||Request URI||HTTP version|
Emulated storage service request
When you're making a request against the emulated storage service, specify the emulator hostname and Queue storage port as
127.0.0.1:10001, followed by the emulated storage account name:
|Method||Request URI||HTTP version|
For more information, see Use the Azurite emulator for local Azure Storage development.
You can specify the following parameters on the request URI:
||Optional. Specifies the new visibility time-out value, in seconds, relative to server time. If it's specified, the request must be made by using an
||Optional. Specifies the time-to-live interval for the message, in seconds. In versions earlier than 2017-07-29, the maximum time-to-live allowed is 7 days. For version 2017-07-29 and later, the maximum time-to-live can be any positive number, and
The required and optional request headers are described in the following table:
||Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.|
||Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage.|
||Optional. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage services.|
||Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives.|
The body of the request contains the message data in the following XML format. Note that the message content must be in a format that can be encoded with UTF-8.
<QueueMessage> <MessageText>message-content</MessageText> </QueueMessage>
Request: POST https://myaccount.queue.core.windows.net/messages?visibilitytimeout=30&timeout=30 HTTP/1.1 Headers: x-ms-version: 2011-08-18 x-ms-date: Tue, 30 Aug 2011 01:03:21 GMT Authorization: SharedKey myaccount:sr8rIheJmCd6npMSx7DfAY3L//V3uWvSXOzUBCV9wnk= Content-Length: 100 Body: <QueueMessage> <MessageText>PHNhbXBsZT5zYW1wbGUgbWVzc2FnZTwvc2FtcGxlPg==</MessageText> </QueueMessage>
The response includes an HTTP status code and a set of response headers.
A successful operation returns status code 201 (Created).
For more information about status codes, see Status and error codes.
The response for this operation includes the following headers. The response may also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.
||Uniquely identifies the request that was made, and you can use it to troubleshoot the request. For more information, see Troubleshoot API operations.|
||Indicates the Queue service version that was used to execute the request. This header is returned for requests that were made against version 2009-09-19 and later.|
||A UTC date/time value that's generated by the service, which indicates the time when the response was initiated.|
||This header can be used to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the
As of version 2016-05-31, the response for the
Put Message operation contains the message info in the response body. The XML format of the returned body is described here.
MessageID element is a GUID value that identifies the message in the queue. This value is assigned to the message by Queue Storage and is opaque to the client. This value may be used together with the value of the PopReceipt element to delete or update a message from the queue. The value of PopReceipt is also opaque to the client, and it's required when you're using the Delete Message or Update Message APIs.
TimeNextVisible elements are represented as UTC values and formatted as described in RFC 1123.
<QueueMessagesList> <QueueMessage> <MessageId>string-message-id</MessageId> <InsertionTime>insertion-time</InsertionTime> <ExpirationTime>expiration-time</ExpirationTime> <PopReceipt>opaque-string-receipt-data</PopReceipt> <TimeNextVisible>time-next-visible</TimeNextVisible> </QueueMessage> </QueueMessagesList>
Response Status: HTTP/1.1 200 OK Response headers: Transfer-Encoding: chunked Content-Type: application/xml x-ms-version: 2016-05-31 Date: Fri, 09 Oct 2016 21:04:30 GMT Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0 Response Body: <?xml version="1.0" encoding="utf-8"?> <QueueMessagesList> <QueueMessage> <MessageId>5974b586-0df3-4e2d-ad0c-18e3892bfca2</MessageId> <InsertionTime>Fri, 09 Oct 2016 21:04:30 GMT</InsertionTime> <ExpirationTime>Fri, 16 Oct 2016 21:04:30 GMT</ExpirationTime> <PopReceipt>YzQ4Yzg1MDItYTc0Ny00OWNjLTkxYTUtZGM0MDFiZDAwYzEw</PopReceipt> <TimeNextVisible>Fri, 09 Oct 2016 23:29:20 GMT</TimeNextVisible> </QueueMessage> </QueueMessagesList>
This operation can be performed by the account owner and by anyone with a shared access signature with permissions to perform this operation.
The optional visibility time-out specifies the time that the message is invisible. After the time-out expires, the message becomes visible. If you don't specify a visibility time-out, the default value of 0 is used.
The optional message time-to-live specifies how long a message remains in the queue. The message is deleted from the queue when the time-to-live period expires.
A message must be in a format that can be included in an XML request with UTF-8 encoding. To include markup in the message, the contents of the message must either be XML-escaped or Base64-encode. Any XML markup in the message that isn't escaped or encoded is removed before the message is added to the queue.
If the message is too large, the service returns status code 400 (Bad Request).