invokationMake the source address part of onboarding
An enterprise can expose a public HTTPS API while allowing traffic only from approved source addresses. If your application exits through changing addresses, a correct request may never reach the API. Invokation’s intended egress policies would make that requirement an explicit part of each profile.
The proposed workflow is concrete: obtain a documented address set, give the full set to the enterprise’s network owner, complete approval and testing, then assign the approved route to the customer profile. Our examples use reserved documentation addresses such as 192.0.2.10 and 198.51.100.20; they are illustrative and cannot be allowlisted for an actual Invokation service.
Stable shared sets
A stable shared set is a documented pool of public source addresses used for outbound traffic. Multiple vendors or profiles may use that set. The stability helps an enterprise maintain an allowlist, while the allocation does not provide a vendor-exclusive source identity.
The intended policy would describe region, environments, and every address needed during ordinary execution and failover. An enterprise that approves only one address from a larger required set could accidentally block a healthy fallback route. Address changes need notice and a coordinated handover process.
Dedicated outbound allocations
A dedicated allocation reserves an outbound address set for an agreed scope, such as a vendor environment or selected profiles. The point is a clearer source-address boundary and ownership relationship. Allocation scope and region must be stated rather than inferred from the word “dedicated.”
Reserved addresses do not imply dedicated compute, single tenancy, or complete security isolation. Credentials, application permissions, network policies, and execution boundaries remain separate controls. Dedicated egress is an intended capability; no actual allocations are available through this website.
Private-only systems need a different path
A destination with no public ingress cannot be reached merely by choosing a fixed public source IP. It needs a permitted network path. Planned options include a customer-side agent or an approved network connection, subject to the customer’s architecture and security review.
An agent would introduce its own deployment, upgrade, outbound connectivity, and access responsibilities. A network connection would require routing, name resolution, firewall rules, and ownership of both ends. These are planned directions, not a claim that a VPN or agent is ready today.
Profiles select routes; enterprises approve access
Environment/profile routing policies would bind a connection to its permitted route. A staging profile may use a test endpoint and shared egress. A production profile may need a dedicated set and separate certificate. Moving between them needs an explicit check of route, endpoint, credentials, and approvals.
A fixed address never bypasses authentication, TLS requirements, certificate trust, configurable scopes, or the destination’s authorization decisions. The enterprise remains responsible for approving and enforcing access to its systems. Your team remains responsible for the contract and the permitted actions it invokes.
A practical allowlist handover
- Identify the actual target: application API, enterprise gateway, or private service.
- Confirm public ingress exists, or select a separately approved private path.
- Document primary region, failover region, complete source sets, and allocation scope.
- Exchange the addresses through the customer’s normal approval process.
- Configure credentials, certificate requirements, scopes, and name resolution separately.
- Test from the intended route against the intended environment.
- Record the approval owner, change process, and operational contact.
Include negative tests: an unapproved source, a revoked credential, and a wrong environment should fail in the way your runbook expects. Connection health should indicate what was tested without claiming broader permissions.
The static outbound IP guide explains the networking tradeoffs independently of Invokation. The client onboarding walkthrough shows how route approval fits into a repeatable implementation.