Changelog

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 create

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.

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.

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.

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.

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.

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.

{
  "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.

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.

{
  "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.

{
  "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.

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.

Today we're introducing reusable requests, making it easy to reuse fetch step configurations across different workflows.

Save reusable requests

In the dashboard sidebar, you'll see a new "Reusable requests" section. Here you can create and manage your reusable requests that can be used in any fetch step across your workflows.

Once saved, these requests can then be applied to any workflow fetch step, making it easy to maintain consistent configurations across your messaging infrastructure.

Apply reusable requests to workflow fetch steps

Within a workflow fetch step, you'll see a new "Apply template" button. Here you can select a reusable fetch step to instantly inherit its properties. While linked, the fetch step will continue to inherit any changes made to the reusable request's configuration.

AI-generate reusable request configurations

We've also added the ability to generate reusable request configurations. This can be done by clicking the "Generate" button in the reusable request editor either during creation or when editing an existing request. This will use the prompt to auto-populate the request configuration.

More Information

To learn more about reusable requests, check out the documentation: Reusable fetch functions.

Fixes and improvements

• 👀 [Dashboard] Added realtime input validation in the content editor
• 👀 [Liquid] Added support for partial ISO dates across all of our date helpers
• 👀 [Dashboard] Added message previews to the Guide message log
• 👀 [Dashboard] Fixed performance issues in Guide content editor
• 👀 [SDKs] Added optimistic updates when archiving a message
• 🐛 [API] Fixed a bug with creating schedules with a null ending_at field
• 👀 [Dashboard] Added interacted metadata to the guide message log timeline
• 🐛 [Dashboard] Fixed the width of the HTTP channel button in the workflow step pane
• 🐛 [Dashboard] Fixed the callout UI within Deactivate workflow modal

Today we're releasing a significant improvement to our CLI with the ability for any user to log in via their Knock account.

Previously, in order to use the CLI, you would have to use a service token to authenticate. Service tokens are great for non-local, shared environments, like when using Knock inside your CICD pipeline. However, for engineers who want to work with their Knock resources locally, requiring them to create a service token was an unnecessary extra step.

Now, Knock users can simply knock login to gain access to the CLI and get started managing their Knock workflows, templates, and more in code. You'll be redirected from the CLI to your browser to authenticate and grant access to your Knock account. Users who have authenticated with the CLI will then be granted the same permissions they have in the dashboard.

We’re excited to make it even easier for you and the engineers in your organization to work with Knock locally via our CLI. You can read more and get started today via the docs.

Fixes and improvements

• 🐛 [Dashboard] We fixed an issue where resetting a variable could set the variable to an empty string, causing the default to not be applied.
• 🐛 [Dashboard] We fixed an issue with casing of custom fields during CSV upload mapping.
• 👀 [SDK] We've added the ability to opt out of inline-identify in the JS and React SDKs.