RudderStack Docs – Release Notes

Releases: Singular API v2 and SDID Support

Tue, 31 Mar 2026 00:00:00 +0000

RudderStack’s Singular cloud mode integration now supports Singular’s API v2 and SDID (Singular Device ID). When SDID is present in your event payloads, RudderStack automatically routes events to Singular’s v2 endpoints. Otherwise, events continue flowing to API v1 as before by leveraging platform-specific identifiers — without requiring any configuration changes.

This makes RudderStack the first platform to support Singular v2/SDID, enabling you to run an independent hybrid setup (Singular SDK for attribution + RudderStack SDK for data collection and routing) to keep events flowing when Singular enables SDID on their account.

Why we introduced SDID support

Singular is rolling out SDID (Singular Device ID) as a universal device identifier across customer accounts. When Singular enables SDID on an account, events sent via the v1 API continue to flow using legacy device IDs (IDFA, IDFV), but those identifiers only cover roughly 25% of iOS users post-ATT — leading to significant attribution accuracy degradation over time.

For teams running the recommended independent hybrid setup — where the Singular SDK handles attribution (installs, deep linking, SKAdNetwork, fraud detection) and RudderStack handles data collection and routing — this update ensures full attribution coverage. RudderStack now detects SDID automatically and routes to the correct API version, so your events are attributed accurately without any manual intervention.

Key features

Automatic SDID detection and API v2 routing: When integrations.Singular.singularDeviceId is present in an event payload, RudderStack routes the event to Singular’s v2 endpoints. Otherwise, API v1 is used — fully backward compatible.
Zero configuration changes: No new dashboard settings or connection updates are needed — detection and routing happen automatically.
LDS (Limit Data Sharing) privacy flag support: You can pass the limitDataSharing: true flag via integration options to honor GDPR/CCPA requirements in Singular.
Partner attribution: Events sent through RudderStack are tagged with partner=rudderstack for clear visibility in the Singular dashboard.
LAUNCH endpoint skip in hybrid mode: Prevents duplicate session creation when the Singular SDK already handles session tracking.
Platform ID handling: Automatically drops IDFA/AIFA device identifiers when SDID is present, aligning with Singular’s v2 requirements.

Get started

The steps below are for the Singular SDK + RudderStack cloud mode hybrid setup, where the Singular SDK generates the SDID.

If you use RudderStack cloud mode without the Singular SDK, you must generate and maintain the SDID yourself. See Singular Integration Setup Approaches to choose the right approach.

Ensure your Singular SDK is instrumented alongside the RudderStack SDK in your app. The Singular SDK must expose the SDID value.
Implement SDID bridge code from the Singular SDK to capture the singularDeviceId value in your app.
Pass the SDID in the integrations object of your RudderStack events:

rudderanalytics.track("Purchase Completed", {
 revenue: 99.99,
 currency: "USD",
 user_actual_id: 12345
}, {
 integrations: {
 Singular: {
 singularDeviceId: "<SINGULAR_DEVICE_ID>",
 limitDataSharing: true // Honors GDPR/CCPA
 }
 }
});

Verify events in the Singular dashboard — look for events tagged with partner=rudderstack to confirm delivery via API v2.

See Pass the Singular Device ID and Data Sharing Options for detailed instructions.

Resources

See the following guides for more information on this feature:

Releases: Stream Events to Snowflake Iceberg Tables

Tue, 17 Mar 2026 00:00:00 +0000

RudderStack’s Snowflake Streaming destination now supports Snowflake-managed Apache Iceberg tables. When enabled, your event data streams in real-time into your own cloud storage — S3, GCS, or Azure — in the Iceberg table format.

Snowflake manages the Iceberg metadata catalog and you get the speed of Snowpipe Streaming with the openness and portability of the lakehouse.

See the Snowflake Streaming to Iceberg Tables documentation for full details.

Why Iceberg tables?

Organizations adopting lakehouse architecture want the best of both worlds: the performance and governance of Snowflake with the openness and flexibility of storing data in their own cloud storage. Until now, Snowpipe Streaming wrote exclusively to standard Snowflake tables locked in proprietary storage — forcing a choice between real-time delivery and data portability.

That trade-off disappears with Iceberg table support. Your event data lands in open Parquet format on storage you control, accessible by any engine that reads Iceberg — Spark, Trino, Databricks, Athena — while Snowflake continues to serve as the primary query engine and catalog. You reduce vendor lock-in, gain multi-engine access, and maintain full storage lifecycle control, all without sacrificing delivery speed.

Key features

Near real-time streaming to Iceberg: Events are delivered via Snowpipe Streaming with ~30 second latency directly into Snowflake-managed Iceberg tables — the same low-latency pipeline, now writing to open storage.
Open Parquet storage on your cloud: Data is stored as Parquet files in your external volume (S3, GCS, or Azure). Query it from Snowflake, Spark, Trino, Databricks, Athena, or any Iceberg-compatible engine.
Automatic table creation: RudderStack automatically creates Iceberg tables with the correct catalog, external volume, and base location configuration. No manual DDL required.
Automatic schema evolution: New event properties are detected and columns are added automatically — your Iceberg tables stay in sync with your event schemas as they evolve.
Automatic compaction: Snowflake handles compaction of the underlying Parquet files, keeping query performance optimized without manual maintenance.
All standard event types supported: Track, identify, page, screen, group, and alias events all stream to Iceberg tables.

Get started

Ensure prerequisites are in place: You need a Snowflake account with Iceberg table support and an external volume configured in Snowflake pointing to your cloud storage (S3, GCS, or Azure).
Set up RSA key-pair authentication: Iceberg table support requires key-pair authentication. Password authentication is not supported for this feature.
Enable Iceberg in your Snowflake Streaming destination: Toggle on the Create Iceberg Tables setting in your Snowflake destination configuration.
Specify the external volume name: Specify the name of the external volume you created by following the steps here
Start sending events: RudderStack handles Iceberg table creation, schema evolution, and compaction automatically.

See the How to Configure Snowflake Streaming to Iceberg Tables guide for detailed setup instructions.

How it works

When you enable Iceberg in your Snowflake Streaming destination, RudderStack:

Sends events to Snowflake via the Snowpipe Streaming API
Lets Snowflake handle buffering and flushing rows to Parquet files
Relies on Snowflake to manage the Iceberg metadata and catalog

The following diagram illustrates the high-level data flow:

Known limitations

JSON fields stored as VARCHAR: Snowflake does not yet support the VARIANT data type for Iceberg tables. JSON data is stored as VARCHAR until Snowflake V3 adds VARIANT support.
No USERS table: Streaming mode is append-only and does not support MERGE operations, so the consolidated USERS table is not available.
~30 second minimum latency: This is a Snowflake-imposed constraint for Iceberg table writes.
TIMESTAMP_NTZ(6) instead of TIMESTAMP_TZ: Timestamps do not include timezone information in Iceberg mode.
Immutable Iceberg settings: External volume and Iceberg configuration cannot be changed after table creation.
Key-pair authentication required: Password-based authentication is not supported.

Resources

Screenshots

Releases: Custom Web Device Mode Integration

Mon, 16 Mar 2026 00:00:00 +0000

RudderStack now supports Custom Web Device Mode Integration, a new destination type that lets you write your own JavaScript code to connect the RudderStack JavaScript SDK to any browser-based tool.

If an integration for the tool you need isn’t already available in RudderStack’s integration catalog, you can build the connection yourself without waiting for RudderStack to add it. You handle the “last mile” delivery code (loading the third-party SDK and mapping events), while RudderStack continues to manage event collection, consent enforcement, event filtering, device mode transformations, and error isolation automatically.

Custom Web Device Mode Integration is included in every RudderStack plan — Free, Starter, Growth, and Enterprise — with no limits on the number of custom destinations you can create.

See the Custom Web Device Mode Integration documentation for full details.

Why Custom Web Device Mode Integration?

If you work with niche analytics tools, newly-launched marketing platforms, or proprietary in-house systems that run in the browser, you’ve likely hit a wall: RudderStack doesn’t have a pre-built integration for every tool. Until now, your options were to wait for RudderStack to build it, cobble together a workaround outside the platform, or look at other vendors entirely. None of those options are great when you’re trying to move fast.

Custom Web Device Mode Integration removes that bottleneck. With basic JavaScript knowledge, your frontend developers or data engineers can build a working client-side integration in hours, not weeks. The integration plugs directly into RudderStack’s event pipeline, so you keep all the platform features you already rely on (consent management, event filtering, transformations) without giving up control over which tools you connect to.

Key features

Simple JavaScript interface: Register your integration with a single API call (addCustomIntegration) and implement familiar methods — init, track, page, identify, group, and alias — to map RudderStack events to any destination’s API.
Full platform features preserved: Consent management (OneTrust, Ketch, iubenda, custom), client-side event filtering (allowlist/denylist), and device mode transformations all work automatically with your custom integration — no extra configuration required.
Error isolation and timeout enforcement: RudderStack sandboxes your custom code so that errors in your integration never affect other destinations or the SDK itself. A built-in readiness check polls every 100ms with a 30-second timeout to prevent stalled integrations from blocking event delivery.
Dashboard visibility and control: Set up and manage your custom destination directly in the RudderStack dashboard, just like any pre-built integration. Connect it to a JavaScript source, configure consent and filtering rules, and monitor it alongside your other destinations.

