Configure and Verify Fixed Egress for RazorpayX API Clients

Use a dedicated proxy-aware HTTP transport to give selected application requests a predictable outbound source. This guide walks through the implementation boundary, secret setup, allowlist preparation, and non-mutating route verification for a cloud application preparing to use RazorpayX.

The intended result is an explicit route that every relevant process can verify. Your website DNS, webhook ingress, API credentials, and business-operation logic remain separate configuration concerns.

Before you begin

Identify the exact server-side runtime and HTTP client or SDK that opens the API connection. You will need access to its deployment configuration, a QuotaGuard subscription’s connection details, and an account owner who can approve the destination’s network arrangement.

Confirm acceptance of the proposed addresses, shared or dedicated infrastructure, and geographic route for the specific account. A proxy-compatible implementation still needs destination approval. If your existing cloud egress already meets those requirements, you can keep that route instead.

Use the Razorpay allowlisting instructions for the current policy and account controls. Owner/Admin users can add up to 20 IPs in Live mode under profile, My Account & Settings, Developer Controls, Share IP Addresses. Save and complete OTP confirmation. If the control is missing or you use dynamic source addresses, follow Razorpay’s support route.

1 Identify every process that calls RazorpayX

List each process with its runtime, library, deployment, and secret source. At a minimum, review the web process, payout worker, scheduled reconciliation job, administrative tooling, and any standby deployment.

Use this compact record for each caller:

Process name:
Production environment or region:
Deployment identifier:
HTTP client or SDK:
Proxy configuration entry point:
Secret source and rotation owner:
Source IP diagnostic result and time:

Do not put proxy credentials or API keys in the record. A private deployment identifier and a source IP are enough to correlate the network result with a release.

A job running on a different service is a separate caller even if it uses the same repository. Treat a new worker pool or deployment region as a networking change until its route has been verified.

2 Collect the right QuotaGuard values

Open the selected subscription’s Setup page, choose Outbound Proxy, then Connection Information. Retrieve the complete HTTP connection URL and the two assigned static IPv4 addresses. See the connection-details reference.

Use each value for its intended purpose:

• HTTP connection URL: server-side client configuration, stored as a secret.
• Assigned static IPv4 pair: approved source addresses for the destination allowlist and for diagnostic comparison.
• Proxy hostname: part of the connection URL; not a substitute for the assigned pair.

Both assigned addresses belong in the approved allowlist because either may be used. Do not choose only the address seen in your first test. The two-address explanation describes the pair.

3 Configure secrets for each deployed caller

Store the full URL in a server-side variable named QUOTAGUARDSTATIC_URL. Store the expected pair as EXPECTED_EGRESS_IPS, with the two addresses separated by a comma. The pair is configuration, not an authentication secret, but it should still be managed deliberately.

Use the platform’s secret manager or protected environment configuration. Do not paste a real URL into source control, an example file, build output, chat, or browser code. Avoid shell tracing and verbose network logging while working with authenticated proxy URLs.

Confirm that the setting reaches the process that needs it. A secret attached to the web service may not exist in a worker or scheduled task. Some runtimes read configuration only at startup; follow the platform’s documented redeployment or restart behavior after a change.

A missing required proxy setting should stop the protected operation. Do not construct a default direct client when configuration is empty.

4 Configure a dedicated HTTP transport

Keep proxy routing scoped to the relevant integration. This reduces surprises for unrelated application requests and makes it possible to test the route independently.

For Python Requests, the essential configuration is:

import os
import requests

proxy_url = os.environ["QUOTAGUARDSTATIC_URL"]
if not proxy_url.strip():
    raise RuntimeError("Proxy configuration is required.")

session = requests.Session()
session.trust_env = False
session.proxies = {"http": proxy_url, "https": proxy_url}

# Use this Session for the selected integration only.
# Every actual request also needs timeouts, TLS verification,
# and an explicit redirect policy.

The full diagnostic example adds configuration validation, timeouts, response limits, and sanitized errors. trust_env = False prevents ambient proxy settings or .netrc credentials from changing this Session’s behavior. It also means an approved custom CA bundle must be configured explicitly if your runtime needs one. See the Requests configuration documentation and Session reference.

For Node’s built-in HTTPS client, use an agent designed for CONNECT proxying:

import https from 'node:https';
import { HttpsProxyAgent } from 'https-proxy-agent';

const proxyUrl = process.env.QUOTAGUARDSTATIC_URL;
if (!proxyUrl?.trim()) {
  throw new Error('Proxy configuration is required.');
}
const agent = new HttpsProxyAgent(proxyUrl);

// Pass { agent } to the selected https.request or https.get call.
// Keep certificate verification enabled and apply a request deadline.

