Integrations
Webhooks And Eventing Roadmap
Webhooks and eventing are not current extension SDK hooks. This page is roadmap/prep documentation so integration providers can understand the direction without relying on unsupported behavior.
Current extension integration support is mail transport registration. Webhook delivery and structured internal eventing need a later contract before they become extension-authorable, API-callable, or MCP-visible SDK surfaces.
Current Status
The feature inventory marks webhooks and eventing as mixed future work:
| Surface | Current reading |
|---|---|
| Webhook delivery service | Scaffolded and used for funnel events in test mode. |
| Outbound webhooks | Planned with configurable retry policies and delivery logging. |
| Internal event system | Planned as the backbone for publish, file upload, form submission, and other mutation events. |
Source code includes implementation signals:
MyronWebhookDeliveryService::recordTestDelivery()records sanitized test-mode webhook audit entries.MyronFunnelWebhookDispatcher::dispatch()validates a URL and returns a dispatch result shape for funnel automation.MyronFunnelAutomationServicerecognizeswebhook.dispatchas one funnel automation action.
These are not extension SDK contracts. They do not define extension registration hooks, public event names, signing rules, retry behavior, delivery log APIs, or MCP tools for webhook management.
Human Path
Today, an integration provider should not build an extension that depends on a MyronCMS extension webhook hook. There is no documented bootstrap.php key, registry, interface, or manifest declaration for extension-provided webhooks or event subscribers.
Providers that need current integration support should use the stable mail transport surface where applicable.
AI Path
An AI coding agent can read current source and prepare design notes, but it should not author docs or extension examples that imply webhook/eventing support exists today.
An installed MCP client has no current extension webhook/eventing tool or resource to call. Any future MCP exposure must be evaluated separately with scopes, audit behavior, signing/secrets policy, replay/idempotency handling, and operator controls.
Scopes
No current extension webhook/eventing scope exists. Do not invent one in extension docs.
Future work will need to decide whether webhook/eventing scopes belong under existing base scopes such as administration.read and administration.write, or whether narrower sub-scopes are needed.
Artifacts
Current implementation signals:
app/modules/integrations/WebhookDeliveryService.phpapp/modules/funnels/Automation/WebhookDispatcher.phpapp/modules/funnels/AutomationService.phpdocs/features-inventory.md
Missing extension SDK artifacts:
- no extension webhook interface,
- no event subscriber registry,
- no
bootstrap.phpwebhook payload key, - no extension manifest declaration for events,
- no public extension webhook API,
- no MCP tool/resource for extension webhook management.
Parity Gap Triage
| Question | Answer |
|---|---|
| What can a human do today? | A human can review scaffolded funnel/webhook internals and use current app workflows that exercise test-mode or funnel automation behavior where available. |
| Why can an AI not do it through current API/MCP/local authoring? | There is no extension SDK interface, registry, bootstrap contract, API action, or MCP tool/resource for extension-authored webhooks or event subscribers. |
| What kind of gap is this? | Missing action coverage, missing resource coverage, and missing extension architecture contract. It is also safety-sensitive because outbound delivery involves secrets, signing, replay, retries, and audit. |
| What contract question must be answered before exposure? | Which events are public, how subscriptions are declared, how destinations and secrets are stored, what scopes govern setup and delivery logs, and what retry/idempotency guarantees are supported? |
| Safest interim wording | "Webhooks/eventing are planned integration surfaces. Current extension SDK docs do not offer a webhook or event subscriber hook." |
Safety Boundary
Do not document current extension examples using webhooks, events, subscribers, or similar bootstrap.php keys. They are not current loader payloads.
Do not promise live outbound webhook delivery, event catalogs, retry policies, delivery log APIs, signing secrets, or operator setup screens as extension SDK features.
Do not expose webhook secret creation, rotation, or destination management as an AI-callable path without a later safety contract.
Verification
For documentation review:
rg -n "webhook|eventing|mailTransports" docs/extensions-sdk app/modules app/systemConfirm this page:
- uses
support_status: "future-planned", - uses
parity_gap: true, - says there is no current extension webhook/eventing hook,
- treats current source as implementation signals only,
- does not include a current tutorial.
Failure Modes
| Failure | What it means | Safe response |
|---|---|---|
Docs show a webhook bootstrap.php key | Unsupported extension contract was invented. | Remove it and route through Evaluate before adding runtime support. |
| Page reads like a current tutorial | Future/planned status is not clear enough. | Reword around roadmap/prep and parity gap. |
| AI path claims an MCP tool exists | AI parity was overstated. | Mark the gap explicitly and require a future contract. |
| Event names are listed as stable | Internal behavior was promoted to public contract. | Remove the list unless a later contract freezes it. |