Get started

Follow these steps to set up and use a custom web device mode integration:

Step 1: Add the destination

In the RudderStack dashboard, add a new Custom Device Mode destination and connect it to your JavaScript (web) source. Optionally configure consent management and event filtering. Finally, copy the Destination ID — it is required for registering your integration (see Step 4).

(Optional) Step 2: Write and connect a transformation

If you need to transform events before they reach your custom integration, connect a transformation to the Custom Device Mode destination in the RudderStack dashboard. Then, enable the Device Mode toggle and configure the Propagate errors setting based on your requirements.

See Use Transformations in Device Mode for detailed instructions.

Step 3: Write your integration code

Implement your JavaScript integration object with the methods your use case requires. Your integration will receive the transformed events.

Step 4: Register and load

Call rudderanalytics.addCustomIntegration(destinationId, integration) before rudderanalytics.load().

If you’ve connected a device mode transformation to the destination in Step 2 and are explicitly specifying the SDK plugins, make sure to include the DeviceModeTransformation plugin in your plugins list.

See the Custom Web Device Mode Integration documentation for detailed setup instructions and code examples.

Resources

See the following guides for detailed instructions on using this feature:

Screenshots

Custom Device Mode destination setup in the RudderStack dashboard

Destination ID shown in destination settings

Releases: Android (Kotlin) SDK: Modern Analytics for Android

Thu, 12 Mar 2026 00:00:00 +0000

We’re pleased to announce the new Android (Kotlin) SDK for faster and efficient event tracking on your Android apps. It delivers up to 4x faster event processing with a modern, extensible architecture. Built with Kotlin coroutines and a plugin-based design, it provides type safety and cleaner payloads.

RudderStack recommends using the Android (Kotlin) SDK for all new Android implementations. The legacy Android (Java) SDK will continue to receive maintenance updates but no new features.

Why we built this

The legacy Android SDK served customers well, but modern Android development has evolved significantly. Developers now expect coroutine-based async handling, type-safe APIs, and modular architectures that integrate cleanly with Jetpack libraries.

The legacy SDK’s architecture made it difficult to add new capabilities without increasing complexity. Customers who wanted to customize event payloads or add custom processing logic had to wait for SDK team updates, thereby creating bottlenecks and slowing their implementation timelines.

The Android (Kotlin) SDK addresses these limitations with a ground-up redesign that embraces modern Android practices and gives you the extensibility to customize your implementation without waiting for SDK changes.

Key benefits

This section lists some key benefits of using the Android (Kotlin) SDK.

Performance

4x faster event processing: Optimized batching and burst handling dramatically improve event delivery speed to the data plane server

Developer experience

Coroutine-based async: Structured concurrency with proper lifecycle management replaces manual thread handling
Type safety: Compile-time safety with Kotlin’s type system catches errors before runtime
NavController integration: Automatic screen tracking with Android Navigation Component, including Compose support

Extensibility

Plugin architecture: Modular design lets you add custom plugins to modify, enrich, or process events without waiting for SDK updates
Multi-instance support: Run multiple SDK instances with different write keys in the same application

Maintainability

Cleaner payloads: Reduced redundancy by removing duplicate fields like context.traits.anonymousId, resulting in smaller and more consistent event data

How to use the SDK

For installation, initialization, and API usage, see the Android (Kotlin) SDK Quickstart. For configuration options, see SDK Configuration Options.

New and improved features

New features

Plugin architecture: Add, remove, and customize plugins at runtime
Automatic screen tracking with NavController: Track navigation destinations automatically with Fragment-based and Compose navigation
Multiple instances: Run separate SDK instances for different data sources
Shutdown API: Clean up SDK resources during runtime with analytics.shutdown()

See the New Features in Android (Kotlin) SDK guide for more information.

Improvements over legacy SDK

Configuration: Replace RudderConfig.Builder() chains with a direct Configuration(...) constructor
Properties: Use buildJsonObject { } for compile-time type safety instead of RudderProperty().putValue() with runtime checks
Async handling: Native coroutine integration replaces manual thread management
Plugin management: Add and remove plugins dynamically at runtime with add() / remove()

A sample SDK configuration is shown below:

// Kotlin SDK - cleaner, no builder pattern
val config = Configuration(
 writeKey = "WRITE_KEY",
 application = application,
 dataPlaneUrl = "DATA_PLANE_URL",
 logLevel = LogLevel.DEBUG
)

An example of type-safe properties is shown below:

val properties = buildJsonObject {
 put("product_id", "12345")
 put("price", 99.99)
}

See the following guides for more information:

Migrate from legacy Android SDK

The legacy Android (Java) SDK continues to work and receive maintenance updates, so you can migrate at your own pace.

The Android (Kotlin) SDK introduces API and payload changes from the legacy Android (Java) SDK. Event payloads remove redundant fields (for example, context.traits.anonymousId, context.traits.userId, context.userAgent) and the library identifier in payloads changes to com.rudderstack.sdk.kotlin.android.

If your downstream systems rely on these removed fields, make sure to update your transformations before migrating.

See the following guides for detailed API differences and migration process:

Breaking Changes in Android (Kotlin) SDK: For differences in SDK initialization, event API, and configuration mapping
Migration Guide: Migrate persisted SDK data (anonymousId, userId, traits, etc.)

SDK versions

SDK	Latest version
Android (Kotlin) SDK	1.2.0

Platform requirements

Platform	Minimum version
Android API	21+ (Lollipop)
Kotlin	1.7.0+
Java	8+

Resources

See the following resources for learning more about the Android (Kotlin) SDK:

The following guides will help you get started with the Android (Kotlin) SDK:

Releases: iOS (Swift) SDK: Modern Analytics for Apple Platforms

Thu, 12 Mar 2026 00:00:00 +0000

The new iOS (Swift) SDK replaces the legacy iOS (Obj-C) SDK with a modern architecture designed for today’s Apple development practices. Built with async-await, it introduces a runtime-flexible plugin system, multi-instance support, and expands platform coverage to include macOS alongside iOS, tvOS, and watchOS.

RudderStack recommends using the iOS (Swift) SDK for all new Apple platform implementations. The legacy iOS (Obj-C) SDK continues to receive maintenance updates but no new features.

Why we built this

The legacy iOS SDK was built in Objective-C when it was the dominant language for Apple development. As Swift has matured and become the standard, developers expect type-safe APIs, structured concurrency, and modern language features that Objective-C cannot provide.

The legacy iOS (Obj-C) SDK locked integrations at configuration time, making runtime modifications impossible. Customers who needed custom event processing or filtering had to request SDK changes, creating bottlenecks and slowing their implementation timelines.

The iOS (Swift) SDK addresses these limitations with native Swift concurrency, a dynamic plugin system for runtime customization, and expanded platform support including macOS. It lets you use a single SDK across Apple platforms.

Key benefits

This section lists some key benefits of using the iOS (Swift) SDK.

Developer experience

Modern Swift concurrency: Built with async-await and structured concurrency for non-blocking operations and better app responsiveness
Enhanced identity access: Type-safe direct property access to anonymousId, userId, traits, and sessionId
macOS support: Native support for macOS 12.0+ alongside iOS 15.0+, tvOS 15.0+, and watchOS 8.0+

Extensibility

Plugin architecture: Dynamic plugin management lets you add, remove, and modify event processing without waiting for SDK updates
Multi-instance support: Create multiple isolated analytics instances with independent state, storage, and configuration

Stability

Shutdown API: Explicitly shut down and clean up SDK resources with event persistence across restarts

Maintainability

Cleaner payloads: Removed redundant identity fields from context.traits for smaller, consistent event data

How to use the SDK

For installation, initialization, and API usage, see the iOS (Swift) SDK Quickstart. For configuration options, see SDK Configuration Options.

New and improved features

New features

Plugin architecture: Add, remove, and customize plugins at runtime
Multiple instances: Run separate SDK instances for different data sources
Shutdown API: Clean up SDK resources during runtime with analytics.shutdown()

See New Features in iOS (Swift) SDK for more information.

Improved features

Flexible reset API: Reset specific identity values (anonymousId, userId, traits, session) individually instead of all-or-nothing
Enhanced custom context: Pass any JSON value type (strings, arrays, nested objects, booleans) to customContext, not just dictionaries
Flexible integration options: Pass configuration objects to integrations instead of just boolean toggles
ExternalId on all event types: Set externalId on track, screen, and group events—not just identify
Direct destination instance access: Access destination plugin instances anytime with getDestinationInstance() instead of waiting for callbacks
Custom logger: Configure centralized logging with pluggable implementations via LoggerAnalytics.setLogger()

See the Improved Features in iOS (Swift) SDK guide for more information.

Migrate from legacy iOS (Obj-C) SDK

The legacy iOS (Obj-C) SDK continues to work and receive maintenance updates, so you can migrate at your own pace.

The iOS (Swift) SDK introduces API and payload changes from the legacy iOS (Obj-C) SDK. For example, event payloads remove redundant identity fields such as context.traits.anonymousId, context.traits.userId, and context.traits.id.

