osFoundry / Platform
Outbound webhooks
Fan out platform events to your own endpoints. Auto-retry, signature verification.
What it is
Outbound webhooks let osFoundry push events to endpoints you control. Instead of polling for changes, you register a URL and osFoundry sends an HTTP request to it whenever a relevant event happens in your workspace. That turns activity in your chat, agents, apps, code, knowledge, and data surfaces into a signal your own systems can act on, without wiring a custom integration for each one.
Inside osFoundry, webhooks live under Settings & Security because they cross a trust boundary: they carry workspace events out to a receiver you own. Every delivery is signed, so your endpoint can verify the request actually came from osFoundry and was not tampered with in transit. You check the signature against your shared secret before you trust the body. Deliveries that fail — because your endpoint was down, slow, or returned an error — are retried automatically rather than dropped, so a brief outage on your side does not silently lose events. Because osFoundry is bring-your-own-key and local-first, webhooks are the deliberate, opt-in way to move data outward: you decide which endpoints receive events, and payloads go only where you point them.
The practical value is decoupling. Your notification service, ticketing system, data warehouse, or an in-house automation does not need to live inside osFoundry or hold osFoundry credentials — it just needs to expose an HTTPS endpoint that verifies a signature and returns a success status. Signature verification plus auto-retry are what make that endpoint safe to trust and reliable to depend on, which is the difference between a webhook you can build a workflow on and one you have to babysit.
Key capabilities
- Register your own HTTPS endpoints and receive platform events as they happen, no polling loop to maintain
- Every payload is signed so your receiver can verify the request originated from osFoundry before acting on it
- Failed deliveries retry automatically, so a downstream outage doesn't silently drop events
- Managed under Settings & Security as an opt-in, per-endpoint outbound path you fully control
- Fits the local-first, BYOK model: data leaves only to the endpoints you explicitly point it at
Use cases
- Platform engineer: forward workspace events to an internal automation service without giving it osFoundry credentials or embedding it in the app
- Ops/on-call: pipe events into an existing alerting or notification system so the right people hear about activity in real time
- Data team: stream events to a warehouse or ETL endpoint to keep an external record in sync with what happens in the workspace
Frequently asked questions
How do I verify a webhook request actually came from osFoundry?
Each delivery is signed. Your endpoint recomputes the signature over the request body using your shared secret and compares it to the signature osFoundry sends. If they don't match, reject the request. This is what stops a third party from forging events to your endpoint.
What happens if my endpoint is down when an event fires?
osFoundry retries the delivery automatically instead of dropping it, so a short outage or deploy on your side doesn't cause you to lose events. Your endpoint should return a success status once it has accepted the payload.
Does using webhooks send my data somewhere osFoundry controls?
No. osFoundry is local-first and BYOK, and webhooks are outbound to endpoints you register. Events go only to the URLs you configure, and you control which endpoints exist. It's an opt-in way to move specific events to systems you already own.