Mobile Flow Errors

Errors you'll encounter in mobile-initiated flows and how to handle them.

All Error UI Is Your Responsibility

On mobile, the SDK does not display any success or error UI. Your application receives the result (or error) through the SDK callback and you control what the user sees.

Frontend SDK Error Categories

These are the error categories your frontend code will catch when using the web client SDK. Handle by category rather than individual codes for a more robust integration.

User Cancelled

Retryable from user gesture

The user dismissed the consent prompt (TS.43) or closed the App Clip card (Link). The browser may also report this as a NotAllowedError.

Handle: Show a button to try again. The retry must come from a user click since the browser blocks programmatic re-invocation.

Browser / Platform Not Supported

Not retryable

The browser doesn't support the Digital Credentials API, or the authentication strategy is not available on this platform.

Handle: Offer a fallback authentication method (e.g., SMS OTP). Don't retry the same flow.

Validation Errors

Not retryable without fixing input

The request is missing required parameters or the phone number format is invalid. These are caught before any network request is made.

Handle: Show an input error to the user so they can correct the value.

Network / Timeout

Retryable

The network request failed or timed out. You can check the error code field for NETWORK_ERROR or TIMEOUT to identify these.

Handle: Auto-retry a few times with backoff. If still failing, show a connectivity error and let the user try again.

Backend Errors (passed through)

Varies by error

Errors from Glide's backend are passed through the SDK with the original error code and HTTP status. These include session errors, verification failures, carrier eligibility, and server errors.

Handle: Check the status field. 4xx errors are typically not retryable (fix the request). 5xx errors can be retried once. See the category table for details.

User Dismissal by Platform

When the user dismisses the authentication prompt, the error details vary by platform.

PlatformWhat HappensHow to Retry
Android (TS.43)SDK receives a user cancelled error with browser error detailsCall invokeSecurePrompt() again from a user click
iOS (App Clip)No cancellation signal is received. The SDK continues waiting until timeout.Always show a CTA to retry while waiting for a result

iOS has no dismissal event. When a user closes the App Clip, your app does not receive any signal. The SDK will keep waiting until the session times out. For this reason, always display a retry CTA alongside the loading state so the user can re-trigger the flow without waiting for a timeout. The CTA should call invokeSecurePrompt() from a user click.

Both platforms require a user gesture (click/tap) to re-invoke. The browser blocks programmatic re-invocation of the Digital Credentials API and App Clip launches.

Example: Handling Errors

import { isAuthError, ERROR_CODES } from '@glideidentity/glide-fe-sdk-web';

try {
  const result = await authenticate(request);
} catch (err) {
  if (isAuthError(err)) {
    switch (err.code) {
      case ERROR_CODES.USER_CANCELLED:
        // User dismissed - show try again button
        showTryAgainButton();
        break;
      case ERROR_CODES.NETWORK_ERROR:
      case ERROR_CODES.TIMEOUT:
        // Network or timeout - safe to auto-retry
        showRetryUI();
        break;
      case ERROR_CODES.BROWSER_NOT_SUPPORTED:
        // Offer fallback auth
        showFallbackAuth();
        break;
      default:
        // Other errors - show friendly message
        showError(err.message);
    }
  }
}