If your downstream systems rely on these removed fields, update your transformations before migrating.

See the following guides for detailed API differences and migration steps:

Breaking Changes in iOS (Swift) SDK
Migration Guide: Migrate persisted user data (anonymousId, userId, traits, and so on)

Platform requirements

Platform	Minimum version
iOS	15.0+
macOS	12.0+
tvOS	15.0+
watchOS	8.0+

Resources

See the following resources for learning more about the iOS (Swift) SDK:

The following guides will help you get started with the iOS (Swift) SDK:

Releases: Braze Multi-App Key Support

Fri, 06 Mar 2026 00:00:00 +0000

You can now configure platform-specific App Identifier Keys for iOS, Android, and Web within a single Braze destination. The RudderStack SDK automatically selects the appropriate key based on the device/platform type at runtime, falling back to the Default App Key if a platform-specific key is not provided.

This feature is currently in Beta and behind a feature flag. It is expected to be generally available by March 31, 2026.

Contact RudderStack Support to enable this feature for your account.

For setup instructions, see the Braze destination documentation.

Why we built this

Braze recommends using separate App Identifier Keys for each platform to ensure proper data attribution and analytics segmentation. Previously, RudderStack only supported one App Key per Braze destination, which meant customers with multi-platform apps (iOS and Android) needed to create separate Braze destinations for each platform.

This was especially problematic for teams using cross-platform frameworks like React Native or Flutter, where RudderStack treats these as single sources but Braze requires separate app keys for each underlying platform.

With Multi-App Key Support, you can consolidate your setup into a single Braze destination while still following Braze’s recommended configuration.

Key features

Platform-specific keys: Configure separate App Identifier Keys for Android, iOS, and Web within one destination
Automatic routing: The RudderStack SDK detects the platform at runtime and routes events to the correct Braze app
Cross-platform support: Works seamlessly with React Native and Flutter sources
Backward compatible: Existing configurations with only the Default App Key continue to work without changes

How to use it

Navigate to your Braze destination settings in the RudderStack dashboard
Enable the Enable Platform-Specific App Identifier Keys toggle
Enter the App Identifier Keys from your Braze dashboard for each platform (Android, iOS, Web)
The Default App Identifier Key serves as a fallback for any platform without a specific key configured

This feature applies only to device mode connections. Cloud mode connections do not use App Identifier Keys.

SDK upgrade required

To use platform-specific keys, upgrade your device mode SDK to the minimum supported versions:

SDK	Minimum Version
Android (Kotlin)	1.2.0
iOS (Swift)	1.0.1
React Native	2.1.0
Flutter	2.5.0
Android (Java) — Legacy	2.1.1
iOS (Obj-C) — Legacy	4.2.1

If you keep the Default App Identifier Key configured, older SDK versions will continue to work using the default key.

Resources

See the following guides for detailed instructions on using this feature:

Releases: P95 Latency Alerts for Event Stream Destinations: General Availability

Fri, 27 Feb 2026 00:00:00 +0000

P95 latency alerts for Event Stream cloud destinations are now Generally Available for all Enterprise customers.

You can now configure P95 latency thresholds for your Event Stream cloud destinations and receive alerts whenever event delivery slows beyond acceptable limits. For example, if you set a P95 latency threshold of 15 minutes and 95% of events aren’t delivered within that window, RudderStack triggers an alert on your configured delivery channels — Slack, email, Microsoft Teams, or a custom webhook.

This helps you catch delivery delays early, troubleshoot proactively, and keep stakeholders informed before issues escalate.

What’s new

Generally available: P95 latency alerts are no longer in beta. They are fully supported and available for all Enterprise customers.
Expanded access: Previously, only Admins could view the P95 latency metric. Now, any user subscribed to P95 latency alerts for a destination can also view its latency metrics directly in the Events tab.

P95 latency alerts apply only to Event Stream destinations connected to sources in cloud mode.

They do not apply to Reverse ETL connections, warehouse destinations, and device mode connections.

See the following guides for more details:

Set up P95 latency alerts: Configure alert thresholds for your destinations
View the P95 latency event metric: View and interpret the P95 latency metric for your destination

Screenshots

Configure P95 latency alerts in the RudderStack dashboard:

View the P95 latency metric for a destination:

View the P95 latency for events coming from a particular source:

Releases: Bot Management

Mon, 23 Feb 2026 00:00:00 +0000

We are excited to announce Bot Management, a data governance feature that detects, flags, and drops bot traffic on web sources before it enters your data pipelines. By identifying and managing bot events early in your data flow, you can significantly improve data quality and reduce unnecessary costs.

Why Bot Management?

Managing bot traffic has traditionally required implementing custom detection logic in downstream systems, leading to inconsistent bot detection across your analytics stack and inflated costs from processing non-human events. Bot Management eliminates these challenges by providing a centralized, reliable filtering layer that standardizes bot detection across your web sources.

Key features

User agent-based detection: Automatically identifies bot events using predefined bot patterns to detect common bots, crawlers, and automated traffic.
Flexible event management: Choose to flag bot events for downstream analysis or drop them entirely at the gateway to prevent unnecessary processing costs.
Workspace and source-level configuration: Set global bot management settings for all web sources or apply custom configurations for individual sources based on your specific requirements.
Real-time bot metrics: Monitor bot event volume patterns at the source level through the source Events view. For more details, see View Bot Event Metrics.
Cost optimization: Drop bot events at the gateway to reduce billable event volume and prevent unnecessary costs across pipelines, data stores, and analytics tools.

Get started

Bot Management is available in all RudderStack paid plans. You can get started with just a couple of clicks — navigate to Govern > Bot Management in your RudderStack dashboard and enable bot detection for your workspace.

See the Bot Management documentation for detailed instructions.

Resources

See the following guides for detailed instructions on using this feature:

Screenshots

Bot management view in the RudderStack dashboard

Bot management global setting

Source-level bot event management

Bot event metrics in the source page

Releases: RudderStack Tracking Assistant Browser Extension

Wed, 21 Jan 2026 00:00:00 +0000

We are excited to announce the Events Tracking Assistant, a browser extension for Chrome and Firefox that transforms how you debug and validate your JavaScript SDK implementation. It provides instant visibility into your RudderStack setup directly in your browser.

Why Events Tracking Assistant?

Debugging SDK implementations has traditionally required waiting 1-5 minutes for events to appear in the dashboard, piecing together information from browser’s developer tools, or filing support tickets for complex issues. The Events Tracking Assistant eliminates these friction points by providing real-time feedback in under one second.

Key features

Real-time event monitoring: See events the moment they fire with full payload inspection, filtering by event type, and visual status indicators.
SDK health dashboard: Instantly view SDK version, write key, data plane URL, installation type (CDN vs NPM), and CSP compatibility.
Destination and plugin visibility: Monitor device-mode destination status and debug configuration issues without leaving your browser.
SDK injection: Test RudderStack on any website without code changes — ideal for evaluation, prototyping, and demos.
One-click debug export: Export comprehensive debug data including SDK state, events, and logs to streamline support communication.

Installation

All data processing occurs locally in your browser. The extension does not transmit captured events or SDK information to external servers.

Get started

Install the extension from the Chrome Web Store or Firefox Add-ons.
Navigate to any website with the RudderStack JavaScript SDK installed.
Open the extension to instantly view your SDK configuration, health status, and real-time events.
Use the Events tab to monitor event payloads as they fire, or the Overview tab to inspect destinations and plugins.
Export debug data with one click to share with your team or RudderStack support.

Resources

See the following guides for detailed instructions on using the extension:

Releases: Snowflake Streaming Destination: General Availability

Mon, 08 Dec 2025 00:00:00 +0000

The Snowflake Streaming destination is now Generally Available. This integration delivers event data to Snowflake in seconds via continuous micro-batches using Snowflake’s Snowpipe Streaming API, enabling real-time analytics, alerting, A/B testing, and fresher data for personalization and AI/ML use cases.

Key benefits

Real-time data availability: Events appear in Snowflake within seconds, not hours, enabling immediate insights and activation
Cost-efficient streaming: Uses Snowpipe Streaming API instead of warehouse compute, maintaining the same or lower cost compared to batch integration while dramatically reducing latency
Full platform integration: Leverage all of RudderStack’s native capabilities including Transformations, Tracking Plans, and other Data Governance capabilities
Enterprise-grade reliability: Built on RudderStack’s proven event streaming infrastructure with monitoring and alerting

Seamless migration

Existing Snowflake batch destination users can migrate seamlessly using the Assisted Migration feature. This guided workflow wizard creates and configures your new Snowflake Streaming destination, manages the pipeline transition, and minimizes duplicate records during migration.

To start the migration, go to your existing Snowflake batch destination in the RudderStack dashboard and look for the Migrate to Snowflake Streaming banner.

See the Snowflake Streaming Migration Guide for more information.

Pricing and packaging

Snowflake Streaming is an Enterprise feature, but we’re offering a free trial to all paying RudderStack customers through June 8, 2026. After the trial period, Snowflake Streaming will be available as an add-on for non-Enterprise customers.

Get started

To set up the Snowflake Streaming destination:

