ingestr v1.0.40 - Braze Source and KPI Window Fix

ingestr v1.0.40 was published on June 23, 2026 for bruin-data/ingestr, with the main operator visible change being a new Braze source. The release also adds Braze to the server connector catalog and fixes a KPI window boundary bug that could drop the start day from a metric range. It is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The release notes list a new Braze source. For data teams, the useful part is not the connector count. It is that Braze data can now enter the same ingestr path as other sources, instead of sitting behind a separate export job or a local script that no one wants to own.

The notes do not spell out endpoint coverage, auth shape, object mapping, or incremental cursor behavior. That limits what can be said from the release alone. Treat v1.0.40 as the point where Braze source support starts in the project, then validate the exact entities and sync mode against a small account before wiring it into a production warehouse path.

The important operational question is schema stability. Marketing systems often carry wide objects, nullable custom fields, and event records that shift as teams change their campaign model. A new source in an ELT tool is useful only when those changes fail in visible ways. This release note does not claim schema guarantees, so the practical move is to stage the connector, inspect the loaded table shapes, and compare row counts before scheduling regular jobs.

The changelog also says Braze was added to the server connector catalog. That is a separate operator concern from source code existing in the repository. A source that works locally but is absent from the server catalog can still be awkward in managed flows, central connector listings, or any control plane that depends on catalog metadata.

Putting Braze in the catalog makes the new source more discoverable to the server side of ingestr. It also reduces the chance that teams test a connector locally and then find a different surface area in the service path. For platform teams, that matters because connector enablement should be a repeatable change, not a manual exception.

There is still a normal validation burden. The release notes do not list new configuration keys, default schedules, or catalog metadata fields. If your deployment wraps ingestr with policy around allowed connectors, this is the item to check after upgrade. Confirm that Braze appears where operators expect it, and that any allow list or catalog sync process has the same view as the server.

The other concrete runtime fix is for a KPI window bug that dropped the start day. Boundary bugs in metric windows are easy to miss because the output can still look plausible. A seven day range can become a six day range with a clean looking total, and the failure may only show up when someone compares against source system reporting.

This matters most for backfills, finance adjacent dashboards, and campaign reporting where the first day in a requested window is not optional. If a previous ingestr run used KPI windows, the upgrade should include a spot check on ranges that start at a known active day. Compare the first day before and after v1.0.40 rather than only checking aggregate totals.

The fix also changes the risk profile for reruns. If the old behavior skipped the start day, a corrected rerun can add rows or change totals for the same nominal date range. That is expected for a boundary fix. Downstream models that assume old totals were final should be refreshed with that in mind.

One changelog item says Greptile review feedback was addressed on the Braze source. Read that as internal cleanup around the new source unless you maintain the connector code. It does not advertise a new user visible feature by itself.

The value is still real, just narrower. New source implementations tend to fail at edges such as pagination, retries, empty payloads, and type normalization. Review cleanup before or during release is the right place to catch those issues, but the release notes do not provide enough detail to treat it as a separate behavioral change.

That makes v1.0.40 a compact release. It adds one source, exposes that source through the catalog, and fixes one metric window boundary issue. There are no breaking changes or migration steps listed in the notes.