Network Request Monitoring for React Native (Plus What's New in SDK 1.11)

Your session replay shows a user tapping Checkout and then staring at a spinner. What you can't see is the request behind it — which endpoint they hit, how long it took, and whether it came back 200 or 500. As of vexo-analytics 1.11, you can. Vexo captures your app's network requests — URL, method, response time, and status — automatically, from the same vexo('YOUR_API_KEY') call that already powers screens, taps, and replay.

The headline of this release is which requests it captures. Install it with:

npm i vexo-analytics@1.11.0

Now covering axios, not just fetch

Here's the gap 1.11 closes. Vexo instruments the network by wrapping the request layer, and previously it only patched fetch. That's fine if your app uses fetch directly — but a large share of React Native apps use axios, and on React Native axios runs on the XMLHttpRequest (XHR) adapter, not fetch. So those apps got zero network telemetry, silently. No error, no warning — just an empty network tab that looked like the feature was off.

1.11 patches the XMLHttpRequest path as well, so both routes are covered:

If your app is an axios app, upgrading to 1.11 is the difference between an empty network view and a full one — without changing a line of your request code.

Automatic, non-fatal, and quiet about itself

Three properties matter when an SDK sits in the path of every request your app makes:

• It's automatic. Network capture turns on when vexo() runs. There's no separate interceptor to register and nothing to wrap around your API client — the instrumentation is installed once, globally.
• It can never break a request. The instrumentation is non-fatal by construction: it observes the request and its result, but if anything in the capture path itself goes wrong, your app's request still proceeds untouched. Vexo watching a call can never be the reason a call fails.
• Failed requests are marked. A request that errors or comes back with a failing status isn't dropped — it's recorded and flagged, so a spike of failures against one endpoint is something you can actually see.

One more detail worth knowing: Vexo keeps its own calls out of your data. The SDK maintains a host ignore-list so the requests it makes to Vexo's own backend don't show up as network traffic in your app's telemetry. You see your API, not our plumbing.

Also in 1.11

Network monitoring is the headline, but 1.11 ships a few more things worth putting in your init file.

Super properties: registerProperties

Some attributes belong on every event — the user's plan tier, the experiment bucket they're in, the app flavor. Instead of threading those through every customEvent() call, registerProperties registers them once and merges them into everything Vexo sends afterward:

import { registerProperties, customEvent } from 'vexo-analytics';

// Register once — merged into every event from here on.
registerProperties({ plan: 'pro', experiment: 'checkout-v2' });

// This event carries plan + experiment automatically.
customEvent('Add To Cart', { sku: 'ABC-123' });

Repeated calls accumulate rather than replace, so you can register the plan at login and the experiment bucket later without clobbering the first. If a per-event property collides with a global one, the per-event value wins — the property you pass to customEvent overrides the global for that event.

Session-replay sampling: sessionReplaySampleRate

If you don't need a recording of every session, 1.11 lets you sample. Pass sessionReplaySampleRate at init and Vexo records replay for that fraction of sessions:

import { vexo } from 'vexo-analytics';

// Record session replay for ~10% of sessions.
vexo('YOUR_API_KEY', { sessionReplaySampleRate: 0.1 });

The decision is made once per session, on the device — a session either records or it doesn't, no mid-session flipping. Crucially, this only samples the replay: event capture stays at 100%. You keep every screen, tap, custom event, and network request while recording video for a representative slice.

Manual screen tracking: trackScreen

Vexo auto-tracks screens for React Navigation and Expo Router. But if you're on react-native-navigation (the Wix library) or a custom navigator Vexo can't hook into automatically, trackScreen(name, properties?) lets you report screens yourself:

import { trackScreen } from 'vexo-analytics';

trackScreen('Checkout', { cartSize: 3 });

React Native 0.87 and Expo Router through SDK 57

1.11 adds support for React Native 0.87, and Expo Router is verified through Expo SDK 57 — so upgrading your app framework doesn't mean leaving Vexo behind.

Getting it

Upgrade to the current release:

Network monitoring, super properties, and replay sampling need nothing beyond the vexo() call you likely already have — network capture is automatic on init, and the two options above are set at init when you want them. It works with Expo (Development Build) and bare React Native alike; see the integration docs for the full reference, or the crash and error monitoring post for what shipped in 1.10.

Frequently Asked Questions