ziti-webhook-action VS webhook.site

Alternaitvely you could use OpenZiti 'zitified' webhook for Github (https://github.com/openziti/ziti-webhook-action). We use it internally to connect our GitHub from open source OpenZiti repo to our CloudZiti SaaS instance - https://netfoundry.io/this-is-the-way-invisible-jenkins/. You can do this by self-hosting ziti or using the CloudZiti free tier.

We used this to build a GitHub webhook action - https://github.com/openziti/ziti-webhook-action. We use this to connect our production Jenkins to the OpenZiti Jenkins with no inbound ports or ACLs - https://netfoundry.io/this-is-the-way-invisible-jenkins/.

This includes SDKs to embed in an app, e.g., Python running AWS Lambda (https://openziti.io/my-intern-assignment-call-a-dark-webhook-from-aws-lambda) or Node inside a GitHub webhook (https://github.com/openziti/ziti-webhook-action).

As far as your question on alternatives, the OpenZiti private networking approach has always been desired from a security perspective, but was previously implemented by requiring all your API clients to use VPNs, an MPLS network or private business APNs. For a relatively small and static implementation, those methods might be viable. The problem is managing all of that at scale. OpenZiti addresses this management problem by putting the private networking into the APIs themselves, as code. Here is a simple example of a Zitified Webhook.

open-sourcehttps://github.com/openziti/ziti-webhook-action

It doesn't have all of the features, but there is an open-source version of webhook.site that you can host yourself: https://github.com/webhooksite/webhook.site