Source Types

A Source Type defines a category of event producer. It determines which kinds of triggers can fire events and which flows they can target.

---

What Source Types Do

When you create a Flow, you link it to both a Source Type and a Sink Type. The Source Type gates which sources can trigger that Flow. For example, a Flow linked to the Webhook source type can only be triggered by webhook sources — a schedule cannot fire it.

Source Types also carry Config Params — key/value configuration pairs injected into source agents at runtime.

---

Built-In Source Types

Source Type	How It Triggers
Webhook	An HTTP POST to a unique URL creates an event. Each webhook source gets its own endpoint
Scheduler	A cron expression fires an event on a repeating schedule. Managed via the Schedules screen
Azure EventGrid	Messages from an Azure Event Grid topic subscription become events
MCP	AI agents using the Model Context Protocol create events directly. See the MCP Server guide for setup

Additional source types can be registered by your platform administrator.

---

Triggering a Webhook

Every Flow linked to the Webhook source type can be triggered over HTTP. The flow’s UUID is its webhook address — open the flow in the Flows screen and copy it from the Webhook address field in the Basics section.

The request

POST <webhook-node-host>/<tenant-uuid>/<flow-uuid>

Content-Type: application/json

{
  "type": "anything-you-like",
  "data": {
    "field": "value",
    ...
  }
}

• <tenant-uuid> — your tenant’s UUID (shown in the flow editor’s webhook hint)
• <flow-uuid> — the flow’s webhook address
• <webhook-node-host> — the platform’s webhook endpoint host. When the platform hosts the webhook node, the flow editor shows the complete URL directly; otherwise ask your platform administrator for the public host

A 201 Created response means the event was registered and queued for your flow’s sink type. Follow it on the Events screen.

Required fields

Every DATA parameter on the flow’s entry action must be present in data — those are the fields the action reads from the payload at runtime. A payload missing one of them is rejected with 422 (“Missing required fields for this event type”). STATIC and SECRET parameters are supplied by the platform, never by the payload.

Authentication

By default the webhook endpoint is open. When your platform secures it, two mechanisms apply:

• Token: request one with GET <webhook-node-host>/<tenant-uuid>/<flow-uuid>/token?type=<anything-you-like>, then append ?token=<token> to the POST. The token is computed from the flow UUID and the type value, so keep the type stable.
• Signature (svix/standard-webhooks): when WH_SIGNATURE_SECRET is configured, POSTs must carry the standard webhook-id, webhook-timestamp, and webhook-signature headers.

---

Securing a Webhook (per-tenant)

The platform’s Webhook template ships with security-first config params, so a copied webhook type requires both a token and a signature by default. Set it up in three steps:

1. Create the signing secret

On the Secrets screen, add a secret (e.g. key webhook-signing-secret). The value is write-only — the platform stores it encrypted and resolves it when your webhook type runs. Copy its secret://nx-secret/<key> URI with the copy button on the row.

2. Copy the Webhook template

On the Sources screen’s Types tab, click Make my copy on the Webhook template. The copy arrives pre-filled with the template’s three security params:

Param	Default	Meaning
ALLOW_UNSIGNED_REQUESTS	false	Reject POSTs without a valid signature header set
ALLOW_UNAUTHENTICATED_REQUESTS	false	Reject POSTs without a valid token or signature
WH_SIGNATURE_SECRET	secret://nx-secret/webhook-signing-secret	The secret used to verify signatures — pick yours from the Secrets dropdown

3. Point the SECRET param at your secret

Open the copied type, edit the WH_SIGNATURE_SECRET param, and pick your secret from the dropdown (the value is stored as a secret://nx-secret/<key> URI). The params also carry helper text explaining each setting.

How the two modes combine

With the secured defaults, a POST must pass both checks:

• Token mode — append ?token=<token> (obtained via the /token endpoint) and keep the type value stable between the token request and the POST.
• Signature mode — sign the request with the secret (standard-webhooks format): webhook-id, webhook-timestamp, and webhook-signature headers.

A request missing either is rejected with 403.

Existing flows keep working. Webhook copies made before the security params were seeded have no params, so they fall back to the deployment’s environment defaults — nothing you already run changes. Only new copies arrive secured. To secure an older copy, add the three params (or copy the template again).

If the platform has not configured a signing secret for its webhook node, signature verification is unavailable until it is configured.

---

Config Params

Source Types can have Config Params — key/value pairs that are injected into source agents at runtime. They use the same parameter types as other Nexomatic resources:

Type	Behaviour
STATIC	A fixed value baked into the Source Type definition
DATA	A key read from the event payload at runtime
SECRET	A secret key resolved from the Secrets store at runtime

Config Params are optional. Use them to pass environment-specific settings (API keys, endpoint URLs, feature flags) to source agents.

---

Creating a Source

Once a Source Type is defined, you can register individual Sources — specific instances of that type. For example, you might have three webhook sources, each with its own URL, all backed by the Webhook source type.

Types vs. instances. A Source Type is a template; a Source is your tenant’s instance of it. Copying or creating a type does not create an instance — after creating a custom Source Type (e.g. GeneralWebhook), create a Source of that type for it to start receiving events.

Make My Copy

Platform templates are inert until your tenant has its own copy. In the Sources screen’s Types tab, platform templates show a Make my copy action:

1. Click Make my copy on a platform template (e.g. Webhook).
2. Give your copy a name. The dialog shows the template’s config parameters, which ride along verbatim (edit them afterwards on the type edit screen).
3. Confirm — the copy becomes your tenant’s working type, with the same secret and the same node coverage as the template, so the platform node that serves the template also serves your copy’s instances. Copies show “based on