diff --git a/guides/contexts.md b/guides/contexts.md
index 531a4bcc4d..d605c9ce39 100644
--- a/guides/contexts.md
+++ b/guides/contexts.md
@@ -158,7 +158,7 @@ end
 
 We've seen how controllers work in our [controller guide](controllers.html), so the code probably isn't too surprising. What is worth noticing is how our controller calls into the `Accounts` context. We can see that the `index` action fetches a list of users with `Accounts.list_users/0`, and how users are persisted in the `create` action with `Accounts.create_user/1`. We haven't yet looked at the accounts context, so we don't yet know how user fetching and creation is happening under the hood – *but that's the point*. Our Phoenix controller is the web interface into our greater application. It shouldn't be concerned with the details of how users are fetched from the database or persisted into storage. We only care about telling our application to perform some work for us. This is great because our business logic and storage details are decoupled from the web layer of our application. If we move to a full-text storage engine later for fetching users instead of a SQL query, our controller doesn't need to be changed. Likewise, we can reuse our context code from any other interface in our application, be it a channel, mix task, or long-running process importing CSV data.
 
-In the case of our `create` action, when we successfully create a user, we use `Phoenix.Controller.put_flash/2` to show a success message, and then we redirect to the `user_path`'s show page. Conversely, if `Accounts.create_user/1` fails, we render our `"new.html"` template and pass along the Ecto changeset for the template to lift error messages from.
+In the case of our `create` action, when we successfully create a user, we use `Phoenix.Controller.put_flash/3` to show a success message, and then we redirect to the `user_path`'s show page. Conversely, if `Accounts.create_user/1` fails, we render our `"new.html"` template and pass along the Ecto changeset for the template to lift error messages from.
 
 Next, let's dig deeper and check out our `Accounts` context in `lib/hello/accounts/accounts.ex`:
 
diff --git a/lib/phoenix/presence.ex b/lib/phoenix/presence.ex
index e16c2581b2..6fa582a80f 100644
--- a/lib/phoenix/presence.ex
+++ b/lib/phoenix/presence.ex
@@ -369,7 +369,7 @@ defmodule Phoenix.Presence do
 
   ## Examples
 
-  Uses the same data format as `Phoenix.Presence.list/1`, but only
+  Uses the same data format as `Phoenix.Presence.list/2`, but only
   returns metadata for the presences under a topic and key pair. For example,
   a user with key `"user1"`, connected to the same chat room `"room:1"` from two
   devices, could return:
@@ -377,7 +377,7 @@ defmodule Phoenix.Presence do
       iex> MyPresence.get_by_key("room:1", "user1")
       %{name: "User 1", metas: [%{device: "Desktop"}, %{device: "Mobile"}]}
 
-  Like `Phoenix.Presence.list/1`, the presence metadata is passed to the `fetch`
+  Like `Phoenix.Presence.list/2`, the presence metadata is passed to the `fetch`
   callback of your presence module to fetch any additional information.
   """
   def get_by_key(module, topic, key) do