Changelog

The latest releases and improvements to Knock.

Feature illustration

Today we're releasing asset management, a centralized way to upload, host, and manage image files directly in Knock for use in your messaging templates.

With asset management, you can now:

  • Store assets directly in Knock. Upload and store images like logos, icons, and graphics in your Knock account without needing external hosting.
  • Reuse assets across templates. Browse and insert uploaded assets into any message template with a single click. No more copying and pasting URLs.
  • Centralized control. Assets live in one place and are referenced everywhere, so you can update visuals across messages without touching templates, making it easier to keep your brand assets consistent.

Currently, only image files are supported, including PNG, JPEG, GIF, and SVG. In the future, we may support additional asset types.

Asset management is available today for all Knock customers. Navigate to Content > Assets to upload and manage your assets, or read the documentation to learn more.

Chris Bell
Chris Bell
Feature illustration

Today we're releasing API key management, giving you more control over how you authenticate with Knock.

Previously, each environment in Knock had a single public and secret API key pair. This meant all of your integrations shared the same credentials, which made it difficult to rotate keys or limit access for specific use cases.

With API key management, you can now:

  • Create multiple API keys. Generate as many public and secret key pairs as you need per environment, enabling you to use dedicated keys for different services, integrations, or team members.
  • Revoke keys instantly. If a key is compromised or no longer needed, you can revoke it directly from the dashboard without affecting your other integrations.
  • Better security practices. Rotate keys on your own schedule and scope credentials to specific parts of your infrastructure.

API key management is available today for all Knock customers. You can manage your API keys from the Settings > API keys page in the dashboard, or read the documentation to learn more.

Chris Bell
Chris Bell
Feature illustration

Since we launched our CLI back in May 2023, teams have used it to work with their Knock-powered notifications in code and to programmatically manage their messaging infrastructure, making Knock an extension of their development workflow.

Today, we're thrilled to launch the 1.0 release of the CLI, with a whole host of new features and improvements to make working with Knock locally and in your CI/CD pipeline even easier.

With the 1.0 release of the CLI you can now:

  • Login to the CLI using your Knock account, without needing a service token via knock login
  • Initialize a central knock.json file for your project, and use that for all pull and push commands without specifying where your Knock directory is located
  • Work with all versioned resources in Knock (workflows, templates, guides, layouts, translations), commit and promote changes, list environments and channels, and much more
  • Create new resources directly without going to the Knock dashboard, or from our new template repository via knock workflow new

We've also included JSON schemas for all of your resource definitions, providing an editing assist and type hints in your IDE for you and your favorite coding agent like Cursor, Copilot, or Claude Code.

CLI 1.0 is also fully compatible with our new branching beta. Using the CLI you can create branches, push and pull changes on those branches, and merge changes from your branch back into main when complete.

If you're interested in trying out the 1.0 release of the CLI, you can get started by running npm install -g @knocklabs/cli or brew install knocklabs/tap/knock. You can also read the documentation to get started.

Chris Bell
Chris Bell
Feature illustration

Today we're excited to announce the beta release of branching, a new way for developers to work together in Knock.

Previously, all changes to versioned content in Knock had to be made in your development environment. That meant if you had multiple developers using Knock, changes needed to be carefully coordinated.

With branching, each developer can make changes in an isolated branch. Once changes are complete, the branch can be safely merged back into the development environment.

Branch management is deeply integrated into our management API and CLI, allowing you to use branching as a part of your everyday developer workflow or automate branches with your CI/CD pipeline. In addition, branching makes it possible to use Knock in preview environments, like those used by Vercel or Netlify. That means your team can test notification workflows end to end alongside other feature changes.

Branching unlocks an even better developer workflow within Knock, and we're excited to make it available today to all customers. If you're interested in trying out branching, you can request access from the dashboard on the Settings > Branches page. You can learn more in our documentation.

Matt Mikolay
Matt Mikolay
Feature illustration

Today we’re excited to announce the beta release of dynamic audiences.

Dynamic audiences are segments of users you can use to trigger workflows, target guides, or build broadcast lists. You can also use dynamic audiences in your workflow conditions and branches to check if a user is in an audience and route them accordingly.

