Implement Network Requests and Data Fetching

Expo Networking is the official Expo skill for any networking work in an Expo or React Native app: API requests, data fetching, caching, authentication, offline behavior and network debugging. It is published under the MIT license by the Expo team, and it is meant to be applied to any networking work in a project. Its guidance is organized around common issues:

• Fetch basics: use the fetch API with an explicit response.ok check, a JSON Content-Type and Authorization header on POST requests, and prefer expo/fetch over axios.
• React Query (TanStack Query): a QueryClient in the root layout with example defaults of a 5-minute staleTime and 2 retries, useQuery for reads with a queryKey, and useMutation with invalidateQueries on success. It recommends React Query for complex apps and SWR or custom hooks for simpler needs, and notes that React Query deduplicates requests and cancels them automatically on unmount or invalidation.
• Error handling: a typed ApiError carrying status and code, a wrapper that turns non-OK responses and network failures (status 0, code NETWORK_ERROR) into typed errors, and a retry helper with exponential backoff (3 attempts, waiting 2 to the power of the attempt number in seconds).
• Authentication: store tokens with expo-secure-store, never in AsyncStorage, wrap fetch to attach a Bearer token, and refresh tokens through a single shared in-flight promise so concurrent requests do not each trigger a refresh.
• Offline support: track connectivity with @react-native-community/netinfo, and connect NetInfo to React Query's onlineManager so queries pause when offline and resume when online. React Query persistence handles queued or cached data.
• Environment variables: variables prefixed EXPO_PUBLIC_ are inlined into the client bundle at build time, use .env.development and .env.production for different API URLs, and need a dev-server restart after changes. Secrets must never carry the prefix; server-side secrets belong in unprefixed variables used only in API routes. A small API client can throw at startup if EXPO_PUBLIC_API_URL is missing, and a ProcessEnv declaration adds TypeScript types.
• Cancellation: an AbortController aborts the request when a component unmounts, ignoring AbortError.

A decision tree maps each question to an answer: basic fetch to the fetch API with error handling, caching to React Query with staleTime, token storage to expo-secure-store, offline to NetInfo, environment config to EXPO_PUBLIC_ and .env files, and performance to caching, deduplication and cancellation.

Use it when implementing or debugging any network request or API call, setting up React Query or SWR, using Expo Router data loaders, handling authentication tokens, designing caching or offline behavior, or configuring API URLs and environment variables. Typical questions: how to make API calls in React Native, React Query versus SWR, making the app work offline, handling auth tokens, why API calls are slow, and where an API key belongs. Client-safe keys go in prefixed public variables in the environment file, and secret keys go in unprefixed variables used only in API routes.

It is not a substitute for environment-specific tests, security review, or approval for costly or destructive actions, and commands, API behavior, quotas and credentials should be checked against current official documentation.

Inputs are the app's networking need, the Expo SDK version and the deployment target. Outputs are TypeScript code for fetch helpers, query setup, auth wrappers and loaders. Two mistakes are called out. Fetching without a status check is wrong; the right pattern is:

const response = await fetch(url);
if (!response.ok) throw new Error(`HTTP ${response.status}`);
const data = await response.json();

Likewise, storing tokens in AsyncStorage is not secure; use SecureStore.setItemAsync.

Expo Router loaders provide route-level data loading on web with Expo SDK 55 or later, following the Remix and React Router loader model. A loader is an async function exported from a route file and read with useLoaderData from expo-router. Initial page loads run it on the server and embed the JSON in the HTML, while client navigation fetches it over HTTP. Configuration needs web.output set to "server" (loader runs on every request, full request access including headers and cookies, hosting on a Node.js server such as EAS Hosting, requiring both unstable_useServerDataLoaders and unstable_useServerRendering) or "static" (loader runs at build time, no request, any static host, only unstable_useServerDataLoaders). Dynamic routes use the LoaderFunction<T> type from expo-server, where params hold path parameters only and query parameters come from new URL(request.url).searchParams. StatusError raises HTTP errors, setResponseHeaders sets headers such as Cache-Control, a Suspense boundary must sit above the component calling useLoaderData, and an exported ErrorBoundary catches loader failures. Loaders cannot be used in _layout files, must return JSON-serializable values only, and their data is currently cached for the session, a known limitation. For native apps, use React Query or fetch instead.

It covers React Query, SWR, expo-secure-store, @react-native-community/netinfo, expo-router, expo-server, EAS Hosting and static hosts such as Netlify, Vercel and S3.

It suits Expo and React Native developers who need dependable patterns for API calls, caching, authentication, offline support and Expo Router data loading.