> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/get-started/sdks/errors.md).

# SDK errors

The IDlayr iOS and Android SDKs can return errors **before any HTTP request reaches IDlayr** — for example when the device has no cellular data path, or when a redirect URL fails to parse. These are **client-side conditions** surfaced by the SDK and are distinct from the HTTP errors returned by the IDlayr API (which follow RFC 7807).

The error codes are **standardised across iOS and Android** — same names, same semantics, so cross-platform error handling can share the same branching.

## Error code reference

| `error_code`               | Platform     | Meaning                                                                                                                                                                                | Recommended action                                                                                                                                                                                                      |
| -------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sdk_no_data_connectivity` | iOS, Android | Device has no cellular data path. The SDK refused to make the request because no mobile-network interface is available (airplane mode, eSIM not provisioned, Wi-Fi-only tablet, etc.). | Surface a "no mobile connection" message to the user. Fall back to an alternative verification path — for example, [Reverse SMS](/products/number-verification/reverse-sms.md), which doesn't need cellular data.       |
| `sdk_connection_error`     | iOS, Android | Network-level failure during the request (socket closed, TLS handshake failed, abrupt disconnect).                                                                                     | Retry once after a short delay. If it persists, surface a generic "network problem" message and offer fallback.                                                                                                         |
| `sdk_redirect_error`       | iOS, Android | Failure while following the verification redirect chain — too many hops, malformed `Location` header, scheme mismatch, or an unexpected response from a redirect target.               | This usually indicates a carrier-side or platform-level issue, not a client-side bug. Log the `debug` block if present and report to your IDlayr account team for investigation. Fall back to alternative verification. |
| `sdk_error`                | iOS, Android | Generic SDK failure not covered by the more specific codes.                                                                                                                            | Treat as a transient failure. Retry once; if it persists, fall back. Report to your IDlayr account team with the debug trace.                                                                                           |
| `invalid_scheme`           | iOS, Android | A URL in the redirect chain was not HTTPS. The SDK rejects plain-HTTP hops in the verification path — this is a hard security boundary.                                                | Should never appear in production with a healthy IDlayr backend. If you see it, the verification URL was tampered with or the carrier inserted a non-TLS hop. Treat as a hard failure and report.                       |

## Where SDK errors surface

| Platform | Surface                                                                                                             |
| -------- | ------------------------------------------------------------------------------------------------------------------- |
| iOS      | `response["error"]` and `response["error_description"]` keys in the completion handler's response dictionary.       |
| Android  | The callback parameter on the SDK method — exact field name documented per product on the Android integration page. |

For per-product integration shape — how to wire the response handler, how to read the result, fallback patterns — see each product's iOS / Android integration page.

## SDK errors are not HTTP errors

SDK errors have **no `status`, no `http_status`, and no RFC 7807 `problem+json` representation**. They are raised by the SDK locally; the IDlayr platform never sees them and they don't generate callbacks. If you also configured a callback URL, the check on the IDlayr side will eventually time out (`status: EXPIRED`) — but the actionable signal is the SDK error from the device side.

For the HTTP-side error catalogue — the codes the IDlayr API returns once a request does reach it — see the API Reference errors section.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.idlayr.com/get-started/sdks/errors.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.