What Is a Network Request Integration? How Apps Talk Without Official APIs

Every time you click "Export" or "Submit" on a web platform, a JavaScript function fires, constructs an HTTP request (a method, a URL, a set of headers, a JSON payload) and sends it to the platform's backend. The backend processes it and returns a structured response. The browser just renders the result.

A network request integration captures exactly that exchange and replays it on your schedule, without opening a browser. That is the architecture Integuru is built on. This post explains how it works, how to observe it in under five minutes with the tools already in your browser, and what production-grade handling actually requires.

What Is a Network Request Integration?

A network request integration is an integration that works by identifying, mapping, and programmatically reproducing the HTTP requests a web application makes to its backend, rather than interacting with the frontend UI. Instead of launching a browser and clicking through a page, you call the same backend endpoints the browser was calling, using the same methods, headers, and payloads, issued directly from your code.

The browser is a display layer. The actual work (reading records, submitting data, triggering actions) happens through HTTP requests the browser issues internally. A network request integration skips the display layer entirely and operates at the HTTP layer where the data actually moves.

The Anatomy of a Network Request

Every action a web application takes over the network has the same five-part structure. Understanding each component is the foundation for building or inspecting an integration.

1. Method: GET, POST, PUT, PATCH, or DELETE. The method signals intent to the server: read data, create a resource, update one, or remove it. Most write operations use POST or PATCH.

2. URL: the endpoint address, e.g. https://platform.example.com/api/v2/patients/schedule. The path encodes the resource; query parameters encode filters or pagination.

3. Headers: key-value pairs attached to the request. Content-Type: application/json tells the server how to parse the body. Authorization: Bearer <token> presents authentication credentials. Custom headers like X-CSRF-Token or X-Client-Version carry platform-specific metadata.

4. Request body: the JSON (or form-encoded) payload for write operations. This is the data you are sending: field values, IDs, configuration options.

5. Response: the server's reply: an HTTP status code (200 OK, 201 Created, 401 Unauthorized) plus a body, usually JSON, containing the result or an error message.

Modern browsers initiate these requests via two mechanisms: XMLHttpRequest (XHR), the older standard, and the Fetch API, the current standard. Both reach the same backend endpoints. From the server's perspective, there is no meaningful difference between a request from a browser's Fetch call and a request from your integration code.

Why the Network Layer Is the Right Integration Target

Selenium, Playwright, and other browser automation tools operate at the DOM layer. They launch a browser, load a full page, locate elements, and simulate clicks. The DOM layer is fragile because it changes every time a designer updates a button label or restructures a form. The backend HTTP interface changes far less frequently, because the engineering team maintains it for their own mobile clients, internal tooling, and any third parties who do have official access.

Three reasons network requests are the correct integration target:

• Stability. Backend endpoints outlive frontend redesigns. A visual overhaul that breaks every Selenium integration may leave a direct HTTP integration untouched.

• Structure. The request body and response are typed JSON, not text scraped from a rendered UI. You get structured data in, structured data out.

• Performance. Direct HTTP calls carry no page-load overhead. No Chromium process, no DOM rendering, no waiting for JavaScript to hydrate. Integuru-generated integrations average under 3 seconds per call.

A visual redesign that breaks every browser automation integration may leave a network request integration completely unaffected, because the backend team is not rewriting their API endpoints every time the frontend ships.

How to Observe Network Requests

Chrome DevTools is the standard starting point, and the first thing most engineers notice when they open it is how much the platform is telling them. Press F12, go to the Network tab, and filter by Fetch/XHR. Then log in and click through the workflow you want to automate. Within five minutes, every endpoint the platform uses, the exact URL, method, headers, and JSON payload, is sitting in the panel. Right-click any request and select Copy as cURL to export the full call as a terminal command you can paste and run immediately.

This is the non-obvious truth about private APIs: platforms cannot hide their network traffic from the browser. The JavaScript that powers the UI needs those endpoints to function, so the browser exposes them. The discovery step for most integrations takes minutes, not days.

What takes real engineering is the next part: handling session tokens that expire, CSRF values that regenerate per request, and the payload variations that only appear in production across real account states. For a full step-by-step walkthrough of the capture and replay process, see type: entry-hyperlink id: 1QmLpq0M5tR6fHWHJynriL.

The Three Things Teams Get Wrong When Replaying Requests Manually

Capturing a request in DevTools and getting a 200 OK in curl is straightforward. Keeping that integration working in production is where most teams run into specific, predictable failures.

• Auth header format and token expiry. The Authorization: Bearer <token> value you copy from DevTools is tied to the current session. Tokens expire. A production integration needs automated token refresh: capturing the login flow and re-issuing credentials before requests fail. Many platforms also use non-obvious formats: a custom header instead of Authorization, a token stored in a cookie rather than localStorage, or a multi-step auth flow with an intermediate verification call.

