diff --git a/doc/source/api/form_post_middleware.rst b/doc/source/api/form_post_middleware.rst
index 482be1c5e5..272fa59899 100644
--- a/doc/source/api/form_post_middleware.rst
+++ b/doc/source/api/form_post_middleware.rst
@@ -1,3 +1,5 @@
+.. _formpost:
+
 ====================
 Form POST middleware
 ====================
@@ -8,12 +10,13 @@ path.
 
 You can upload objects directly to the Object Storage system from a
 browser by using the form **POST** middleware. This middleware uses
-account secret keys to generate a cryptographic signature for the
+account or container secret keys to generate a cryptographic signature for the
 request. This means that you do not need to send an authentication token
 in the ``X-Auth-Token`` header to perform the request.
 
 The form **POST** middleware uses the same secret keys as the temporary
-URL middleware uses. For information about how to set these keys, see account secret keys.
+URL middleware uses. For information about how to set these keys, see
+:ref:`secret_keys`.
 
 For information about the form **POST** middleware configuration
 options, see `Form
diff --git a/doc/source/api/temporary_url_middleware.rst b/doc/source/api/temporary_url_middleware.rst
index 75b909abf2..f606b0b8c0 100644
--- a/doc/source/api/temporary_url_middleware.rst
+++ b/doc/source/api/temporary_url_middleware.rst
@@ -23,9 +23,7 @@ Note
 ~~~~
 
 To use **POST** requests to upload objects to specific Object Storage
-locations, use form **POST** instead of temporary URL middleware. See
-`Form POST <http://docs.openstack.org/havana/config-reference/content/object-storage-form-post.html>`__
-in the *OpenStack Configuration Reference*.
+locations, use :doc:`form_post_middleware` instead of temporary URL middleware.
 
 Temporary URL format
 ~~~~~~~~~~~~~~~~~~~~
@@ -64,23 +62,34 @@ object name. Object Storage returns this value in the ``Content-Disposition``
 response header. Browsers can interpret this file name value as a file
 attachment to be saved.
 
-Account secret keys
-~~~~~~~~~~~~~~~~~~~
+.. _secret_keys:
 
-Object Storage supports up to two secret keys. You set secret keys at
-the account level.
+Secret Keys
+~~~~~~~~~~~
 
-To set these keys, set one or both of the following request headers to
-arbitrary values:
+The cryptographic signature used in Temporary URLs and also in
+:doc:`form_post_middleware` uses a secret key. Object Storage allows you to
+store four secret key values. Two are stored at the account level and two
+are stored at the container level. When validating a request,
+Object Storage checks signatures against all keys. Using two keys at
+each level enables key rotation without invalidating existing temporary URLs.
+
+To set the keys at the account level, set one or both of the following
+request headers to arbitrary values on a **POST** request to the account:
 
 -  ``X-Account-Meta-Temp-URL-Key``
 
 -  ``X-Account-Meta-Temp-URL-Key-2``
 
-The arbitrary values serve as the secret keys.
+To set the keys at the container level, set one or both of the following
+request headers to arbitrary values on a **POST** or **PUT** request to the
+container:
 
-Object Storage checks signatures against both keys, if present, to
-enable key rotation without invalidating existing temporary URLs.
+-  ``X-Container-Meta-Temp-URL-Key``
+
+-  ``X-Container-Meta-Temp-URL-Key-2``
+
+The arbitrary values serve as the secret keys.
 
 For example, use the **swift post** command to set the secret key to
 *``MYKEY``*:
@@ -112,8 +121,8 @@ signature includes these elements:
    ``/v1/my_account/container/object``. Do not URL-encode the path at
    this stage.
 
--  The secret key. Set as the ``X-Account-Meta-Temp-URL-Key`` header
-   value.
+-  The secret key. Use one of the key values as described
+   in :ref:`secret_keys`.
 
 This sample Python code shows how to compute a signature for use with
 temporary URLs:
@@ -138,8 +147,8 @@ Do not URL-encode the path when you generate the HMAC-SHA1 signature.
 However, when you make the actual HTTP request, you should properly
 URL-encode the URL.
 
-The *``MYKEY``* value is the value you set in the
-``X-Account-Meta-Temp-URL-Key`` request header on the account.
+The *``MYKEY``* value is one of the key values as described
+in :ref:`secret_keys`.
 
 For more information, see `RFC 2104: HMAC: Keyed-Hashing for Message
 Authentication <http://www.ietf.org/rfc/rfc2104.txt>`__.