diff --git a/website/source/docs/agent/http/coordinate.html.markdown b/website/source/docs/agent/http/coordinate.html.markdown
index 06e9f10673..04a16b3920 100644
--- a/website/source/docs/agent/http/coordinate.html.markdown
+++ b/website/source/docs/agent/http/coordinate.html.markdown
@@ -25,7 +25,7 @@ The following endpoints are supported:
 
 ### <a name="coordinate_datacenters"></a> /v1/coordinate/datacenters
 
-This endpoint is hit with a GET and returns the WAN network coordinates for
+This endpoint is hit with a `GET` and returns the WAN network coordinates for
 all Consul servers, organized by DCs.
 
 It returns a JSON body like this:
@@ -55,9 +55,9 @@ cluster. Also, it does not support blocking queries or any consistency modes.
 
 ### <a name=""coordinate_nodes></a> /v1/coordinate/nodes
 
-This endpoint is hit with a GET and returns the LAN network coordinates for
+This endpoint is hit with a `GET` and returns the LAN network coordinates for
 all nodes in a given DC. By default, the datacenter of the agent is queried;
-however, the dc can be provided using the "?dc=" query parameter.
+however, the `dc` can be provided using the `?dc=` query parameter.
 
 It returns a JSON body like this:
 
diff --git a/website/source/docs/agent/http/event.html.markdown b/website/source/docs/agent/http/event.html.markdown
index dc91ef2758..f1b1554c62 100644
--- a/website/source/docs/agent/http/event.html.markdown
+++ b/website/source/docs/agent/http/event.html.markdown
@@ -24,11 +24,11 @@ needs a `name`, provided on the path. The endpoint also supports several
 optional parameters on the query string.
 
 By default, the agent's local datacenter is used, but another datacenter
-can be specified using the "?dc=" query parameter.
+can be specified using the `?dc=` query parameter.
 
-The fire endpoint expects a PUT request with an optional body.
+The fire endpoint expects a `PUT` request with an optional body.
 The body contents are opaque to Consul and become the "payload"
-of the event. Names starting with the "_" prefix should be considered
+of the event. Names starting with the `_` prefix should be considered
 reserved for Consul's internal use.
 
 The `?node=`, `?service=`, and `?tag=` query parameters may optionally
@@ -54,7 +54,7 @@ The `ID` field uniquely identifies the newly fired event.
 
 ### <a name="event_list"></a> /v1/event/list
 
-This endpoint is hit with a GET and returns the most recent
+This endpoint is hit with a `GET` and returns the most recent
 events known by the agent. As a consequence of how the
 [event command](/docs/commands/event.html) works, each agent
 may have a different view of the events. Events are broadcast using
diff --git a/website/source/docs/agent/http/health.html.markdown b/website/source/docs/agent/http/health.html.markdown
index b32857a8c1..9c8767ef71 100644
--- a/website/source/docs/agent/http/health.html.markdown
+++ b/website/source/docs/agent/http/health.html.markdown
@@ -24,9 +24,9 @@ All of the health endpoints support blocking queries and all consistency modes.
 
 ### <a name="health_node"></a> /v1/health/node/\<node\>
 
-This endpoint is hit with a GET and returns the checks specific to the node
+This endpoint is hit with a `GET` and returns the checks specific to the node
 provided on the path. By default, the datacenter of the agent is queried;
-however, the dc can be provided using the "?dc=" query parameter.
+however, the `dc` can be provided using the `?dc=` query parameter.
 
 It returns a JSON body like this:
 