• Anti-CSRF tokens. State-changing requests on many platforms require a X-CSRF-Token header whose value is generated fresh from the previous page load or a prior GET response. Copy a CSRF token once and reuse it across calls and you will see 403 Forbidden. A correct integration fetches the CSRF value for each request or session where one is required.

• Edge case payloads. The request body you capture in a standard session reflects your account's current state on the platform's happy path. Different account permission tiers, incomplete records, specific workflow states, and error-handling paths send different payloads and receive different responses. An integration that only covers the payload you observed breaks the moment it encounters a different account state in production.

How Integuru Automates Network Request Integration at Scale

Integuru is a Y Combinator-backed platform (founded 2024) that automates the full network request integration process. You connect a platform by authenticating your account (about a 10-minute auth flow), and Integuru's agent analyzes the platform's network traffic, maps the full API structure, and delivers production-ready endpoints in 10 to 20 minutes.

The output is a documented API for the target platform, built entirely on direct HTTP, with Integuru handling all three of the failure modes above:

• Auth auto-healing. On the Production plan, Integuru detects session expiry and re-authenticates automatically before requests fail. Bearer token rotation, cookie refresh, and 2FA flows are handled without manual intervention.

• CSRF and anti-bot handling. Integuru captures the full request lifecycle, including CSRF token generation steps and any anti-bot validation the platform requires, and bakes that logic into the generated integration.

• Edge case coverage. The agent maps branching logic, error states, and variation across account types, not just the happy path you trigger in a single DevTools session.

Key metrics for Integuru-generated integrations:

• 10-20 minutes to generate production-ready endpoints per platform

• Under 3 seconds average response time

• 99.9%+ reliability across production deployments

• 24/7 on-call maintenance on the Production plan: platform API changes are Integuru's problem, not yours

For a comparison of how direct HTTP stacks up against browser automation across latency, throughput, and cost, see type: entry-hyperlink id: 7ELDCHBOg5bNuPGE5jITi1. For the browserless architecture that makes network request integrations run without any browser overhead, see type: entry-hyperlink id: 1ASOtDJQ38Aq9iIUR3a4Lo.

When Network Request Integration Doesn't Apply

This approach covers the vast majority of authenticated web platforms. There are two categories where it does not apply.

Fully client-rendered pages with no XHR. Some older or unusual applications render everything in the browser and never issue HTTP calls to a backend API: the data lives entirely in the JavaScript bundle or a local state model. If DevTools' Fetch/XHR filter returns nothing when you perform an action, there are no network requests to capture. Browser automation or a different architectural approach is required.

WebSocket-only platforms. Applications that communicate exclusively through persistent WebSocket connections (rather than discrete HTTP request-response cycles) do not expose the kind of callable endpoints a network request integration targets. The connection is stateful and long-lived; there is no individual request to identify, capture, and replay.

Both cases are uncommon in standard authenticated SaaS platforms. Enterprise platforms, EHR systems, logistics portals, and fintech dashboards almost always use Fetch or XHR for their data operations.

How Production Integrations Handle Auth

Auth is the most operationally demanding part of any network request integration. Getting the initial request working in curl is step one. Keeping it working across session expiry, token rotation, 2FA challenges, and multi-account deployments is the production problem.

A durable auth implementation covers four layers:

1. Session initiation. Replicate the full login request sequence, not just the action request. Capture the POST to /auth/login or equivalent, extract the session token from the response, and store it for subsequent calls.

2. Token refresh. Monitor for 401 Unauthorized responses. On expiry, re-run the auth flow and retry the original request with a fresh token. This loop needs to be atomic: if two concurrent requests both detect expiry, only one should run the refresh, and the other should wait and reuse the new token.

3. 2FA handling. If the platform issues a 2FA challenge during login (a code sent via email, SMS, or TOTP), the integration needs to complete that verification step before the session is usable. Integuru supports email and phone 2FA as part of the standard integration.

4. Multi-account isolation. Integrations running across multiple accounts need separate session state per account. Token bleed between accounts produces incorrect results and can trigger security alerts at the platform.

On Integuru's Production plan, auth auto-healing manages the full refresh cycle automatically. Session expiry is detected, the re-auth flow runs, and requests resume without any manual intervention or downtime to your integration.

Get Started

Integuru maps the full network request profile of any web platform (all endpoints, all auth states, all edge case payloads) and delivers a production-ready integration in 10 to 20 minutes. The fastest way to start is the CLI:

npm install -g integuru

Or open the web app at app.integuru.com. To talk through your specific platform and use case, book a call here or email us.