Add a source in your RudderStack dashboard.
Select Snowflake Streaming from the list of destinations.
Configure your connection settings and credentials.
Connect your sources and start streaming.

See the Snowflake Streaming documentation for detailed setup instructions and configuration options.

Releases: Cloud Extract End of Support Announcement

Mon, 01 Dec 2025 00:00:00 +0000

After careful consideration and a strategic evaluation of our product portfolio, RudderStack is ending support for Cloud Extract (our ETL offering).

Here’s what you need to know:

End-of-support date: December 1, 2025. Starting from this date, RudderStack will no longer provide support or respond to support tickets for ETL pipelines.
Pipeline shutdown date: January 10, 2026. All ETL pipelines will be turned off on this date. Users will no longer be able to activate or toggle on their pipelines.
Access until shutdown: Current RudderStack Growth and Enterprise customers will retain access to Cloud Extract pipelines until January 10, 2026.

For account-specific details or assistance with transition planning, contact RudderStack Support for the specifics.

Why RudderStack is sunsetting Cloud Extract

RudderStack’s core competencies include event collection (Event Stream), governance (Data Quality and Data Compliance Toolkits), unification (Profiles), and activation (Reverse ETL & Real-time integration).

By focusing on these areas, we are better positioned to continue to innovate and provide the best possible solutions for your data needs.

Reach out to us for any queries.

Releases: Snowflake Streaming Assisted Migration Feature

Tue, 28 Oct 2025 00:00:00 +0000

Migrating from RudderStack’s traditional Snowflake batch destination to the new Snowflake Streaming destination unlocks real-time data ingestion using Snowflake’s Snowpipe Streaming API. However, manually managing this migration — including creating new destinations, reconnecting sources, and coordinating the cutover — can be complex and risky.

With the assisted migration feature, you can now migrate your existing Snowflake pipelines with a guided workflow that handles all the heavy lifting for you. This feature automatically creates and configures your new Snowflake Streaming destination, manages the transition between pipelines, and minimizes duplicate records during the migration process.

Key capabilities

Automated destination setup: RudderStack creates a new Snowflake Streaming destination using your existing batch destination credentials and configuration, preserving your schema and table mappings.
Guided verification: A step-by-step workflow prompts you to verify that events flow correctly through the new Snowflake Streaming pipeline before completing the migration.
Automatic pipeline coordination: The Snowflake batch destination is automatically paused during migration to minimize duplicate records while both pipelines are active.
Final sync trigger: You can trigger a final sync from the batch destination to ensure any events collected during the pause are loaded to your warehouse.
Rollback capability: If any errors occur during setup, you can roll back to your previous state without any data loss.
Deduplication guidance: Receive migration timestamps and documentation to help you deduplicate any records that may have been ingested during the transition.

Why migrate to Snowflake Streaming?

The Snowflake Streaming destination delivers event data to Snowflake in seconds via continuous micro-batches, enabling real-time analytics, alerting, A/B testing, and fresher data for personalization and AI/ML use cases. Because it uses the Snowpipe Streaming API instead of warehouse compute, it maintains the same or lower cost compared to the batch integration while dramatically reducing latency.

Get started

Go to your existing Snowflake batch destination in the RudderStack dashboard.
Look for the Migrate to Snowflake Streaming banner.
Click Proceed to initiate the assisted migration process.

Follow the guided steps to verify your new Snowflake Streaming destination and complete the migration. If needed, reference the provided timestamps to deduplicate records in your target tables.

See the Snowflake Streaming Migration Guide for more information on manual migration options and deduplication queries.

Screenshots

Releases: Conditional Validation Support in Rudder CLI

Wed, 01 Oct 2025 00:00:00 +0000

RudderStack’s Tracking Plans enable data teams to apply type-safe governance to event schemas. While our governance features ensure consistency and predictability, real-world applications often require schemas to adapt based on business context.

With the release of Conditional Validation, you can now define validation rules that dynamically adjust based on discriminator properties. This powerful capability addresses a common challenge — maintaining strict data quality standards while accommodating legitimate variations in your event data structure.

With conditional validation, you can:

Define context-aware validation rules that adapt based on specific property values
Prevent event proliferation by consolidating similar events with varied requirements
Enforce granular validation on custom types that need to behave differently in different scenarios
Maintain data quality without sacrificing flexibility for legitimate business variations

You can leverage conditional validation both on the event schema level and within custom types, and manage everything via workspace configuration files using Rudder CLI.

Use cases

This section provides some examples of using the conditional validation feature.

Event-level conditional validation

Adaptive page tracking: Single Page Viewed event with different required properties based on page type — for example, search term for search pages, product details for product pages, checkout step for checkout pages
Context-aware form submissions: Different required fields based on form type or user journey stage
Dynamic feature usage tracking: Varying property requirements based on feature context or user role

See Event Rule Variants for more details on creating and managing event rule variants in your Tracking Plans using Rudder CLI.

Custom type conditional validation

Regional address formats: Different required fields for US addresses (state + ZIP) vs. UK addresses (postcode) vs. Japanese addresses (prefecture + district)
Manufacturer vs. marketplace products: Require MSRP and Manufacturer ID for direct products, and require Seller ID for marketplace items
Account tier-specific profiles: Different required profile fields for individual vs. business vs. enterprise accounts

See Custom Type Variants for more details on creating and managing custom type variants using Rudder CLI.

How it works

Conditional validation uses discriminator properties to determine which validation rules apply. A discriminator is a required property whose value triggers specific validation cases.

For example, in an ecommerce tracking scenario:

Discriminator property: page_type (enumerated list defined in Data Catalog)
Variant cases:
- When page_type = search_page: Require the search_term property
- When page_type = product: Require the product object property

Result: Same event handles both scenarios with appropriate validation.

Implementation

Conditional validation works at two levels:

Event rule variants

Define variants within your tracking-plans.yaml to create context-aware event validation:

version: "rudder/v0.1"
kind: "tp"
metadata:
 name: "ecommerce_tracking_plan"
spec:
 id: "ecommerce_tracking_plan"
 display_name: "Ecommerce Store - Tracking Plan"
 description: "Comprehensive tracking plan for the casual apparel e-commerce demo site built with React TypeScript. Captures user behavior across product discovery, cart interactions, and purchase completion for analytics and optimization."
 rules:
 - type: "event_rule"
 id: "page_viewed_rule"
 event:
 $ref: "#/events/ecommerce_events/page_viewed"
 allow_unplanned: false
 properties:
 # Base properties required for all page views
 - $ref: "#/properties/ecommerce_properties/page_type"
 required: true
 - $ref: "#/properties/ecommerce_properties/page_name"
 required: false
 - $ref: "#/properties/ecommerce_properties/page_url"
 required: false

 # Conditional Validation Variants
 variants:
 - type: discriminator
 discriminator: "#/properties/ecommerce_properties/page_type"
 cases:
 - display_name: "Product Detail Page"
 match:
 - "product"
 description: "When user is viewing a specific product page"
 properties:
 - $ref: "#/properties/ecommerce_properties/product"
 required: true

 - display_name: "Search Results Page"
 match:
 - "search"
 description: "When user is on search or category pages"
 properties:
 - $ref: "#/properties/ecommerce_properties/search_term"
 required: true

 # Default case for home and other pages (only page_url required)
 default:
 - $ref: "#/properties/ecommerce_properties/page_url"
 required: true%

Custom type variants

Define variants within your custom-types.yaml to create reusable, context-aware object types:

version: "rudder/v0.1"
kind: "custom-types"
metadata:
 name: "ecommerce_types"
spec:
 types:
 # Product Type - Consolidates all product-related properties with conditional MSRP validation
 - id: Product_Object
 name: "Product_Object"
 description: "Custom type for product information with conditional manufacturer pricing validation"
 type: "object"
 properties:
 - $ref: "#/properties/ecommerce_properties/product_id"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_sku"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_name"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_category"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_price"
 required: true
 - $ref: "#/properties/ecommerce_properties/manufacturer_pricing"
 required: false
 # Conditional Validation Variants for Product Object
 variants:
 - type: discriminator
 discriminator: "#/properties/ecommerce_properties/manufacturer_pricing"
 cases:
 - display_name: "Product with Manufacturer Pricing"
 match:
 - true
 description: "Products that have manufacturer suggested retail price (MSRP)"
 properties:
 - $ref: "#/properties/ecommerce_properties/product_msrp"
 required: true

Deploy the changes to your workspace

rudder-cli apply -l ~/path_to_tracking_plan_dir

See the Conditional Validation documentation for more details.

Releases: Custom Types Support in Rudder CLI

Thu, 17 Jul 2025 00:00:00 +0000

Building on our recent Custom Types release, you can now define Custom Types directly in your workspace configuration files and deploy them using Rudder CLI. This enhancement brings Custom Types into your existing infrastructure-as-code workflows, enabling you to version control and programmatically manage complex data validation rules.

With workspace config and CLI support, you can now:

Define Custom Types as code: Create a custom-types.yaml file alongside your existing Tracking Plan configurations, enabling version control and collaborative development of data governance rules.
Reference Custom Types in properties: Use Custom Types as property types in your properties.yaml files, eliminating the need to redefine complex validation logic across multiple properties.
Deploy via CLI: Use the rudderstack tp apply command to push Custom Types and their associated properties to your workspace, integrating seamlessly with your existing deployment workflows.

