What Is a Data Plane: Where API Traffic Actually Runs

A data plane is the path the request takes

If the control plane is where you change the system, the data plane is where each call runs. In a router, that is the forwarding ASIC. In Kubernetes, it is kube-proxy and the CNI on the node. In an API gateway, it is the process that accepts the HTTP request, decides, and talks upstream.

The data plane has to be close to the work. It holds the state the hot path needs: encrypted credentials, proxy and target config, rules, meters, filters, short-lived token cache, and the request log. It should not call home to ask permission on every request. Policy was already pushed. Enforcement is local.

What happens on one call

A caller hits a regional proxy endpoint with a proxy credential. The data plane:

1. Authenticates the caller – lookup for a key, signature check for jwtVerify against a JWKS endpoint, basic-auth decode, and so on. Authentication is per-credential-type, not a single code path.
2. Evaluates rules against path, method, headers, query, body, and JWT claims. proxyDefaultRuleEffect: "deny" means no match is a deny. Rules support regex matching and {{variable}} interpolation – a variable can be extracted from a header, a JWT claim, a query parameter, or the request body and substituted into a pattern at evaluation time.
3. Checks meters. Two types: request_count meters enforce request-per-minute/hour/day/month limits. response_value meters extract a numeric value from the upstream response (a header like x-ratelimit-remaining or a body path like usage.total_tokens) and aggregate it against a budget. A proxy with no meters has no rate limits. Meters can be conditional – scoped to specific methods, paths, headers, or claims, so a single proxy can rate-limit POST calls without constraining GET.
4. Decrypts the target credential, attaches it to the outbound request, and calls the vendor. For oauth2 and customToken credentials the gateway handles token fetch, caching, and refresh automatically – the caller’s request is held until a valid access token is ready. For jwtSigned credentials the gateway mints a fresh signed JWT at forward time.
5. Applies response filters. Filters operate on the response body and headers before the result is returned to the caller. Operations are retain (keep only matching fields) or destroy (remove matching fields). Row-level filtering can match inside arrays – for example, retain only the order rows where customerId matches the caller’s JWT sub claim. This is PII redaction and data minimisation at the gateway, not in application code.
6. Applies overrides if configured – additional headers, query parameters, or body data injected per-proxy or per-credential on every matching request.
7. Writes an audit record with timing, auth decision, rule outcomes, meter results, filter actions, HTTP status, and caller country. The record stays in-region, with a 90-day TTL, and is queryable through the Requests API.

Secrets on disk are AES-256-GCM. The algorithm is What is AES-256 encryption. Decrypt happens on this path, for this call, and the plaintext is not returned on GET /credentials.

Region is not a label. It is the plane.

Every proxy and credential has a region field (proxyRegion, credentialRegion). That value selects which data plane stores the encrypted secret and handles the traffic. Operational data does not replicate to other regions. That is the residency story: the bytes stay where you put them.

The control plane can see that a credential named stripe-production exists in eu-west-1. It cannot read the token. A proxy in us-east-1 cannot use a credential stored in eu-west-1. Cross-region is a misconfiguration, not a fallback.

Shared, dedicated, self-hosted

The data plane is the part you can move. The control plane stays central.

• Managed multi-tenant. Shared regional infrastructure. Change proxyRegion to deploy somewhere else. Every plan.
• Dedicated managed. Isolated infrastructure RequestRocket operates. Same APIs, same console, a region value that is yours. Announced in dedicated managed and fully self-hosted RequestRocket.
• Self-hosted. The gateway software in your VPC. Secrets never leave your account. The region still appears in /endpoints. Policy still comes from the same Core API.

Feature set does not fork across those models. credentialAuthType values, rules, filters, meters, and request logs are the data plane’s job wherever it runs.

What a data plane is not

It is not a place to invite users or rotate member roles. That is control-plane traffic. A proxy credential that can call /v1/charges should not be able to list your organisation’s members.

It is not “the AWS region your app runs in.” Your Lambda can live in ap-southeast-2 and still call a RequestRocket proxy in us-east-1. The data plane region is where this proxy and this secret live, chosen for residency and latency to the vendor, not for where the agent process happens to sit.

It is not a secrets manager you query from application code. The application never fetches the target credential. It presents a proxy credential and gets a response. If the app can print the vendor key, you are not using the data plane. You are using a vault as a shared clipboard.

It is not limited to synchronous request-response. The data plane also serves the async proxy API – the caller fires a request, receives a task ID, and polls or is called back when the upstream responds. Retry count (proxyMaxRetries) and backoff ceiling (proxyMaxBackoff) are proxy-level settings. The data plane handles the retry loop and writes one audit record per attempt.

Next steps

Pick a region, create the target credential there, issue a proxy credential in the same region, and point a deny-by-default proxy at both. The management half of the same picture is What is a control plane. Deployment options are in the dedicated managed post and the architecture docs. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.