Skip to main content
The SDK reports problems in three ways, depending on how far it got: Both callbacks can fire more than once for the same problem, so keep them idempotent.

loadDoola() rejects

Auth errors

onAuthError receives { type, message }. The iframe shows the founder a matching message: “This session has ended”, “This email already has a doola account”, “We could not open your account” or “This account is no longer active”. mint_failed shows “We could not start your session” with Try again, and a session that went stale before the SDK mounted again shows “We lost your session” with Try again. After three failed tries, both read “Please contact the team you signed up with.” A 409 your route sent without a code shows “We could not start your session” with that line and no Try again, because the email may not be the cause and retrying will not help.

Load errors

onLoadError receives { type, message }. In every case but one, the iframe is running and shows its own error screen, so onLoadError is for your logging. Today the SDK reports only render_error. Log the other types too, so a release that starts sending them needs no change on your side.

render_error

When the iframe never starts, nothing inside it can show an error, and your page is the only place to tell the founder. That happens when:
  • your CSP’s frame-src refuses sdk.doola.com;
  • a browser extension or a network filter blocks the iframe;
  • the iframe’s page fails to load.
The SDK reports render_error within 20 seconds of mounting, or 5 seconds after the iframe’s page loads without starting. If it was full screen, it releases the overlay and your page’s scroll first. Keep the message, which says which case it was:

Partner API errors

Errors from your server’s calls to doola use the Partner API’s { payload, error } envelope and codes. The ones specific to the SDK flow: See Errors for the envelope and the codes every endpoint can return.
Last modified on October 8, 2026