This release complements the existing Data Catalog API and Git-Based Data Catalog and Tracking Plan Management, giving development teams full flexibility in how they manage data governance across their organization.

Get started

Create a workspace config file: Add custom-types.yaml to your Tracking Plan directory alongside your existing configuration files.
Define your Custom Types: Define your custom type rules.
Reference your Custom Types: In your properties.yaml file, you can define a property that references your previously defined custom types.
Validate and Deploy with CLI: Use the Rudder CLI tool to validate the YAML configurations and apply changes to your workspace.

See the Use Custom Data Types in Rudder CLI guide for more details on creating and managing custom types using Rudder CLI.

Sample snippets

Defining custom types in workspace configuration files

version: "rudder/v0.1"
kind: "custom-types"
metadata:
 name: "ecommerce_types"
spec:
 types:
 # Product Type - Consolidates all product-related properties
 - id: Product_Object
 name: "Product_Object"
 description: "Custom type for product information including ID, SKU, name, category, pricing"
 type: "object"
 properties:
 - $ref: "#/properties/ecommerce_properties/product_id"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_sku"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_name"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_category"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_price"
 required: true
 - $ref: "#/properties/ecommerce_properties/product_msrp"
 required: false

Reference custom types within a property configuration

version: "rudder/v0.1"
kind: "properties"
metadata:
 name: "ecommerce_properties"
spec:
 properties:
 # Product Custom Type Property
 - id: "product"
 name: "product"
 type: "#/custom-types/ecommerce_types/Product_Object"
 description: "Product information object containing all product details"

Deploy the changes to your workspace

rudder-cli apply -l

Releases: Snowflake Streaming Destination

Wed, 18 Jun 2025 00:00:00 +0000

We are excited to announce our new Snowflake Streaming destination. This integration enables real-time data streaming into Snowflake using the Snowpipe Streaming API.

Integration highlights:

Snowflake Streaming is ideal for continuous data streaming like clickstream data or event logs, supporting use cases like real-time dashboards, streaming analytics, and real-time A/B testing analysis.
Loading data through Snowflake Streaming reduces compute time, optimizing warehouse costs while ensuring faster insights
For main use cases, Snowflake Streaming empowers businesses to act on customer data quickly, driving competitive advantages through timely, data-driven decisions

See our docs for more information on when to use Snowflake Streaming.

Setup guide

To set up the Snowflake Streaming destination, follow these steps:

In the RudderStack Connections page, click Add Destination
Search for Snowflake Streaming and select it.
Name the new destination and select your sources.
Input the destination configurations and credentials.
Click Continue to finalize the destination.

See the Snowflake Streaming Destination docs for more information on setting up and using this integration.

Screenshots

Add Snowflake Streaming destination

Input destination configurations and credentials

Configure advanced settings for the destination

Releases: Cursor Column Support for Reverse ETL Syncs

Thu, 15 May 2025 00:00:00 +0000

Previously, RudderStack’s Reverse ETL Upsert mode was diff-based, meaning it compared every column and row to detect changes from your source table in order to determine what records needed to synced. This led to longer sync times and higher warehouse costs, particularly for large tables.

With Cursor Column support, you can leverage a timestamp value checkpoint for the diff. This optimizes Reverse ETL syncs by allowing you to specify a comparable timestamp column (for example, updated_at) to track incremental changes in Upsert mode. RudderStack will then query only records with a cursor value greater than the last checkpoint, avoiding resource-intensive, full-table comparisons.

By reducing the computational load of warehouse queries, this feature lowers operational costs and speeds up syncs, especially for large datasets.

Setup guide

RudderStack does not support migrating existing Reverse ETL connections from upsert mode to cursor mode. You must create a new Reverse ETL connection to use the cursor column feature.

Create a new destination connected to a warehouse table or SQL model as a source.
After adding the destination credentials and mappings, choose Upsert as your sync mode.
Turn on the Cursor Column toggle.
Choose the timestamp column you want to use as the cursor column.
Initiate your first sync.

RudderStack will perform a full sync on the first run.

After the first run, RudderStack will use the cursor column to identify any new or updated records that arrive in the source table and sync those records on any subsequent sync jobs.

See our Cursor Column Support docs for more information on this feature.

Screenshots

Releases: Full Sync Mode Support

Wed, 14 May 2025 00:00:00 +0000

We’re excited to announce Full Sync mode—a new Reverse ETL sync mode that gives you more control over how data flows from your warehouse to various business tools.

Similar to Upsert and Mirror modes, Full Sync mode is configured at the connection level. It ensures that the entire dataset is sent on every sync—this is ideal for teams that already handle change detection or diffs inside the warehouse.

Key details

Full Sync mode is configured when creating a Reverse ETL connection.
RudderStack will send the full model result set on each sync, overwriting or resending all records based on the destination’s behavior.

This mode offers maximum flexibility for advanced teams that prefer to own the sync logic in their warehouse, while still benefiting from RudderStack’s destination coverage and scheduling infrastructure.

When to use Full Sync mode

Warehouse-managed diffs: If you’re using tools like dbt or scheduled jobs to determine which records to send, Full Sync mode lets you send that curated dataset downstream, exactly as it appears in your warehouse.
Destinations with limited support for updates: Some tools or custom endpoints do not handle upserts or partial updates well. Full Sync mode guarantees that the complete table is refreshed every time, reducing downstream inconsistencies.

Learn more about the Full Sync mode in our docs

Screenshots

Releases: Tracking Plan Code Generation

Tue, 06 May 2025 00:00:00 +0000

Event data quality has never been more important, but even for teams that run tight processes, details can get lost in translation. Between the creation of an event schema definition and the instrumentation of the API call to fire the event from the codebase of the website or app, simple mistakes can create big problems downstream.

RudderStack’s new Code Generation (Codegen) feature automatically creates clear code snippets that software engineers can use in their instrumentation. The code snippets ensure property and trait keys are accurate, provide samples for selected data types, and clearly denote whether the key is optional.

The Codegen feature is in Public Beta as part of RudderStack’s Early Access Program, where we work with early users and customers to test new features and get feedback before making them generally available.

Contact the Product team if you have any questions.

As part of this release, we’ve made significant updates to the UI for our schema view and have completely overhauled the schema editing experience, which significantly simplifies schema buildout and updates.

See our Tracking Plan Codegen docs for more information.

Screenshots

Releases: Loops Destination

Fri, 25 Apr 2025 00:00:00 +0000

Today, we launched Loops as a cloud mode destination. Now you can seamlessly send your events from RudderStack to Loops for effective email marketing.

Loops is a popular email platform for SaaS companies for sending marketing and transactional emails from the same platform.

See the Loops destination documentation for more information on setting up and using this integration.

Releases: Userpilot Destination

Wed, 23 Apr 2025 00:00:00 +0000

Today, we launched Userpilot as a destination. Now you can seamlessly send your events from RudderStack to Userpilot for effective user onboarding and engagement.

Userpilot is a no-code product experience platform that helps you enhance the user onboarding experience. It allows you to drive user activation, boost feature adoption, and improve user retention through personalized in-app experiences.

See the Userpilot destination documentation for more information on setting up and using this integration.

Releases: Enhanced Shopify Source Solution

Tue, 08 Apr 2025 00:00:00 +0000

Every Shopify store is different, and we are excited to deliver a solution that reflects that. RudderStack’s new Shopify Source Solution offers two powerful tools:

RudderStack Shopify Pixel App: Downloadable from the Shopify Marketplace and offers fast, automatic tracking.
RudderStack Custom Pixel: A code option hosted on our GitHub that allows the RudderStack JavaScript SDK to be loaded onto your store. It also supports customizations to the event tracking for precision control.

Together, these tools provide three tracking methods:

App Pixel for browser-based ease
Webhooks for reliable server-side data
Custom Pixel for tailored flexibility

Whether your store is fully Shopify-hosted or a hybrid with a self-hosted pre-checkout, you can mix and match these approaches to fit your needs. Ultimately, the Shopify Source Solution empowers you to harness your customer data with ease, delivering it to RudderStack instantly for analytics, marketing, or beyond - freeing you up to focus on growth with confidence.

How this new Shopify source compares with other tools in the industry

Shopify event tracking is often a one-size-fits-all struggle as it lacks best practice Shopify event tracking and misses the adaptability modern stores need.

RudderStack’s comprehensive Shopify Source Solution is designed to support five different Shopify store setup scenarios and consists of the two powerful tools and three different event tracking methods as mentioned above.

How it works

Install the App Pixel, insert the code into a Custom Pixel, or do both. Your data will begin to flow instantly - enriched and ready for action.

Here’s how to set up the Shopify Source Solution in a few simple steps:

Choose your tool: Install the RudderStack Shopify Pixel App directly from the Shopify Marketplace for quick setup, or grab the RudderStack Custom Pixel code from our GitHub to add into Shopify’s Customer Events settings.
Pick your tracking method: With the App Pixel, enable Shopify’s automatic browser tracking, Webhooks for server-side reliability, or both. For the custom pixel, paste the code into the custom pixel and make any adjustments as needed.
Connect to RudderStack: Ensure that you configured the data plane URL and the Shopify source write key correctly so that it points to the RudderStack Shopify source.
Test and activate: Preview your tracking in RudderStack’s Live Events, tweak as needed, and go live to start routing data to 200+ destinations.

