​
Event-Based triggers

Event-streaming is a loosely coupled SuprSend Integration where you can publish events to your event bus in a pub-sub model and build associated workflows within SuprSend. Whenever a notification needs to be sent, your system simply pushes an event containing the necessary data, while SuprSend handles all processing—such as determining which user to notify, fetching user profile and their preferences and computing target channels. This approach is ideal for notifications triggered in response to user-initiated actions.

Pros:

  • Decoupled integration: Just connect your event bus or microservice to SuprSend, and the entire notification logic stays inside SuprSend.
  • Single event can trigger multiple workflows.
  • Flexible workflow logic: You only need to pass the event name, actor, and relevant data. SuprSend determines the appropriate workflow, recipients, and notification channels.
  • Easily add new notifications without requiring engineering involvement.

Cons:

  • Users must be pre-created; inline user creation within a workflow trigger isn’t supported. Cannot send anonymous notifications.
  • No immediate response confirming whether the workflow was triggered.
  • Requires a persistent connection to continuously send and listen for events.
  • Workflow control is managed via UI, meaning changes can be made without engineering oversight. For critical triggers where failure isn’t an option, API-based triggers are recommended for immediate failure response.

Event-Based triggers are best suited for event streaming architectures, microservices orchestration, and service buses.

​
Workflow API

With API-based triggers, you explicitly call a workflow using its workflow-slug, specifying the workflow and recipients directly in the API request. This approach provides tighter integration with SuprSend and is ideal for system-generated workflows, such as sending a daily digest to all users in a company or sending anonymous notifications to unidentified users. It’s also useful for cases where you don’t want to setup a separate user sync and just want to pass user information within the trigger.

Pros:

  • Recipients and preferences can be identified inline.
  • Supports sending to anonymous users.
  • Recommended approach to **send notification to non-user entities like **object
  • Ideal for critical notifications, as you receive an immediate response when the workflow is triggered.

Cons:

  • Tightly coupled integration: Any changes to notifications or recipient payloads require code-level updates.

Workflow API is best for system-generated notifications where you need better control of triggers in your backend, or for sending to anonymous users or non-user entities like object.