- Payment service sends an order-status event to an internal billing service.
- A source-code platform sends repository events to an internal automation service.
- A CRM or support tool notifies a private back-office system about a customer action.
- Your own public service forwards operational events to a private handler without exposing that handler to the internet.
Webhook Connector Guided onboarding
Receive public webhooks into a private service
Webhook Connector gives an outside service a BusinessProxy address for sending events, while your private service stays behind the firewall. The local utility connects out to BusinessProxy and forwards each accepted event only to the fixed internal address you configured.
This is a separate connector mode for machine-to-machine notifications. It does not give a browser user access to your private network and does not replace the main App Gateway connector.
Purpose
When this is useful
Use it when a public system must notify a private application, but opening an inbound port to that application would be too risky or inconvenient.
Event path
How the path works
Create a webhook connector
The connector has its own type and token. It cannot publish App Gateway applications, and an App Gateway token cannot read webhook events.
Add a receiving address
BusinessProxy creates a public webhook URL with a long random secret and binds it to one fixed private upstream, method list, size limit, timeout and request rate.
Put the URL into the outside service
The outside service sends events to the BusinessProxy URL. The outside request never chooses the private upstream.
Run the local utility
The utility polls BusinessProxy over an outbound connection, receives accepted events for its workspace and connector, and forwards them to the fixed private upstream.
Security
Security boundaries
- Connector and endpoint tokens are separate from App Gateway tokens.
- The internal upstream is fixed in BusinessProxy settings, not supplied by the incoming request.
- Method, body size, timeout and rate limits are enforced before the event is queued.
- Secrets from the public webhook URL are removed from logs, errors and activity views.
- The outbound request path keeps the same hardened dial rules: DNS pinning, metadata blocking and fail-closed target checks.
Setup
User setup checklist
The exact commands are shown in the account and in the setup documentation. At product level, the flow is this:
1. Create the connector
In the workspace, create a Webhook Connector and store the one-time runtime token in a safe place.
2. Create the receiving address
Choose the provider type, the fixed private upstream, allowed methods, body limit, timeout and rate limit. Save the public URL and its one-time secret.
3. Start the utility near the private service
In the network segment that can reach the private upstream, check the configuration, run diagnostics and then start the connector process.
4. Configure the outside service
Paste the BusinessProxy webhook URL into the outside service and keep the service-side signature verification enabled when that service supports it.
5. Test and rotate secrets
Send a test event, confirm that the private service receives it, then define how connector tokens and webhook secrets will be rotated or revoked.
Boundaries
What it is not for
- It is not a general inbound tunnel into the private network.
- It is not a browser access product for people. Use App Gateway for that.
- It does not prove that a payment or business action is valid. Your application must verify critical events with the original provider.
- It should not be used to expose arbitrary private URLs chosen by the sender.