The HttpsProxyAgent documentation describes this transport. An https.Agent is not automatically the right configuration for fetch, Axios, or a vendor SDK. Use the actual library’s documented interface, and verify its route rather than assuming it inherited the setting.

Keep the integration’s real destination URL, account authentication, and operation semantics unchanged when adding routing. The proxy credentials authenticate to QuotaGuard; the API credentials authenticate to the destination. Never send the latter to a diagnostic endpoint.

5 Run a nonmutating egress check

Use the accompanying examples/check_egress.py or examples/check-egress.mjs from the deployed runtime. Each makes a GET request to QuotaGuard’s source-IP diagnostic endpoint, https://ip.quotaguard.com, through its explicitly configured proxy client. QuotaGuard documents a JSON response with an ip field in its egress verification example.

After installing the dependency in your application’s managed environment and setting the two configuration variables, run one of:

python check_egress.py

node check-egress.mjs

The scripts do not require Razorpay credentials. They reject redirects, unexpected response bodies, and source addresses outside the configured pair. They preserve TLS verification and do not retry through a direct connection.

A successful result contains the observed egress_ip and a true matches_configured_pair field. Record it against the caller and deployment. This establishes the route for that diagnostic request, not account acceptance or financial-operation success.

Run the corresponding check for each real caller. If the production SDK uses a different transport from the example, add a non-mutating diagnostic using that actual transport or its supported test hook. Do not claim SDK coverage from a separate successful script.

If outbound access to a diagnostic endpoint is restricted, agree on an approved equivalent with the network owner. Keep it non-mutating and do not send destination credentials or sensitive request bodies. Do not relax production network controls solely to make an example work.

6 Complete the destination configuration

Have the authorized account administrator apply the approved pair using the current provider workflow. Re-read the saved configuration and match both values to the selected subscription. Keep an internal record of the account, environment, pair, change owner, and time.

Do not replace unrelated entries when adding the pair. Other applications may still rely on them. Retiring old entries should be a separately reviewed change after the migration is complete.

Do not infer approval from the absence of an error in a local diagnostic. Destination policy, account permissions, and provider-side source authorization are separate checks.

7 Integrate routing without changing payout semantics

Pass the approved transport into the application’s existing request path. Verify that queue consumers and scheduled jobs use the same reviewed configuration boundary.

Keep the application’s authorization, idempotency, amount validation, and reconciliation logic intact. A network configuration change should not introduce a new payout payload, new retry policy, or new permission model as a side effect.

Use the team’s existing authorized release process for end-to-end financial testing. Do not issue a live state-changing request merely to see whether the proxy works. If you need a provider-side check before enabling the workflow, identify an appropriate non-mutating operation with the account owner and follow its documented access rules.

8 Make failure and rollback behavior explicit

When the proxy is unavailable, leave the protected operation stopped or queued according to the application’s reviewed design. A direct fallback silently changes the source address and may violate the intended access boundary.

For rollback, pause the affected workload or return it to a previously approved route through a controlled deployment. Do not disable the destination allowlist as a routine troubleshooting step. Preserve the prior configuration until the new path is verified and old callers are accounted for.

Treat an uncertain financial response separately from a routing failure. Before retrying an operation that may have reached the provider, reconcile its state and apply the provider’s operation-specific guidance.

9 Add a lightweight operational check

After a deployment or secret rotation, repeat the source-IP diagnostic from the affected caller. A check tied to the deployed client is more informative than one run in a general CI runner that never executes production requests.

Use a restrained schedule if you add ongoing monitoring. Do not make the diagnostic a dependency for every business transaction, and do not interpret a diagnostic-service outage as proof that the financial API is down.

Log the caller identity, deployment version, check time, observed source IP, and sanitized result. Do not log authenticated proxy URLs, API keys, financial payloads, or raw exception objects that can contain secrets.

Security considerations

HTTPS destinations retain endpoint TLS through a Static CONNECT tunnel. This does not encrypt the initial connection to an http:// proxy or its proxy authentication. Review both hops and the complete data route against your requirements. Keep destination certificate verification enabled. See QuotaGuard’s HTTPS explanation.

Shared IPs are not exclusive identities. Select a shared or dedicated arrangement deliberately and maintain application authentication regardless of the network choice. For help assessing the client and route, contact QuotaGuard.

Completion criteria

The routing work is ready for the team’s next release step when each intended caller has a documented transport, both assigned addresses are in the approved configuration, configuration survives deployment, non-mutating egress checks pass, and failure behavior is controlled. Financial workflow acceptance remains part of the separate application release process.

Download the reference examples · Integration overview