@@ -56,7 +56,7 @@ It returns a JSON body like this:
 ```
 
 In this case, we can see there is a system level check (that is, a check with
-no associated `ServiceID`) as well as a service check for Redis. The "serfHealth" check
+no associated `ServiceID`) as well as a service check for Redis. The `serfHealth` check
 is special in that it is automatically present on every node. When a node
 joins the Consul cluster, it is part of a distributed failure detection
 provided by Serf. If a node fails, it is detected and the status is automatically
@@ -66,13 +66,13 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="health_checks"></a> /v1/health/checks/\<service\>
 
-This endpoint is hit with a GET and returns the checks associated with
+This endpoint is hit with a `GET` and returns the checks associated with
 the service provided on the path. By default, the datacenter of the agent is queried;
-however, the dc can be provided using the "?dc=" query parameter.
+however, the `dc` can be provided using the `?dc=` query parameter.
 
-Adding the optional "?near=" parameter with a node name will sort
+Adding the optional `?near=` parameter with a node name will sort
 the node list in ascending order based on the estimated round trip
-time from that node. Passing "?near=_agent" will use the agent's
+time from that node. Passing `?near=_agent` will use the agent's
 node for the sort.
 
 It returns a JSON body like this:
@@ -96,23 +96,23 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="health_service"></a> /v1/health/service/\<service\>
 
-This endpoint is hit with a GET and returns the nodes providing
+This endpoint is hit with a `GET` and returns the nodes providing
 the service indicated on the path. By default, the datacenter of the agent is queried;
-however, the dc can be provided using the "?dc=" query parameter.
+however, the `dc` can be provided using the `?dc=` query parameter.
 
-Adding the optional "?near=" parameter with a node name will sort
+Adding the optional `?near=` parameter with a node name will sort
 the node list in ascending order based on the estimated round trip
-time from that node. Passing "?near=_agent" will use the agent's
+time from that node. Passing `?near=_agent` will use the agent's
 node for the sort.
 
 By default, all nodes matching the service are returned. The list can be filtered
 by tag using the "?tag=" query parameter.
 
-Providing the "?passing" query parameter, added in Consul 0.2, will filter results
-to only nodes with all checks in the `passing` state. This can be used to avoid extra filtering
-logic on the client side.
+Providing the `?passing` query parameter, added in Consul 0.2, will
+filter results to only nodes with all checks in the `passing` state.
+This can be used to avoid extra filtering logic on the client side.
 
-This endpoint is very similar to the /v1/catalog/service endpoint; however, this
+This endpoint is very similar to the `/v1/catalog/service` endpoint; however, this
 endpoint automatically returns the status of the associated health check
 as well as any system level health checks. This allows a client to avoid
 sending traffic to nodes that are failing health tests or reporting warnings.
@@ -170,13 +170,13 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="health_state"></a> /v1/health/state/\<state\>
 
-This endpoint is hit with a GET and returns the checks in the
+This endpoint is hit with a `GET` and returns the checks in the
 state provided on the path. By default, the datacenter of the agent is queried;
-however, the dc can be provided using the "?dc=" query parameter.
+however, the `dc` can be provided using the `?dc=` query parameter.
 
-Adding the optional "?near=" parameter with a node name will sort
+Adding the optional `?near=` parameter with a node name will sort
 the node list in ascending order based on the estimated round trip
-time from that node. Passing "?near=_agent" will use the agent's
+time from that node. Passing `?near=_agent` will use the agent's
 node for the sort.
 
 The supported states are `any`, `passing`, `warning`, or `critical`.
diff --git a/website/source/docs/agent/http/session.html.markdown b/website/source/docs/agent/http/session.html.markdown
index fcd09b3483..cc0dc61a39 100644
--- a/website/source/docs/agent/http/session.html.markdown
+++ b/website/source/docs/agent/http/session.html.markdown
@@ -26,7 +26,7 @@ The create endpoint is used to initialize a new session.
 There is more documentation on sessions [here](/docs/internals/sessions.html).
 Sessions must be associated with a node and may be associated with any number of checks.
 
-The create endpoint expects a JSON request body to be PUT. The request
+The create endpoint expects a JSON request body to be `PUT`. The request
 body must look like:
 
 ```javascript
@@ -44,10 +44,10 @@ None of the fields are mandatory, and in fact no body needs to be PUT
 if the defaults are to be used.
 
 By default, the agent's local datacenter is used; another datacenter
-can be specified using the "?dc=" query parameter. However, it is not recommended
+can be specified using the `?dc=` query parameter. However, it is not recommended
 to use cross-datacenter sessions.
 
-`LockDelay` can be specified as a duration string using a "s" suffix for
+`LockDelay` can be specified as a duration string using an `s` suffix for
 seconds. The default is 15s.
 
 `Node` must refer to a node that is already registered, if specified. By default,