Here are a few use cases you can power with dynamic audiences:

  • Target a guide announcing an enterprise plan feature to your enterprise admin audience
  • Trigger your new user onboarding workflow when a user enters your new signups audience
  • Send a re-engagement broadcast to your "has not logged in for 30 days" broadcast

Dynamic audiences run on the user data you already manage in Knock and are updated in real-time. We built dynamic audiences to be fast and ready to work at the scale of our largest customers.

As of today's release, our segmentation engine works with users and user properties. We'll be adding support for source events and object/tenant data next.

If you're interested in trying out dynamic audiences, let us know and we'll get you set up. You can learn more about dynamic audiences in our documentation.

Meryl Dakin
Meryl Dakin
Andrea Leopardi
Andrea Leopardi
Feature illustration

Today we’re introducing custom domains for link and open tracking for all Knock customers.

This allow you to use domains you own—rather than an auto-generated URL like e1.knock.app—for all tracked links in your messages. Aligning your tracking domains with your sending domain reduces the likelihood of spam filters flagging your messages and increases trust from users who expect links to come from you, not a third party.

Custom domains support granular configuration per message type and per environment. That means you can set up specific domains for specific purposes, such as one domain for short SMS links and another for long-form email URLs.

Custom domains are available today for all Knock customers. You can find out more in our documentation.

Chris Bell
Chris Bell
Feature illustration

We've made a number of improvements to reduce friction when working with recipients in the workflow and broadcast builder.

  1. Recipient always selected. When you open a workflow or broadcast, a recipient is now automatically selected so you can preview recipient data in your workflow.
  2. Object recipients. You can now toggle the recipient or actor field to “object” and select the object you want to use while building and previewing your workflow.
  3. Inline-identify from the recipient selector. You can now add a new user or object directly from the recipient selector, without needing to navigate away.
  4. Edit users and objects. A new “Edit” button lets you make changes to user or object properties without leaving the workflow builder.

These improvements also extend to the test runner, where you're now able to inline-identify and edit user data.

Fixes and improvements

  • 👀 [Dashboard] You can now view a diff of uncommitted changes that have been made to versioned resources in the "Changes" tab.
  • 🐛 [Dashboard] We fixed an issue where writing liquid within a JSON template would fail validation.
  • 🐛 [Notification engine] We now validate all chat channel data before processing a chat channel step. Missing data will now show an error.
  • 👀 [Notification engine] We now send a Knock specific User-Agent header for all webhook channel and outbound webhook requests.
  • 🐛 [Dashboard] We fixed an issue where request signing could not be set on reusable requests.
  • 🐛 [Dashboard] We fixed an issue where toggling preferences with conditions would fail via the dashboard.
  • 👀 [API] We now pass through the Slack retry-after ratelimit headers with all Slack requests.
Connor Lindsey
Connor Lindsey
Feature illustration

Today we're introducing new device-level metadata for tracking per-device locale and timezones for push channel data. Previously, push channel data was limited to tracking only tokens. Now, with device-level metadata, you can attach an additional timezone and locale field along with your token, and Knock will automatically evaluate them when sending push notifications.

Here's how it works:

  • Using the per-device locale you can localize push notification content to what your user's device has configured, taking precedence from the locale stored on the user. That means if your device is set to en-GB but your user has en-US on their user properties, any push notifications sent to the device will be generated in British english.
  • Similarly, using the per-device timezone you can control the precise send windows for when a particular device for a user should receive a push notification. This per-device value takes precedence over the user property.

Our client-side mobile SDKs have been updated with the ability automatically set this data for each device, or if you're using our API directly, you can replace the call to set tokens with a list of devices.

Setting channel data with devices
{
  "devices": [
    {
      "token": "user_device_token_1",
      "locale": "en-US",
      "timezone": "America/New_York"
    }
  ]
}

Push device metadata is available today for all customers. You can read more in our documentation.

Fixes and improvements

  • 👀 [Dashboard/mAPI/CLI] You can now opt into a private beta of branching. Head to your "Settings > Branches" page to request access.
  • 👀 [Dashboard] We added the ability to see all subscriptions that a user has from the users detail page.
  • 🐛 [Notification engine] We fixed an issue with our workflow trigger function where some child workflows were not running.
  • 👀 [API] We now expose a channel attached to each message produced from the API and sent via webhooks.
  • 👀 [mAPI] You can now filter commits by one or more resource_type (like workflow) to show all commits associated to that type of resource.
  • 👀 [Notification engine] We added a new compare_versions liquid filter.
  • 👀 [Notification engine] We now send workflow_category as a tag to Datadog and NewRelic when reporting metrics.
  • 👀 [Dashboard] You can now see the "Last login at" for the members of your account.