See our Shopify Source Solution documentation for the detailed implementation steps.

Screenshots

Shopify source setup in RudderStack dashboard

RudderStack App Pixel setup in Shopify

RudderStack Custom Pixel setup in Shopify

Releases: Capture Incoming Request Details in Webhook Source Events

Mon, 07 Apr 2025 00:00:00 +0000

We have released an enhancement to our Webhook source that introduces a new dashboard setting - Send Source Request Details in Events Context.

When you enable this toggle, RudderStack automatically captures and includes details of the incoming HTTP request like headers, query parameters, request method, etc., in the context object of each event.

Feature overview

Toggle on the Send Source Request Details in Events Context setting for your Webhook source:
- For new sources: Turn on the setting while setting up your source in the RudderStack dashboard.
- For existing sources: Navigate to your webhook source and go to the Configuration tab. Then, turn on the toggle.
All incoming requests will now automatically populate the context object with fields that include headers, query_parameters, method, etc. in every event.
You can then write a transformation to use these values as per your requirement before converting the event into a destination-specific format.

For more information on how to use this feature, see our Webhook source documentation.

Screenshots

Releases: CLI-based Data Governance

Wed, 02 Apr 2025 00:00:00 +0000

We are excited to announce CLI-based data governance workflows in RudderStack. Our new CLI utility and other features make it easy to manage your data catalog and tracking plans as code.

With CLI-based data governance, you can bring the same rigor and process to your data governance workflows that you apply to other development workflows, giving you more control, increased visibility, and ultimately better data quality.

This feature is in Alpha as part of RudderStack’s Early Access Program, where we work with early users and customers to test new features and get feedback before making them generally available.

Note that these features are functional but can change as we improve them. Contact the Product team if you have any questions.

Key features

Some key features of CLI-based tracking plans management include:

Declarative YAML configuration

Define your events, including their names and descriptions, in YAML format.
Create reusable properties with advanced validation rules like min/max length, patterns (through regular expressions), and enums.
Define tracking plan rules by associating events with required properties using a structured reference system.
Reuse property definitions across multiple events with a standardized path reference system.

Powerful CLI tool

The new workflow comes with a powerful Rudder CLI tool that lets you:

Create, update, and delete data catalog and tracking plan resources via command line.
Verify your YAML configurations before pushing changes.
Sync changes in your local files or GitHub repo to RudderStack.

The CLI utility currently only supports pushing to RudderStack, so we recommend starting with a clean workspace (pulling existing assets from the UI is in the works!). Reach out to our team if you would like us to create a dedicated workspace for testing. See our list of limitations to learn more about current differences between the CLI and UI.

Git Integration & CI/CD support

Leverage GitHub Actions to automatically validate and deploy tracking plans from your repository.
Implement version control by tracking changes, managing branches, and reviewing modifications through standard Git workflows.
Review any tracking plan changes before they reach production.

Use Cases

This feature is particularly valuable for teams who:

Manage large tracking plans with hundreds of events and properties.
Need better integration with existing development workflows.
Want to maintain consistent tracking standards across multiple applications.
Require version control and review processes for data governance.

Get started

Install the Rudder CLI tool in your preferred environment.
Generate a workspace-level Service Access Token in the RudderStack dashboard with the following permissions to manage Data Catalog and Tracking Plans:

Resource	Permissions
Tracking Plans	Create & Delete, Edit
Data Catalog	Edit

Token permissions for legacy RBAC system

If you are on the legacy Permissions Management (RBAC) system, your workspace-level Service Access Token should have Admin permissions.

See this documentation for more information on generating the token.

For testing or development purposes only: Generate a Personal Access Token with Read-Write role

RudderStack recommends using a workspace-level Service Access Token for authentication.

Any action authenticated by a Personal Access Token will break if the user is removed from the organization or a breaking change is made to their permissions.

Initialize a new Tracking Plan project with YAML definitions. Then, sync the changes to your workspace.
Automate Tracking Plan management using GitHub Actions.

Releases: Event Stream Destination Latency Metrics

Thu, 27 Mar 2025 00:00:00 +0000

For data teams, managing stakeholder expectations is critical - they want to see the right data arrive on time.

For data engineers running RudderStack, a variety of factors can impact how quickly data is delivered to destinations. Some variables, like complexity of Transformations attached to a destination, are within your control. In many cases, though, latency can increase due to external factors like sudden traffic spikes or degraded performance of a destination API.

Previously, it was difficult for data engineers to troubleshoot data delays for specific destinations.

Now, RudderStack Org Admins can see granular latency metrics for every cloud destination, giving them visibility into delivery latency and equipping them to better manage stakeholder expectations.

These metrics include:

P95 latency for the selected time window: 95% of data is delivered within or faster than this time. For example, if P95 latency for the last two hours is 9 seconds, that means that 95% of events delivered over the last two hours were delivered within 9 seconds or less.
Latency trend: The latency trend shows P95 latency at intervals over the selected time window. This view is helpful for isolating the timing and impact of increased or decreased latency.

See our P95 Latency Event Metrics documentation for more information on this feature.

Screenshots

Releases: Warehouse Sync Metrics

Wed, 26 Mar 2025 00:00:00 +0000

Loading event data into a data warehouse is one of the most common use cases for data teams running RudderStack. A majority of the time sync jobs run without issues, but factors like significant spikes in volume, corrupted data, and other issues out of the data team’s control can make sync jobs run longer than normal. This latency can impact scheduled jobs, reporting, and other use cases for consumers of the data.

Previously, troubleshooting potential latency problems required manually scrolling through a list of sync jobs. Not only was that time consuming, but there was no way to see trends over time.

With warehouse sync metrics, you can see max sync duration over multiple time windows (2 hours, 1 day, 7 days, and 30 days), and see the duration of each individual sync job within the selected window.

With these observability tools, you can more quickly isolate potential problems with data delivery and understand how changes in your data might impact load performance over time.

See our Event Metrics documentation for more information on this feature.

Screenshots

Releases: HTTP Webhook Destination

Thu, 13 Mar 2025 00:00:00 +0000

Many teams need to send events to destinations that require a custom integration - whether it’s an internal endpoint, a third-party service RudderStack doesn’t yet support, or a specialized API.

Earlier, setting up a webhook destination required writing a custom user transformation, making it difficult for non-technical users to configure.

With our new HTTP Webhook destination, you can now quickly and easily configure custom destinations without writing a single line of code.

Key Features

Total control over event payloads: Define the format and structure of the request.
Flexible authentication options: Choose from various authentication mechanisms.
Batching support: Send multiple events in a single request.
Dynamic configurations: You can use JSON paths to customize:
- Request payload fields by mapping values from incoming RudderStack events
- Dynamic or static URL paths and query parameters
- Dynamic or static custom headers

See below for more exciting new features coming soon.

How this integration compares to the existing webhook destination

RudderStack’s existing webhook destination provides flexibility but comes with several limitations:

Requires coding: You must write a JavaScript or Python transformation to structure the request.
No built-in dynamic fields: Dynamic URLs, headers, and query parameters all require coding.
Limited payload formats: This integration only supports JSON as the request format.
No native batching: You must send event to the endpoint individually.

The new HTTP Webhook destination removes these barriers, making it much easier for users to send events without much developer involvement.

What’s next?

This Beta release is just the beginning! We are already working on several enhancements to make the HTTP Webhook destination even more powerful.

Upcoming features 🚀

Event previewer: See how your events look in real time as you configure the destination.
Conditional routing: Customize request types, payload formats, and endpoints based on event type (for example, different endpoints for identify vs. track events).
Custom code support: Optionally add JavaScript for more granular control over payload formatting.
Enhanced batching: Greater flexibility for APIs with strict batching requirements.
OAuth Authentication: Expanding authentication options beyond the basic headers.
Failure Handling: Define retry logic and error-handling based on the response status codes.

We’re excited to continue evolving this product and look forward to your feedback!

Get started

You can set up your first HTTP Webhook destination with just a few simple steps:

Create a new destination in RudderStack and select HTTP Webhook.
Enter the base destination URL where you want to send events (for example, your API endpoint).
Choose your request format (JSON, XML, or Form) and define how your event payload should be structured.
Set authentication if required - RudderStack supports various authentication mechanisms like Bearer Tokens, API keys, Basic Auth, etc.
Map event fields dynamically using JSON paths to configure query parameters, headers, and the request body.
Send a test event to validate your setup and ensure your events are formatted correctly.

See our HTTP Webhook destination documentation for detailed steps on setting up and using this integration. You can also watch our demo video here for a step-by-step walkthrough and see how easy it is to configure a custom destination in minutes.

Screenshots

Releases: Facebook Lead Ads Source

Wed, 12 Mar 2025 00:00:00 +0000

Today, we released Facebook Lead Ads as an Event Stream source. Now your can send all your leads data from Facebook to your entire customer data stack via RudderStack.

