Rudderstack Release Notes
Last updated: Apr 2, 2026
Rudderstack Products
All Rudderstack Release Notes (62)
- Mar 31, 2026
- Date parsed from source:Mar 31, 2026
- First seen by Releasebot:Apr 2, 2026
1.72.1
Rudder Server fixes blacklisting UTS by transformation ID.
- Mar 31, 2026
- Date parsed from source:Mar 31, 2026
- First seen by Releasebot:Apr 1, 2026
Singular API v2 and SDID Support
Rudderstack adds Singular cloud mode support for API v2 and SDID, with automatic routing, zero-configuration backward compatibility, privacy flag support, and hybrid setup handling to keep attribution accurate as Singular rolls out new device IDs.
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:
- Singular Integration Setup Approaches
- Singular Cloud Mode Integration
- Singular Destination Setup Guide
Questions? We're here to help.
Join the RudderStack Slack community or email us for support
Original source Report a problem All of your release notes in one feed
Join Releasebot and get updates from Rudderstack and hundreds of other software products.
- Mar 30, 2026
- Date parsed from source:Mar 30, 2026
- First seen by Releasebot:Mar 31, 2026
1.72.0
Rudder Server releases migration optimizations for jobsdb with large datasets, plus bug fixes for language labels, mirroring round trip comparison, and sanity checks. It also includes partition migration stress test improvements and a sync to the main branch.
Features
Bug Fixes
- language label (#6809) (ac501c8)
- mirroring round trip comparison (#6813) (57a079b)
- sanity checks (#6817) (2969e3e)
Miscellaneous
- partition migration stress test and improvements (#6802) (419818a)
- sync release v1.71.0 to main branch (#6801) (6a6ee90)
- Mar 26, 2026
- Date parsed from source:Mar 26, 2026
- First seen by Releasebot:Mar 27, 2026
1.71.2
Rudder Server fixes mirroring round trip comparison bug in a new release.
- Mar 25, 2026
- Date parsed from source:Mar 25, 2026
- First seen by Releasebot:Mar 26, 2026
1.71.1
Rudder Server fixes a language label bug.
- Mar 23, 2026
- Date parsed from source:Mar 23, 2026
- First seen by Releasebot:Mar 23, 2026
1.71.0
Rudder Server fixes a router panic caused by invalid transformer headers and improves Snowpipe streaming error handling, while also refining jobsdb partition migration and updating core schema and transformer packages.
Bug Fixes
- router panics when invalid header format is returned by transformer (#6795) (910f421)
- snowpipe streaming remove authz error handling (#6777) (910f421)
- snowpipe streaming remove authz error handling (#6777) (5eaffb6)
Miscellaneous
- bump rudder-schemas to 0.11.0 (#6779) (7c7296b)
- bump rudder-transformer to v1.126.2 (#6774) (69692ac)
- force release 1.71.0 (#6791) (9cf21c7)
- jobsdb: partition migration improvements (#6772) (57b1c70)
- sync release v1.70.0 to main branch (#6775) (74125a6)
- ut mirror filtering (#6776) (fa4d1c4)
- Mar 23, 2026
- Date parsed from source:Mar 23, 2026
- First seen by Releasebot:Mar 23, 2026
1.70.2
Rudder Server fixes a router panic caused by invalid header formats returned by the transformer.
- Mar 19, 2026
- Date parsed from source:Mar 19, 2026
- First seen by Releasebot:Mar 19, 2026
1.70.1
Rudder Server releases a bug fix for snowpipe streaming authz error handling, addressing a permissions-related issue.
- Mar 17, 2026
- Date parsed from source:Mar 17, 2026
- First seen by Releasebot:Mar 18, 2026
Stream Events to Snowflake Iceberg Tables
RudderStack releases real-time Snowflake Iceberg support, streaming events to Parquet files in customers’ cloud storage via Snowpipe Streaming. Automatic Iceberg table creation, schema evolution, and compaction enable multi-engine querying with S3, GCS, or Azure.
Stream event data in real time to open Iceberg tables on your own cloud storage — powered by Snowpipe Streaming.
Available Plans
- Starter
- Growth
- Enterprise
3 minute read
Date: Mar 17, 2026
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
- Snowflake Streaming destination documentation
- How to Configure Snowflake Streaming to Iceberg Tables
- How to Migrate from Standard Snowflake Streaming to Iceberg
- Snowflake Streaming to Iceberg Tables Reference
- Snowflake Streaming to Iceberg Tables FAQ
Screenshots
Toggle on Create Iceberg Tables in the RudderStack dashboard
Questions? We're here to help.
Join the RudderStack Slack community or email us for support
Slack Join now →
Original source Report a problem
Email Reach out → - Mar 16, 2026
- Date parsed from source:Mar 16, 2026
- First seen by Releasebot:Mar 18, 2026
Custom Web Device Mode Integration
Rudderstack releases Custom Web Device Mode Integration, a new destination type that lets developers write their own JavaScript integrations to connect RudderStack’s SDK with any browser-based tool. It preserves consent, filtering, and transformations, with sandboxed errors and dashboard control.
Custom Web Device Mode Integration
Build your own client-side integrations with any browser-based tool using the RudderStack JavaScript SDK.
Available Plans
- Free
- Starter
- Growth
- Enterprise
4 minute read
Date: Mar 16, 2026RudderStack 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
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:
- Custom Web Device Mode Integration Overview
- How to Create Custom Web Device Mode Integrations
- Client-Side Event Filtering
- Consent Management
- Use Transformations in Device Mode
Screenshots
Custom Device Mode destination setup in the RudderStack dashboard
Add new destination in RudderStack dashboard
Destination ID shown in destination settings
Destination ID for Custom Device Mode destination
Questions? We're here to help.
Join the RudderStack Slack community or email us for support
Slack — Join now →
Original source Report a problem
Email — Reach out →