Andy Chang
Andy Chang
Feature illustration

Today we're introducing a new preference primitive: channel-level preferences.

While we've always had channel type preferences that let you control preferences for all messages sent for that channel type (like email), there were situations where you might have needed to be more granular with exactly what a user is opting out of.

As an example, if you're using our webhook channel to send messages in your workflow to both "PagerDuty" and "Incident.io", you would have no way in our existing preference model to set a preference for each of these channels, as both would be represented under the http channel type.

Now, using per-channel preferences, you can control exactly which channel a user should or should not receive messages from.

Setting channel preferences
{
  "channels": {
    // The PagerDuty channel
    "145a7412-2e9a-4ae4-ae2d-cbca4f5308fe": true,
    // The Incident.io channel
    "8b3c9f21-7d4a-4e1b-9c8e-f2a1b5d6c3e9": false
  }
}

Channel-level preferences work just like channel type preferences in that you can nest them under workflows or categories. They can even be mixed with channel_types.

Example workflow preference with channels and channel types
{
  "workflows": {
    "new-incident": {
      "channels": {
        // PagerDuty channel is OFF
        "145a7412-2e9a-4ae4-ae2d-cbca4f5308fe": false
      },
      "channel_types": {
        // All emails
        "email": true
      }
    }
  }
}

Channel-level preferences are available today for all customers. You can read more in our documentation.

Fixes and improvements

  • 👀 [CLI] All resources pulled by the CLI now have $schema fields attached, making it possible to get an editing assist when working with your schemas locally.
  • 👀 [mAPI] We've introduced new per-channel step level schemas in our OpenAPI spec to aid with editing. Instead of WorkflowChannelStep there's now WorkflowEmailStep, WorkflowInAppFeedStep etc.
  • 👀 [Dashboard] We've made some large performance improvements to the template editor within the dashboard. Previously, large documents with frequent saves were causing the performance of the editor to regress. Now things should be silky smooth!
  • 🐛 [Dashboard] We fixed an issue with the toolbar commands in our template editor.
  • 🐛 [Dashboard] We fixed an issue where autocompleting objects in liquid would show an empty value.
  • 🐛 [Notification engine] We fixed an issue where using a null actor on the workflow trigger step could cause it to fail.
Chris Bell
Chris Bell
Feature illustration

Today we're excited to release Knock Guides 1.0.

With Guides, you use your own components to power in-app messages that drive activation and upsells. Legacy in-app messaging vendors use external JavaScript libraries that bloat performance and degrade your design. Our component-first infrastructure keeps your app fast and your messaging on-brand.

Component-first in-app messaging

Guides are managed from the Knock dashboard. Once you hook a component into Knock, it's available for product managers and marketers to draft and preview content for that component, as well as target the audience for the guide and where it should render in your application.

Guide prioritization and throttling

You can manage guide prioritization and throttling to ensure users see the highest priority guides first and aren't flooded with messages when they log in to your product.

Observability and analytics

Knock Guides use the same powerful observability and analytics engine as the rest of Knock. Every guide records per-user events so you understand when users see, interact with, and archive your guides.

All of that data is available for debugging and analysis within the Knock dashboard, and will automatically flow through any extensions you've set up with Knock, like our data warehouse syncs or message event webhooks.

Key benefits

  • Composable primitives to build what you want. The guides toolkit provides React components, React hooks, lower-level JavaScript APIs, socket infrastructure so your engineers can build the in-product experience they want.
  • No performance tax. No external scripts to load, no performance tax. Your in-app messaging code runs through the same build process as the rest of your app.
  • Actual inline components. Complete control over your render lifecycle so you can ship truly embedded messaging without content layout shift, UI jank, or CSS conflicts.

Get started

Guides are available for all Knock customers starting today. You can get started by reading our documentation.

Sam Seely
Sam Seely