What is the expected user experience and recovery path in the Ring app if our Account Link URL is temporarily unavailable during account linking, such as from a deployment or outage? Specifically, does Ring show a defined error to the user, does it retry or allow the user to resume the same linking attempt, and is there a recommended way for partners to recover without requiring the user to restart the flow from the Ring App Store?
Hello, thank you for reaching out. I have forwarded your question to our engineers and am awaiting a response. As soon as I have any information I will respond on this thread.
1. UX when the Account Link URL is unavailable
The error page the user sees is entirely within the partner’s own scope — Ring redirects the user’s browser to the Account Link URL and has no control over what is displayed if that page is down. Partners are responsible for their own error handling and messaging at that endpoint.
2. Does Ring show a retry path?
Yes. The “Sign In” button remains present in the Ring App Store even if the linking attempt did not complete. The user does not need to navigate away or find a new entry point — they can simply tap Sign In again once the partner’s endpoint is back up.
3. Does the user need to restart from scratch?
No. The integration stays in a PENDING state, waiting for the user to complete the sign-in. There is no need to reinstall the app or re-initiate the flow from the App Store listing. The user picks up from where they left off.
Thanks — that helps. Just to clarify answer #1: if our Account Link URL itself is unavailable due to DNS/TLS/load balancer outage or a 5xx before our app can render anything, then we cannot display a partner-owned error page. In that case, should we assume the user only sees the Ring app/webview/browser-level failure page, and the supported recovery path is simply to tap Sign In again once our endpoint is restored?
Also, when you say the integration remains in PENDING state and the user does not need to restart from scratch, does tapping Sign In again reuse the same pending linking context/token, or does Ring generate a new account-linking request each time?
Hi Darrell, sorry for the delay. I will let you know as soon as I have an answer.
I am hoping the delay doesn’t mean there isn’t an answer 
Apologies for the delay on this. Here are the answers to your follow up questions:
On the browser level failure scenario:
Yes, that’s correct. If your Account Link URL is completely unreachable (DNS failure, TLS error, load balancer outage, etc.) before your app can render anything, the user will only see whatever their browser or the Ring in app webview displays for a failed navigation. Ring has no control over that page. The supported recovery path is simply for the user to tap Sign In again once your endpoint is restored.
Does tapping Sign In again reuse the same context, or generate a new one?
Ring generates a new authorization code and a new nonce each time the user taps Sign In. The original token from the first attempt remains stored on your backend as an unclaimed token (assuming your Token Exchange URL was reachable and processed it). When the user retries, a new token exchange fires and a new nonce redirect occurs. Your backend will then have multiple unclaimed tokens. The nonce matching algorithm handles this correctly by iterating through all unclaimed tokens to find the match.
The key point: the user does not need to uninstall or reinstall the app or reselect devices. They just tap Sign In again and a fresh linking attempt is initiated with new credentials. We recommend implementing cleanup of stale unclaimed tokens older than 10 to 15 minutes to keep your pool manageable.
1 Like