How does this integration work?

Once you set up the Facebook Lead Ads source in RudderStack, copy the webhook URL. Then, follow the steps in the Configure webhook section to set up the integration.

See our Facebook Lead Ads documentation for detailed information on setting up and using this source.

Releases: Destination Event Details

Mon, 10 Mar 2025 00:00:00 +0000

Data engineers running RudderStack often get questions from their stakeholders about potential problems with event delivery to a specific destination.

Previously, the events view on destinations was limited, showing only a basic chart and failure responses by top-level event type.

Now, you can see a full list of events that RudderStack has attempted to deliver to each destination, including diagnostic data for:

Successful deliveries
Time of last successful delivery
Failures
Time of last failure

You can also drill into individual events to see granular failure information, including sample payloads.

Note that table shows post-transformation event names, which ensures you are seeing the exact events that RudderStack is delivering to your destination, even if you have modified the event name or have generated new events in a user transformation.

See our Event Metrics documentation for more information on this feature.

Screenshots

Releases: Transformation Failure Alerts

Fri, 07 Mar 2025 00:00:00 +0000

You can now configure dedicated alerts for Transformation failures, giving you the ability to take immediate action when problems arise.

Transformation failures can happen for multiple reasons:

Unexpected data causing errors
Testing not covering all use cases across production data, or
A source with new data is connected to the destination.

Previously, these failures would materialize as cloud destination failure alerts, making it difficult to trace problems. With dedicated transformation failure alerting, you’ll be notified if there is an unexpected problem and can take action immediately.

With this feature, you can configure a global failure rate threshold (applicable for all transformations) and specific thresholds for individual transformations.

See Transformation failure alerts for more information on this feature.

Screenshots

Releases: Events Tab 2-hour Time Window

Fri, 14 Feb 2025 00:00:00 +0000

Previously, the Events tab view in the Sources, Transformations, and Destinations configured in RudderStack defaulted to a 1-day time window.

Now, the Events tab defaults to a 2-hour time window, giving you much more granular visibility into data flow over the last few hours.

In the 2-hour view, data flow is shown in 5-minute increments, helping you:

Review recent spikes or drops in traffic and events with higher precision.
Troubleshoot potential issues as soon as they arise.
Quickly validate if the fixes are having the desired effect.

See our Event Metrics documentation for more information on this feature.

Screenshots

Releases: Customer.io Audience Destination

Wed, 05 Feb 2025 00:00:00 +0000

Today, we launched Customer.io Audience as a Reverse ETL-compatible destination.

You can now use this integration to sync data from your Reverse ETL sources to Customer.io for creating and updating user segments.

See our Customer.io Audience documentation to get started.

Releases: Custom Types for Data Catalog Properties

Tue, 28 Jan 2025 00:00:00 +0000

RudderStack’s Tracking Plans feature makes it easy for data teams to apply type-safe governance to event schemas flowing through RudderStack. Advanced rules enable you to create types and rules on individual properties, but for teams managing hundreds of properties, individual rules can be limiting.

With the release of Custom Types, you can now build and manage a separate, centralized library of rules, and apply them to multiple properties across your Data Catalog. Custom Types give you the ability to:

More easily manage and apply the same rule across multiple properties.
Implement more complex rules for properties.

You can also create and manage Custom Types via the Data Catalog API.

Example use cases

Array of enums: With Custom Types, you can combine rules and types for complex use cases. For example, you could define enum values as a Custom Type, then use that Custom Type in a property defined as an array, enabling you to govern an array of enums.
Sub-property bundles: If you need to add sub-properties to multiple properties, you can create an Object Custom Type, add the list of specific sub-properties, and apply them to properties in your Data Catalog.
Custom date formats: If you need to enforce a specific date format across multiple different date properties, you can create a Custom Type with your specific logic, then use that type for those properties.
Custom address formats: If you need to enforce formats for different types of addresses (residential and commercial, for example), you can create Custom Types for each and apply them to different properties.

Screenshots

Releases: Support for Azure DevOps Git URLs Starting with ssh while Importing Profiles Project

Tue, 21 Jan 2025 00:00:00 +0000

RudderStack now supports Azure Git URLs starting with ssh while importing your Profiles project from a Git repository.

With this enhancement, you can now use Azure DevOps as a Git provider for your Profiles project in addition to the previously supported ones, that is, Google cloud sources, AWS CodeCommit, GitHub, GitLab, and Bitbucket.

Read more about this feature in the Import Profiles Project from Git guide.

Releases: Iterable Observability Enhancements

Wed, 08 Jan 2025 00:00:00 +0000

Today, we released some important observability and error reporting enhancements for the Iterable destination, applicable to both Event Stream (cloud mode) and Reverse ETL connections.

With these changes, faulty events previously misclassified with an HTTP 200 status code but failed to deliver to Iterable are now correctly marked with the relevant error codes and Iterable API responses.

You will see improved error reporting in the RudderStack dashboard for:

Events sent to Iterable with non-existent user IDs.
Validation errors due to data type mismatch for the fields passed in the events.
Disallowed event names.

As a result of these changes, you may observe an increase in reported errors (based on traffic, event volume, and issues with sent events), giving you improved visibility and enabling faster resolution.

Contact the RudderStack team for more information on this enhancement.

Releases: RudderStack Dagster Integration

Tue, 07 Jan 2025 00:00:00 +0000

Today, we are excited to announce the launch of the dagster-rudderstack Python library, which integrates RudderStack with Dagster. This integration allows teams to seamlessly orchestrate RudderStack Profiles and Reverse ETL jobs within their existing Dagster workflows. You can also define cross-system dependencies, ensuring your warehouse operations are synchronized and optimized beyond the boundaries of RudderStack.

Overview

As organizations integrate more data sources into their workflows, the processes of cleaning, transforming, and activating data become increasingly complex.

Orchestration tools like Dagster simplify these processes by enabling teams to schedule jobs, define dependencies, and maintain reliable, maintainable, and observable data pipelines. Its modular design and support for modern data practices empower teams to streamline workflows, reduce errors, and focus on delivering actionable insights.

Feature walkthrough

Workflow

Install the dagster-rudderstack Python package.
Use the RudderStack-specific operations to define Profiles runs and Reverse ETL syncs within jobs.
Define RudderStack-specific resources like connection details (access tokens, connection IDs, etc.)
Define a schedule.

See the RudderStack Dagster integration docs for more information on using this tool.

Releases: Topsort Cloud Mode Integration

Tue, 24 Dec 2024 00:00:00 +0000

Today, we launched Topsort as a cloud mode destination in RudderStack. Now you can send events across your cloud mode sources from RudderStack to Topsort seamlessly.

Topsort is a popular advertising and marketing automation platform. It powers retailers and marketplaces to launch optimized ad businesses at scale.

See the Topsort destination documentation for more information on setting up and using this integration.

Releases: Profiles IDE

Wed, 18 Dec 2024 00:00:00 +0000

The Profiles IDE provides a seamless, production-ready environment for developing and deploying your Profiles projects directly within the RudderStack dashboard. It supports in-platform project management and integration with external version control systems like GitHub and GitLab.

Key features

Integrated editor for building and modifying YAML-based Profiles configuration files.
Safe validation of workflows through separate development schemas.
Easy rollbacks of uncommitted changes with a button click.
Automated notifications when multiple users are editing a project simultaneously.

Workflow

You can use the Profiles IDE to modify inputs, build features, and safely validate the changes in a controlled session, before committing them to the production project.

Here’s how to use the feature:

New Profiles project

Select the Web-based editor (IDE) option while creating a new Profiles project.
Provide the project name, warehouse credentials, and output schema for storing the results.
Click Open in editor mode.

Existing Profiles projects

Go to the Settings tab of the Profiles project.
Click Editor mode.

See the Profiles IDE documentation for more details on using this feature.

Screenshots

Editor mode option after creating a new Profiles project.

Editor mode option in an existing Profiles project.

Specify development/validation schema for testing the changes.

Modify configuration, view the changes, and commit to the production schema.

Releases: LinkedIn Audience Destination

Fri, 22 Nov 2024 00:00:00 +0000

We are pleased to announce LinkedIn Audience as a Reverse ETL-compatible destination. Now you can send data from your warehouse to LinkedIn via RudderStack for efficient targeting and segmentation.

See our LinkedIn Audience documentation to get started.

Releases: SSO Support for Other Providers

Wed, 20 Nov 2024 00:00:00 +0000

RudderStack now supports setting up and enabling SSO for your organization for various SSO providers in addition to the existing SSO providers like Okta, OneLogin, and Azure Entra ID.

Workflow

You can integrate RudderStack SSO with your own SSO provider by following these three simple steps:

Specify the configuration settings in your SSO provider’s admin dashboard.
Configure the SAML 2.0 custom attributes.
Contact the RudderStack team to enable SSO for your organization.

See our Generic SSO Setup Guide for more details.

Releases: Warehouse Observability Enhancements

Wed, 20 Nov 2024 00:00:00 +0000

RudderStack’s latest warehouse observability enhancements give you detailed insights into why the data going to a warehouse destination was discarded, especially in cases where there is a data type mismatch and the event data does not conform to the Warehouse Schema.

