All changelog posts

• Jan 20, 2026

  <Subscription /> component

  Give users control over what notifications they receive - at the topic level. Create subscribe/unsubscribe flows that fit the context. Set workflow preferences and use advanced conditional rules. All of this can be done with a customizable React component.

  Authors:

  

  Paweł T., George D., Adam C.

  • New Feature
  • Subscriber Preferences

  

  v3.12.0 or higher

  We've introduced Subscriptions, a new way to manage notification delivery at the topic level. Now with full context-awareness, giving subscribers precise control over what they receive and when.

  

  The new <Subscription /> React component makes it easy to add subscription features to your app. You can use it for a simple “follow” button on a resource or a complete preferences view.

  

  • Subscribe or unsubscribe to topics (e.g., projects, issues)
  • Enable or disable specific workflows within a topic
  • Support conditional delivery rules (e.g., owner-only, thresholds, filters)
  • Context-aware preferences: manage subscriptions differently across environments, tenants, or custom contexts using contextKeys
  • Multiple subscriptions per topic with different conditions
  • Fully customizable UI with theming, localization, and headless hooks
  • Works seamlessly with Inbox and existing workflow/global preferences

  Previously, subscribers could only control notifications at the workflow or channel level.

  Subscriptions now unlock:

  • Topic-level muting (e.g., turn off updates for project:43)
  • Context-scoped preferences: filter and match subscriptions by context, with behavior safely gated behind the feature flag
  • Advanced, structured preferences stored as JSON conditions
  • Contextual subscription management directly on entities like projects or tasks

  Read more

  Behind the scene, we've added robust support for contextKeys throughout the inbox and subscription modules. Sorted for consistency, validated across commands, and integrated into identifier logic for uniqueness.

  This lays the groundwork for granular notification preferences in multi-context environments while maintaining backward compatibility when context features are disabled.

  Learn more about <Subscription /> component

  Improvements (5)

  • Removed the default custom font URL from block-based email content. Now, it uses system default fonts instead.
  • Subscriber preferences now support context-aware binding. You can set and retrieve preferences for specific contexts, such as tenants or environments. If there's no context-specific value, it will use the global preferences instead.
  • Pagination preferences now persist across sessions. When you change how many items show per page, it saves your choice. The next time you visit, your selection will be restored.
  • Webhook messages now include workflow and step identifiers. Each webhook payload now includes workflowId and stepId. This gives you better context for tracking and routing events.
  • You can now configure digest lookback windows directly in the workflow editor. When digest mode is on, you’ll find new options for how far back to look. You can pick from quick presets: immediately, 5 minutes, or 30 minutes. You can also enter a custom value.

  Fixes (1)

  • Fixed the problem where duplicating a workflow didn't copy schema fields. This includes payloadSchema, validatePayload, and severity. These properties are now correctly preserved when workflows are duplicated.

• Dec 22, 2025

  Native Slack and Microsoft Teams Integration

  Route notifications to Slack or Microsoft Teams channels and DMs using your app identity. One integration, simple OAuth per customer, and Novu handles the rest.

  Author:

  Adam Chmara

  • Chat
  • Slack
  • Microsoft Teams

  

  Notify Slack channels, Microsoft Teams, and users through DMs using your app identity.

  The new chat integrations let you connect your Slack app or Microsoft Teams bot to Novu. You can then route notifications to the exact destinations your users choose.

  Messages go where they’re needed. You can alert teams about server problems. You can update hiring managers on candidates. You can send operational alerts to specific channels.

  Both integrations work the same way:

  • First, set up your app credentials in Novu.
  • Then, let users connect their workspaces via OAuth.
  • Finally, register endpoints for channels or users.

  Novu handles token management. It routes messages and delivers them. All this happens across different customer tenants using a single integration.

  The Slack chat integration bot is currently in beta. Contact [email protected] to enable it for your organization.

  Multi-tenant by design

  A single Slack app or Teams bot can serve all your customers. Each customer connects their own workspace through a one-time OAuth consent flow.

  Novu keeps the connection for you. It sends messages on your app's behalf.

  You won't need to manage tokens. Also, you won't have to set up separate integrations for each customer.

  In Microsoft Teams, your customers grant admin consent only once. Then, Novu can send messages to any team or user with your app installed.

  Users authorize their Slack workspace, so you can quickly route messages to channels or DMs.

  Flexible delivery targets

  Create Channel Endpoints to define exactly where notifications should land:

  • Channels: Post to `#alerts`, `#engineering`, or any channel where your app has access
  • Direct messages: Send personal notifications to individual users
  • Webhooks: Use Slack incoming webhooks or Teams Workflows. They allow easy channel-only delivery without needing a full bot setup.

  // Create a Slack channel endpoint
  await novu.channelEndpoints.create({
    type: 'slack_channel',
    subscriberId: 'user-123',
    integrationIdentifier: 'slack',
    connectionIdentifier: 'conn_slack_acme',
    context: { tenant: 'acme' },
    endpoint: {
      channelId: 'C01234567'
    }
  });

  When you trigger a Workflow, Novu matches the subscriber and context to the right endpoints and delivers messages through the appropriate workspace connection.

  
  See the Slack integration guide and Microsoft Teams integration guide to get started.

