Building Confidence in Public APIs with a “No-Auth” Credential and Static Egress IP
- RequestRocket

- May 22
- 3 min read
Modern engineering teams love automation, yet many of the systems we integrate with still cling to firewalls, IP allow-lists, and other legacy controls. These security requirements can derail an otherwise streamlined CI/CD pipeline because cloud runners rarely provide predictable source IPs, and authentication rules often change over time.
RequestRocket addresses these constraints with two complementary features:
A “No-Auth” credential that guarantees downstream services see zero authentication, even if your developers authenticate to RequestRocket.
A fixed egress IP that lets you satisfy static IP allow-lists without restructuring your cloud infrastructure (for Business / Enterprise customers).
This post explains why these two ideas matter, how to weave them into your deployment workflows, and the operational benefits they bring.
The Problem: Legacy Constraints Clash with Modern Pipelines
Picture a software company delivering a customer-facing API. Its engineering team relies on GitHub Actions to run smoke tests against every environment, but one of their enterprise customers insists that only calls from a whitelisted IP can reach the staging URL. Worse, that customer also requires the staging endpoint to remain completely public (no auth headers allowed) so they can run their own unauthenticated health checks.
Cloud runners break under both rules:
No static source IP: Each job starts in a new container on a randomly assigned host.
No auth: Most test frameworks still send something in an Authorization header, even if empty, and some frameworks always send cookies.
Attempts to solve these problems usually involve heavyweight fixes, reserved runners, self-hosted agents, or temporary firewall relaxations. All introduce extra cost, risk, or maintenance debt.
A Two-Part Solution
1. System-Generated “No-Auth” Credential
In RequestRocket every Proxy references both a Target and a Target Credential. Instead of treating “missing credential” as “no authentication,” we allow users to define a No-Auth credential type:
Explicit behavior: RequestRocket filters out every Authorization, Cookie, or Proxy-Authorization header before forwarding the request.
Future flexibility: When the endpoint later requires a token, you replace the No-Auth credential with an OAuth2 or API Key credential in a single click. No pipelines break, and no subtle “credential = null” bugs surface.
The key advantage is clarity. Tests, dashboards, and logs all show an explicit credential object, so everyone knows the intent was to send zero auth.
2. Static Egress IP
RequestRocket also offers a fixed egress IP in each region that defined call will originate from. Internally we employ NAT gateways to hold that address, while the proxy instances continue running in a serverless pool.
For your CI/CD jobs this means:
You leave your GitHub runner network untouched.
All calls route through https://{region}.requestrocket.com/api/{target}.
The downstream provider sees traffic only from the whitelisted IP.
If the downstream system also demands auth later, you enable it in RequestRocket without leaving the static IP path.
Putting It Together in a CI Workflow
# .github/workflows/smoke.yml
name: Staging smoke test
on:
push:
branches: [main]
jobs:
smoke:
runs-on: ubuntu-latest
steps:
- name: Invoke staging API via RequestRocket
run: |
curl \
--header "Authorization: ${{ secrets.RR_API_KEY }}" \
--silent \
--fail \
"https://{region}.requestrocket.com/api/{target}/staging-public/health"
The workflow authenticates to RequestRocket with an API key.
RequestRocket attaches the No-Auth credential, deletes any auth headers, and forwards the call.
The call exits RequestRocket from the fixed IP address and arrives at the customer’s staging server looking like a completely unauthenticated request from a single trusted source.
Operational Benefits
Challenge | Legacy workaround | RequestRocket outcome |
Unpredictable source IPs from cloud runners | Self-hosted or reserved runners | Fixed egress IP handled by the proxy |
Need to verify an endpoint is genuinely public | Manual curl from local machine | Automated smoke test with No-Auth credential |
Later migration from public to authenticated endpoint | Rewrite every pipeline and test | Swap credential type in UI or via API |
Risk of leaking tokens when testing public endpoints | Strip headers manually or rely on dev diligence | Proxy guarantees zero auth leaves the system |
Security Considerations
Outbound traffic inspection: Because RequestRocket can enforce header filtering, you remove accidental token leaks to public services.
Inbound authentication: Developers still authenticate to RequestRocket, so usage metrics and rate limiting apply per workspace, not per job.
Credential rotation: When you replace No-Auth with an OAuth2 secret or API key, rotation policies and secret storage inherit everything available in the platform.
Extending the Pattern Beyond CI/CD
Third-party integrations: Offer a public webhook to partners that must stay unauthenticated but also must come from an IP in their allow-list.
Penetration testing: Validate that no sensitive data appears in headers when scanning public endpoints.
Legacy customer systems: Some vendors never moved beyond IP allow-listing. Present your modern SaaS through a whitelisted IP and translate their outdated expectations into today’s secure practices.
Conclusion
By pairing a formal No-Auth credential with a static egress IP, RequestRocket bridges the gap between modern DevOps automation and the older security controls that many enterprises still rely on. You gain:
Faster, safer CI/CD pipelines.
Cleaner separation between internal and external auth policies.
Simpler future migrations as endpoints evolve.
If your team wants to streamline testing of public endpoints, satisfy stubborn firewall rules, or simply gain clearer observability into how authentication flows through your stack, try configuring the No-Auth credential on a Target and run your next smoke test through RequestRocket. Your pipelines, and your customers, will thank you.



Comments