How the feature works

RudderStack discards any event data going into a warehouse destination that does not strictly conform to the Warehouse Schema spec and cannot be fixed.

In such cases, RudderStack puts the discarded records into a rudder_discards table along with a reason. With the latest observability enhancements, the reasons will give more insights on exactly why the data was discarded.

Some examples are shown below:

incompatible schema conversion from string to boolean
incompatible schema conversion from string to int
incompatible schema conversion from datetime to string
incompatible schema conversion from bigint to float

Releases: Server-side Cookies

Tue, 19 Nov 2024 00:00:00 +0000

You can now set server-side cookies in the JavaScript SDK, ensuring users are tracked across sessions over time, even when browsers expire client-side cookies.

Web browsers are increasingly implementing user tracking restrictions. For example, Safari’s Intelligent Tracking Prevention (ITP) automatically expires client-side, third-party cookies after 7 days. Suppose one of your visitor’s cookies expire and they return to your website. In that case, RudderStack’s JavaScript SDK sees them as a new user and assigns them a new unique anonymousId- this can create challenges for customer journey tracking, attribution analytics, and identity resolution because the ID and session data would show two users when, in reality, it is the same user returning to your website.

With this release, you can configure the JavaScript SDK to set server-side cookies, which aren’t subject to the client-side cookie expiration timelines enforced by Safari and other browsers.

Read our server-side cookies documentation for more information on this feature.

Workflow

To implement server-side cookies, set theuseServerSideCookies option to true while loading the JavaScript SDK.

rudderanalytics.load(WRITE_KEY, DATA_PLANE_URL, {
 useServerSideCookies: true // Default is false
});

Setting server-side cookies requires that you make the cookie request to your website domain.

Most customers use a proxy, but the SDK also supports custom implementations.

How it works

The JavaScript SDK makes explicit POST requests to the server to set cookies via the /rsaRequest endpoint:

The response includes Set-Cookie headers which set the rl_anonymous_id cookie (user’s anonymousId value which is persisted through the server-side cookie).

Releases: Gainsight PX Web Device Mode Integration

Wed, 30 Oct 2024 00:00:00 +0000

Today, we launched the web device mode integration with Gainsight PX. Now you can send events from RudderStack to Gainsight PX via the native Gainsight PX SDK.

See the Gainsight PX destination documentation for more information on setting up and using this integration.

Releases: Sprig Mobile Device Mode Integration

Tue, 29 Oct 2024 00:00:00 +0000

Today, we launched mobile device mode support for the Sprig destination.

Now, you can send events from your Android (Java) and iOS (Obj-C) sources (in addition to the previously-supported native web SDK) in device mode to Sprig in order to collect relevant user insights and boost your product adoption.

See our Sprig destination documentation for more information on adding the mobile device mode integration and sending events.

Releases: Service Access Tokens

Thu, 24 Oct 2024 00:00:00 +0000

We have expanded access to our APIs and services with Service Access Tokens (SATs). SATs can be created at the organization or workspace level and are not tied to individual user accounts.

SATs are ideal for production use cases and centralized management of tokens across the RudderStack platform.

Previously, access to RudderStack APIs required you to create Personal Access Tokens, which are tied to an individual user’s account. If that user account was removed, or permissions on the account were changed, access to APIs and services was impacted as well.

With this release, you can create and manage central SATs to ensure stability and security for critical production workflows.

Contact the RudderStack team to get access to this feature.

How it works

Org Admins can create SATs at the organization or workspace level.

Organization-level SATs can be used to access SSO SCIM and the Audit Log API, used for managing SCIM users and accessing audit logs from the platform, respectively.

Workspace-level SATs can be used to access resources in a specific workspace. These are used to manage programmatic workflows that leverage RudderStack APIs. Some examples are:

Using the Transformations API to manage Transformations programmatically.
Using the Data Catalog API to programmatically manage your Data Catalog and Tracking Plans.
Using the Test API to run programmatic end-to-end pipeline tests.

Operations performed by both SAT types are logged and are available through the Audit Logs view and the Audit Logs API.

Create a SAT

To create SATs, Org Admins can access the Service Access Token view by going to Settings > Organization > Service Access Tokens tab.

Click the Organization or Workspace tab followed by Generate new Token to generate a new Organization-level SAT or Workspace-level SAT.

See the Service Access Token documentation for more information.

Screenshots

The following screenshots highlight the SAT generation flow:

Generate an organization-level SAT:

Copy newly-generated organization-level SAT:

Generate a workspace-level SAT:

Specify workspace-level SAT permissions:

Copy newly-generated workspace-level SAT:

Releases: TUNE Destination

Tue, 22 Oct 2024 00:00:00 +0000

Today, we launched TUNE as a cloud mode destination. Now you can send your events from RudderStack to TUNE seamlessly.

Contact the RudderStack team to get access to this integration.

TUNE is a popular affiliate marketing platform for tracking and managing your data and partner programs to optimize performance and ROI.

See the TUNE destination documentation for more information on setting up and using this integration.

Releases: Amazon Audience Destination

Fri, 18 Oct 2024 00:00:00 +0000

Today we launched Amazon Audience as a Reverse ETL-compatible destination.

You can now connect this destination to a Reverse ETL source and allow the advertisers to reach specific customer segments based on Amazon’s first-party data.

See our Amazon Audience documentation to get started.

Releases: Expanded BigQuery Partitioning Settings

Fri, 04 Oct 2024 00:00:00 +0000

RudderStack now supports expanded partitioning options for the BigQuery warehouse destination.

Previously, RudderStack only loaded data into BigQuery using the ingestion_time column at a day-level granularity. These default settings limited many customers from running cost-efficient, fast queries for use cases that would benefit from partitioning on a different column at a different level of granularity.

With this release, you can now choose from multiple columns for partitioning and can set an hourly granularity level.

Partition column options:

Ingestion Time
Loaded At
Received At
Timestamp
Sent At
Original Timestamp

Granularity options:

Hour
Day

Updating your BigQuery configuration

Note that you cannot edit the partition settings for existing BigQuery destinations through the dashboard. RudderStack automatically sets their partitioning type to Ingestion Time partitioning with a day-level granularity.

To change your partition configuration, RudderStack recommends creating a new BigQuery destination and deprecating the old one.
To apply partition changes to an existing destination, you can contact the RudderStack support team.

See our BigQuery destination documentation for more information on using this feature.

Releases: Full Custom Consent Manager Support

Fri, 04 Oct 2024 00:00:00 +0000

Previously, RudderStack supported fully-integrated consent data flows for OneTrust and Ketch - two popular consent management tools.

With this release, you can integrate your custom consent management solution with RudderStack, giving you granular control over consent settings for each individual destination.

You can also use the Custom Consent Management feature to implement compliant pre-consent user tracking, with the options to store no cookies, store only the session tracking cookie, or only persist the anonymousId.

RudderStack also supports running multiple consent management solutions simultaneously, which is useful when consent management solutions differ across platforms.

Custom Consent Management is now available on all RudderStack plans. See our documentation for more information on using this feature.

Workflow overview

Before capturing user consent, make sure that:

You are running the latest version of the JavaScript SDK.

You have set the enabled key to true in the consentManagement API object. See the JavaScript SDK documentation for more information.

Update the code on your website to grab consent IDs from your custom consent manager.
Add the consent setting in the load object, or pass them to the SDK’s consent API using the consent method, as shown:

rudderanalytics.consent({
 consentManagement: {
 allowedConsentIds: ['performance', 'analytics'],
 deniedConsentIds: ['advertising']
 }
});

Using the consent method is helpful for tracking users who update consent settings and then go on to perform other actions on the same page and in the same session.

Specify the consent settings for each destination by adding the allowed consent ID values in the Consent settings section of the destination configuration. In the below example, the destination accepts data from users have consented to only performance or analytics tracking:

Releases: Global Advanced Property Rules across Tracking Plans

Fri, 04 Oct 2024 00:00:00 +0000

Our Tracking Plans feature evaluates advanced rules for properties, allowing you to flag data that does not align to your settings for enums, data formats, minimum/maximum values, and more.

Previously, you had to apply advanced rules individually to each event in each Tracking Plan — a time consuming and error-prone process.

With this release, advanced rules for properties are now set globally through the Data Catalog. That means the advanced rules are now applied to the property across all events and Tracking Plans, eliminating the need to update rules in multiple places.

Advanced rules for properties are now only managed globally through the Data Catalog. You can no longer set individual advanced rules for properties through Tracking Plans.

Note that:

If you had any existing advanced rules, you have been automatically migrated. Existing settings for advanced rules will not be affected, and any property-level advanced rules you created previously have automatically be propagated to the Data Catalog for global management across all Tracking Plans.
This release applies to all the customers using our UI-based Tracking Plans features.

Read our Data Catalog documentation for more information on this feature.

Screenshots

Releases: React Native Device Mode Integration for Facebook App Events

Tue, 01 Oct 2024 00:00:00 +0000

RudderStack now supports React Native device mode integration for Facebook App Events. You can configure your React Native app (Android (Java) or iOS (Obj-C)) to send events to Facebook App Events in the device mode.

See the Facebook App Events documentation for more information on setting up and using this integration.