Workflows

In Notifly, every notification is a workflow: a named sequence of channel steps you design in the dashboard's visual editor and fire from your code with a single API call.

Triggering a workflow

A trigger names the workflow, addresses one or more recipients, and carries a payload your templates can interpolate:

curl -X POST https://api.notifly.io/v1/events/trigger \
  -H "Authorization: ApiKey $NOTIFLY_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "<workflow-id>",
    "to": { "subscriberId": "<subscriber-id>" },
    "payload": { "body": "Your build finished" }
  }'

The to field accepts a subscriber ID, a full subscriber payload, a topic, or a list of them. Delivery itself is handled asynchronously by dedicated worker processes consuming from Redis-backed queues, so the trigger call returns fast.

Digest

Workflows support digest steps: instead of sending each event immediately, related events are collected and delivered as a single summarized notification. This is the standard defense against notification storms ("57 people liked your post" instead of 57 pushes). The digest notifications guide walks through the regular, look-back and scheduled windows, with a worked example from trigger to delivered summary.

Translations (i18n)

Notifly resolves {{t.key}} translation placeholders at render time, using each subscriber's locale, on the actual delivery path — the same renderer serves both dashboard previews and real deliveries, so what you preview is what ships. Manage translation keys per environment in the dashboard; translation endpoints on the API are environment-scoped.

Environments

Workflows, subscribers, messages, and API keys all belong to exactly one environment (Development and Production by default). You iterate safely in Development and promote to Production when ready — the environment a request operates on is determined by the API key you authenticate with.

Topics

Topics let you fan a single trigger out to a group of subscribers (for example, everyone watching a project) without enumerating recipients in the trigger call. Topics are managed over the API alongside subscribers and workflows.

Related guides

• Subscribers: who a workflow sends to, and how to create and manage them.
• Step conditions: run a step only when rules on the payload, subscriber or context are met.
• Payload schema validation: describe the payload a workflow expects and reject bad triggers.
• Contexts: tag a trigger with the tenant or workspace it belongs to.
• Email layouts: the shared frame around your email steps.
• Environment variables: per-environment values and secrets for your workflows.
• HTTP request step signing: verify the signed calls the HTTP Request step makes to your server.