@@ -64,7 +64,7 @@ causing any locks that are held to be released. Changing this to `delete`
 causes any locks that are held to be deleted. `delete` is useful for creating ephemeral
 key/value entries.
 
-The `TTL` field is a duration string, and like `LockDelay` it can use "s" as
+The `TTL` field is a duration string, and like `LockDelay` it can use `s` as
 a suffix for seconds. If specified, it must be between 10s and 86400s currently.
 When provided, the session is invalidated if it is not renewed before the TTL
 expires. The lowest practical TTL should be used to keep the number of managed
@@ -83,7 +83,7 @@ The return code is 200 on success and returns the ID of the created session:
 
 ### <a name="session_destroy"></a> /v1/session/destroy/\<session\>
 
-The destroy endpoint is hit with a PUT and destroys the given session.
+The destroy endpoint is hit with a `PUT` and destroys the given session.
 By default, the local datacenter is used, but the `?dc=` query parameter
 can be used to specify the datacenter.
 
@@ -93,7 +93,7 @@ The return code is 200 on success.
 
 ### <a name="session_info"></a> /v1/session/info/\<session\>
 
-This endpoint is hit with a GET and returns the requested session information
+This endpoint is hit with a `GET` and returns the requested session information
 within a given datacenter. By default, the datacenter of the agent is queried;
 however, the dc can be provided using the `?dc=` query parameter.
 The session being queried must be provided on the path.
@@ -119,7 +119,7 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="session_node"></a> /v1/session/node/\<node\>
 
-This endpoint is hit with a GET and returns the active sessions
+This endpoint is hit with a `GET` and returns the active sessions
 for a given node and datacenter. By default, the datacenter of the agent is queried;
 however, the dc can be provided using the `?dc=` query parameter.
 
@@ -146,7 +146,7 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="session_list"></a> /v1/session/list
 
-This endpoint is hit with a GET and returns the active sessions
+This endpoint is hit with a `GET` and returns the active sessions
 for a given datacenter. By default, the datacenter of the agent is queried;
 however, the dc can be provided using the `?dc=` query parameter.
 
@@ -171,7 +171,7 @@ This endpoint supports blocking queries and all consistency modes.
 
 ### <a name="session_renew"></a> /v1/session/renew/\<session\>
 
-The renew endpoint is hit with a PUT and renews the given session.
+The renew endpoint is hit with a `PUT` and renews the given session.
 This is used with sessions that have a TTL, and it extends the
 expiration by the TTL. By default, the local datacenter is used, but the `?dc=`
 query parameter can be used to specify the datacenter.
diff --git a/website/source/docs/agent/http/snapshot.html.markdown b/website/source/docs/agent/http/snapshot.html.markdown
index c94968cc43..9c5d86cb59 100644
--- a/website/source/docs/agent/http/snapshot.html.markdown
+++ b/website/source/docs/agent/http/snapshot.html.markdown
@@ -51,11 +51,11 @@ internal to Consul and not intended to be used other than for restore operations
 In particular, the archives are not designed to be modified before a restore.
 
 By default, the datacenter of the agent is queried; however, the `dc` can be
-provided using the "?dc=" query parameter.
+provided using the `?dc=` query parameter.
 
 By default, snapshots use consistent mode which means the request is internally
 forwarded to the cluster leader, and leadership is checked before performing the
-snapshot. If `stale` is specified using the "?stale" query parameter, then any
+snapshot. If `stale` is specified using the `?stale` query parameter, then any
 server can handle the request and the results may be arbitrarily stale. To support
 bounding the acceptable staleness of snapshots, responses provide the `X-Consul-LastContact`
 header containing the time in milliseconds that a server was last contacted by
@@ -83,7 +83,7 @@ intended to be used when recovering from a disaster, restoring into a fresh
 cluster of Consul servers.
 
 By default, the datacenter of the agent is targeted; however, the `dc` can be
-provided using the "?dc=" query parameter.
+provided using the `?dc=` query parameter.
 
 If ACLs are enabled, the client will need to supply an ACL Token with management
 privileges.