1 files changed, 1 insertions, 1 deletions
diff --git a/46.md b/46.md
index 53be001..05719cb 100644
--- a/46.md
+++ b/46.md
@@ -71,7 +71,7 @@ The signer key will always be the key of the user who controls the signer device
 ### Auth URL response
 A signer can reply with a `result: "auth_url", error: "<url>"`. This response can provide an easier way for the user to authorize this client to perform an action. Clients can redirect/popup this URL so the user can take an action directly on the signer backend.
-When redirecting, the client can choose to add a `callbackUrl` query string parameter to tell the signer when to send the user after an action has been performed.
+When redirecting, the client can choose to add a `callbackUrl` query string parameter to tell the signer where to send the user after an action has been performed.
 #### Example flow:

diff --git a/46.md b/46.md index 53be001..05719cb 100644 --- a/46.md +++ b/46.md
@@ -71,7 +71,7 @@ The signer key will always be the key of the user who controls the signer device
71	### Auth URL response	71	### Auth URL response
72	A signer can reply with a `result: "auth_url", error: "<url>"`. This response can provide an easier way for the user to authorize this client to perform an action. Clients can redirect/popup this URL so the user can take an action directly on the signer backend.	72	A signer can reply with a `result: "auth_url", error: "<url>"`. This response can provide an easier way for the user to authorize this client to perform an action. Clients can redirect/popup this URL so the user can take an action directly on the signer backend.
73		73
74	When redirecting, the client can choose to add a `callbackUrl` query string parameter to tell the signer when to send the user after an action has been performed.	74	When redirecting, the client can choose to add a `callbackUrl` query string parameter to tell the signer where to send the user after an action has been performed.
75		75
76	#### Example flow:	76	#### Example flow:
77		77