What we found
The webhooks documentation publishes a fixed set of source IP addresses and recommends restricting the endpoint to them (https://workos.com/docs/events/data-syncing/webhooks#create-an-ip-allowlist). As of today that list has 15 addresses. The SDK does not contain the list, there is no API endpoint that returns it, and a code search of this repository finds no match for any of the addresses or for allowlist.
Effect
Every customer copies the list into their own code. The copy is static and invisible to your release process. When WorkOS adds an address, every copy is wrong at the same moment and the integration rejects valid traffic with no warning. We found this out the hard way: our copy had nine addresses, the docs now have fifteen, and nothing told us. The rejection is a plain 403 from our side, so it does not show up as an error anywhere.
Request
In order of preference:
- Publish the list at a stable API endpoint, for example
GET /webhooks/source_ips, so a client can refresh and cache it. A change then reaches every customer without an upgrade.
- Export the list from the SDK as a constant, for example
WEBHOOK_SOURCE_IPS. Weaker, because it needs a version bump and an upgrade.
- At minimum, announce additions in the changelog with advance notice, and add the list to the machine-readable API description.
Option 1 is the only one that fixes the problem for customers who are not on the latest SDK.
What we found
The webhooks documentation publishes a fixed set of source IP addresses and recommends restricting the endpoint to them (https://workos.com/docs/events/data-syncing/webhooks#create-an-ip-allowlist). As of today that list has 15 addresses. The SDK does not contain the list, there is no API endpoint that returns it, and a code search of this repository finds no match for any of the addresses or for
allowlist.Effect
Every customer copies the list into their own code. The copy is static and invisible to your release process. When WorkOS adds an address, every copy is wrong at the same moment and the integration rejects valid traffic with no warning. We found this out the hard way: our copy had nine addresses, the docs now have fifteen, and nothing told us. The rejection is a plain 403 from our side, so it does not show up as an error anywhere.
Request
In order of preference:
GET /webhooks/source_ips, so a client can refresh and cache it. A change then reaches every customer without an upgrade.WEBHOOK_SOURCE_IPS. Weaker, because it needs a version bump and an upgrade.Option 1 is the only one that fixes the problem for customers who are not on the latest SDK.