Summary
Data Connection webhooks currently require 100% manual configuration through the UI — there is no API, CLI, SDK, or automation support for creating, reading, updating, or copying webhooks between sources. This makes webhook management highly “click-ops” and creates significant friction for teams managing webhooks across environments (dev → staging → prod).
Problem Statement
Webhooks are a critical integration capability, enabling Foundry applications to interact with external systems in real time. However, the current workflow for managing them has several pain points:
-
No programmatic access — There is no API to read or write webhook configurations. Every webhook must be manually created and configured through the Data Connection UI.
-
No environment promotion path — When moving from dev to prod, teams must manually recreate each webhook on the production source by hand, copying over the HTTP method, path, headers, query parameters, body templates, and parameter definitions. This is error-prone and doesn’t scale.
-
No version control or audit trail for configuration — Unlike transforms (which live in code repositories) or Ontology entities (which support branching), webhook configurations have no versioning, diffing, or change tracking beyond the version number in the UI.
-
No bulk operations — Teams with dozens of webhooks on a source must create and update them one at a time.
-
Inconsistency with the rest of the platform — Foundry excels at “infrastructure as code” for pipelines, Ontology, and functions. Webhooks are a notable gap where the only option is manual point-and-click.
Proposed Solution
Add programmatic webhook management capabilities, ideally covering:
| Capability | Description |
|---|---|
| Read webhook config | API to retrieve a webhook’s full configuration (method, path, headers, body template, parameters, response mapping) |
| Create webhook | API to create a new webhook on a source |
| Update webhook | API to modify an existing webhook’s configuration |
| Copy/clone webhook | Ability to copy a webhook from one source to another (e.g., dev → prod), with optional parameter overrides for environment-specific values |
| Export/import | Export webhook configs as JSON/YAML for version control and import them into another source |
| List webhooks | API to list all webhooks on a given source |
Ideal Integration Points
-
Foundry API / REST endpoint — First-class API support for CRUD operations on webhooks
-
OSDK / CLI support — Enable automation scripts and CI/CD pipelines to manage webhooks
-
Global Branching support — Allow webhook configurations to participate in branch-based development workflows alongside Ontology and pipeline changes
-
AIP Agent / AI FDE tooling — Expose webhook management as tools so AI assistants can help configure and troubleshoot webhooks
Use Case Examples
-
Environment promotion: A team maintains 15+ webhooks for a Boomi integration. Promoting from dev to prod currently requires manually recreating each webhook — a 30+ minute, error-prone process that could be a single script or copy operation.
-
Disaster recovery: If a source needs to be recreated, there’s no way to programmatically restore its webhook configurations.
-
Standardization: Teams want to enforce naming conventions, header standards, and body template patterns across webhooks — impossible without programmatic access.
Impact
This change would bring webhook management in line with the rest of Foundry’s developer experience, reduce operational risk from manual configuration errors, and enable proper CI/CD workflows for integration-heavy deployments.