• Dec 16, 2025

  New Cloud Regions: AU, KR, JP, SG, and UK

  Novu cloud infrastructure is now available in five additional regions, enabling lower-latency delivery and improved data residency support for teams operating in these geographies.

  Author:

  Himanshu Garg

  • Infrastructure

  

  Novu now supports deploying its cloud infrastructure in five new geographic regions: Australia (AU), Korea (KR), Japan (JP), Singapore (SG), and the United Kingdom (UK).

  This expansion enables you to run Novu services closer to your users in these regions, resulting in improved performance and enhanced data residency compliance.

• Nov 13, 2025

  Multi-Tenancy

  Novu now supports full multi-tenancy using Contexts, making it possible to isolate notifications, preferences, and credentials across tenants, workspaces, or applications within a single project.

  Author:

  Adam Chmara

  • Infrastructure

  You can now scope any notification to a specific tenant or workspace by attaching a Context when triggering workflows or configuring integrations.
  

  A Context acts as a persistent identity key for a logical boundary in your system:

  {
    "type": "tenant",
    "id": "org-acme",
    "data": { "name": "Acme Corp", "region": "us-east-1" }
  }

  All notifications, and credentials associated with that workflow run will inherit this Context automatically.

  How to use it

  When triggering workflows:

  await novu.trigger('payment-success', {
    to: { subscriberId: 'user-123' },
    payload: { amount: '$250' },
    context: { type: 'tenant', id: 'org-acme', data: { name: 'Acme Corp.', logo: 'http://logo.com' } },
  });

  • All generated messages are tagged with the tenant:org-acme key.
  • You can later query or filter by this key using the API.

  GET /v2/notifications?contextKey=tenant:org-acme

  Within templates or layouts, context.tenant.data can be used for branding or logic:

  {{context.tenant.data.name}} has a new billing update.

  Supported use cases

  • Per-tenant isolation for notifications
  • Tenant-level credentials for chat integrations (e.g., Teams, Slack)
  • Dynamic content and branding driven by context data
  • Workspace or app-level scoping within shared environments

  Real-world examples

  • A SaaS platform with multiple customer organizations sending workspace-specific updates.
  • An enterprise product using chat integrations where each workspace manages its own credentials.
  • An application separating preferences across multiple apps or environments under one Novu project.

  Multi-tenancy in Novu introduces a consistent and reliable way to manage notification boundaries across tenants, workspaces, or applications, without duplicating workflows or environments.

  
  Contexts make it simple to design systems where every notification and credential is tied to the right scope, predictable, queryable, and isolated by design.

  Learn more

• Nov 10, 2025

  Contexts

  Define tenant, app, or workspace context once, and Novu automatically scopes every notification, Inbox feed, preference, and delivery path to that context. No duplicated workflows, no custom filters, and no risk of cross-tenant leaks.

  Author:

  Adam Chmara

  • Infrastructure

  

  This feature is currently in beta. If you'd like to access Contexts, please email our support team at [email protected]

  A Context in Novu is a structured object that describes the environment or scope to which a notification belongs. Instead of embedding metadata (like tenant ID or app name) into every trigger payload, you can now store it once and reference it everywhere.

  Property	Description	Example
  type	Category key (e.g. tenant, app, region)	"tenant"
  id	Unique identifier within that type	"org-acme"
  data	JSON object with custom metadata	{ "name": "Acme Corp", "plan": "enterprise" }
  key	Unique composite identifier	"tenant:org-acme"

  

  Context object schema

  When defining contexts, Novu supports multiple formats per key-value pair, allowing you to store and reference metadata relevant to your workflows and templates.

  await novu.trigger('welcome-email', {
    to: 'user123',
    payload: { userName: 'John' },
    context: {
      // Simple string format
      tenant: 'acme-corp', 
      
      // Rich object format (ID only)
      app: { id: 'jira' },                    
      
      // Rich object format (ID + data)
      region: {                               
        id: 'us-east',
        data: {
          name: 'US East',
          timezone: 'America/New_York',
          currency: 'USD'
        }
      }
    }
  });

  How it works

  1. Create reusable contexts

  POST /v2/contexts
  
  {
    "type": "tenant",
    "id": "org-acme",
    "data": { "name": "Acme Corp", "plan": "enterprise" }
  }

  Contexts are stored with unique environment and organization indexes, ensuring clean separation across projects.

  2. Reference them in workflow triggers

  await novu.trigger('payment-success', {
    to: 'user-123',
    payload: { amount: '$250' },
    context: {
      tenant: 'org-acme',
      app: { id: 'jira', data: { name: 'Jira Integration' } },
    },
  });

  • Contexts can be passed as simple strings or rich objects.
  • Missing contexts are created automatically.
  • All related notifications, messages, and jobs store the context keys for traceability.

  3. Resolved automatically at runtime

  During message delivery, the worker reconstructs the context from its stored key(s), exposing all context data in your templates:

  {{context.tenant.data.name}}   →   Acme Corp
  {{context.app.id}}   →.  jira

  4. Manage through API or Dashboard

  • GET /v2/contexts/:type/:id — retrieve
  • PATCH /v2/contexts/:type/:id — update data
  • GET /v2/contexts — list & search
  • DELETE /v2/contexts/:type/:id — remove

  Visit the documentation to learn how to create, update, and retrieve a Context.

  <Inbox /> with Contexts

  Requires <Inbox /> version 3.11.0 or higher

  As products mature, they typically shift from serving a single user group to supporting multiple groups.

  Each organization, environment, or workspace has its own unique data, brand, and set of rules.

  Most notification systems regard users as a single group with the same feeds, which leads teams to create weak filters and have duplicate subscribers across different tenants.

  This is where <Inbox /> with Contexts excels for managing multi-tenancy. It offers built-in support directly at the notification layer, providing each tenant with a dedicated Inbox setup. This approach keeps your subscriber model and workflows intact without requiring any duplication.

  Inbox Scoped by Context

  When you render the Inbox, merely pass the same context:

  The <Inbox /> knows precisely which messages to load, filtered by context.

  Subscribers can switch between tenants or workspaces. Each one shows its own separate feed and settings.

  • Inbox A → tenant:org-acme
  • Inbox B → tenant:org-globex
  • Inbox C → tenant:org-novu

  Each has its own unread counts, archived messages, and rules. They all use a single subscriber ID (user-123).

  <Inbox  
    applicationIdentifier="YOUR_APP_ID"  
    subscriberId="YOUR_SUBSCRIBER_ID"  
    context={{ tenant: 'acme', app: 'dashboard' }}  
    contextHash="CONTEXT_HASH_VALUE"  
  />

  Learn how to use contexts in the Inbox component to filter and personalize notifications for your subscribers

  Improvements (2)

  • feat(dashboard,api-service, worker): include inbox unread count in the FCM and Expo messages available on the app badge
  • feat(worker): device token invalidation logic for FCM and Expo is now enabled, in active tokens will be removed and notified via the message.failed webhook

  Fixes (4)

  • fix(api-service,application-generic): Passing null values when updating subscriber will now properly recognize and persist them
  • fix(api-service): translation keys escaping bug caused \"\ fields when used escaped fields in the i18n files
  • fix(js): notification count display for 99+ was properly fixed, where previously 100 was shown.

  New Providers (1)

  • iSendPro - SMS Provider

• Oct 27, 2025

  Dynamic Delay

  Dynamic Delay (Payload-Driven Scheduling) lets you control when each workflow continues by passing a datetime field in your payload. Novu pauses and resumes execution at that moment, giving you precise, per-trigger delivery without fixed delays or cron rules.

  Author:

  Dima Grossman

  

  Schedule a workflow to pause until a datetime you provide at trigger time. Configure a Delay step with a delayPath, then pass the ISO datetime in your event payload. Each trigger can resume at its own time, making it ideal for appointment reminders, renewals, or any other per-user timing.

  What you can do

  • Per-trigger timing: Each event determines its own resume time via its payload.
  • Works anywhere in the workflow: Before or between any steps (including before digests).
  • Cancelable: Use transactionId to cancel pending delays.
  • Frictionless: No cron required for per-user scheduling.

  How it works

  In the Dashboard

  1. Add a Delay step
  2. Select Dynamic
  3. Set Path for scheduled date (e.g., payload.sendAt)

  At trigger time (API/SDK)

  Send an ISO 8601 UTC datetime on that path:

  {
    "workflowId": "appointment-reminder",
    "to": { "subscriberId": "user_123" },
    "payload": {
      "sendAt": "2025-12-01T09:00:00.000Z",
      "name": "Alex"
    }
  }

  The workflow pauses and resumes exactly at payload.sendAt.

  Behavior & validation

  • Required: delayPath on the step AND an ISO 8601 UTC value (...Z) in the payload.
  • If missing/invalid: The Delay job is canceled, and execution details show DELAY_MISCONFIGURATION with an error message.
  • If the datetime is in the past, it is rejected with a “future date required” error.
  • Canceling: client.cancel(transactionId) stops pending delay jobs for that transaction.

  Example Use Cases

  Appointment reminder

  • Delay (Scheduled) → delayPath = sendAt
  • After the delay → SMS/Email/In-app step
  • Trigger with sendAt per appointment.

  Subscription renewal

  • Delay (Scheduled) → delayPath = renewalAt
  • After the delay → Email/In-app notice
  • Trigger with renewalAt per subscriber.