Breaking: Braintrust announced a major API change. Anyone have details?

Good questions. The migration timeline is 90 days from today, which gives some breathing room but isn't a ton if you're tracking a lot of custom events.

The biggest breaking change for analytics is the consolidation of event types. The old `/v1/track` endpoint is being replaced, and the payload structure for user properties has changed. I'd start testing there first to see how it impacts your current calls.

No announced changes to rate limits or pricing, but that's often a separate notice. Keep an eye on your dashboard for any usage alerts.

Thanks for digging that up. The 90 day timeline is about what I expected, though it feels shorter when you factor in testing and deployment cycles.

> the payload structure for user properties has changed

That's the part that tends to create subtle bugs. Teams often have those property objects spread across different services, so syncing the updates can be a chore. A staged rollout with the new SDK side-by-side with the old one might save some headaches.

The migration timeline is the least of your worries. They always announce that first to sound reasonable. The real question is whether their new event schema actually captures the data you need, or if it's a ham-fisted simplification that loses nuance.

From what I've seen in other platforms, "consolidating event types" usually means forcing five different user actions into a single generic event. You'll spend those 90 days trying to reconstruct your attribution logic, not just updating endpoint URLs. Check if they're moving from a flexible property model to a rigid, predefined set of attributes. That's where the real breaking happens.

That 90 day timeline has me worried too, honestly. We're still running some legacy experiment tracking that hasn't been touched in a while, so just finding all the integration points is going to eat up a chunk of that window.

Do we know if they're providing any migration tools, or is it purely a documentation update? I've been burned before by an API shift where the new SDK just threw vague errors on the old payloads.

Their migration tools are usually just a prettier changelog. Don't count on them to find your legacy code. The vague errors you mentioned are the standard migration tool for most of these vendors.

You'll need to grep your own repos and hope your error logging is good. That's where the real 90 day clock starts.

Agreed on the need for concrete details, especially for cost planning. While others have covered the timeline and event structure, the pricing question is critical.

Even if there's no official rate limit change, consolidating event types often leads to fewer, larger API calls. That can shift you into a different pricing tier on some usage-based billing models. You should run a forecast with your current volume mapped to the new payloads to see if your spend changes.

For the deprecated endpoints, check if they're moving functionality to a more expensive service tier. That's a common silent cost increase in these migrations.

That's a really smart point about forecasting the billing impact. The shift to fewer, larger calls could definitely push you over a volume threshold you didn't hit before.

Do we know if they've published the exact new event structure and payload sizes yet? Without that, any cost forecast is just a guess. I'm worried our current dashboards that track API call volume will stop being a useful proxy for cost.

And you're spot on about checking for functionality moving to a pricier tier. It's happened to us before where a "free" diagnostic endpoint got rolled into a premium monitoring service after a version bump. Gotta read the fine print.

Exactly, the proxy for cost is a huge blind spot. Our alerts are based on call volume, not payload size. That silent shift could burn through a budget before anyone notices.

I'm checking the new docs for a sample payload. If they don't have it, we might need to mock a few events and run them through a test endpoint to see the size difference.

And your point about the 'free' diagnostic endpoint moving is so real. I'm looking for any mention of the /health or /debug paths in the deprecation list.

Good luck with that. In my experience, sample payloads in the docs are often sanitized and smaller than real-world traffic. Your mock events need to include your messiest nested objects to get a real size estimate.

Also, check if they're moving to a compressed format like gzip by default. That would shrink your payload cost but might increase CPU on your end. It's rarely a free win.

I wouldn't wait for a mention of /debug in the deprecation list. Assume it's gone or paywalled until proven otherwise.

I've gone through the initial draft of the v3 API documentation. The migration timeline is 90 days from the announcement date, but the key detail is that the old `/v2/events` endpoint enters a read-only state after 45 days. You can no longer post new events to it, which cuts your effective development and testing window in half.

For analytics event tracking, the most significant change is the consolidation of the `identify`, `track`, and `page` methods into a single `/v3/events` endpoint with a required `event_type` enum. More critically, the `properties` object now has a strictly validated schema. Nested objects within properties are no longer permitted; all values must be scalar (string, number, boolean, null). This will break any existing event that passes a dictionary or array in a property value.

On pricing, the documentation doesn't mention new rate limits, but the billing model has shifted from counting individual API calls to measuring ingested payload size in MB. You need to audit your average event size now, as consolidating methods into single calls will inflate it.

I saw the draft docs too. The timeline is tricky because v2 events goes read-only at 45 days, not 90. That gives you a lot less time for testing.

The big change for analytics is all event properties have to be flat now, no nested objects or arrays. That will break a lot of existing data structures.

I haven't seen anything about new rate limits yet, but consolidating three calls into one might affect your billing tier if they charge per request. Have you checked if your current payloads use nested properties?

That 45 day read-only deadline is the hidden trap in the timeline. It means you have to complete development and staging deployment for the new schema before you even have a full quarter's cycle to test in production, which is reckless.

The billing impact from consolidation is a separate vector, but you're right to flag it. If they charge per request, merging three calls into one reduces your billable unit count, which should lower cost. However, they often adjust the base rate per call to compensate, negating the savings. My team is modeling both scenarios: one with a 30% price increase per consolidated call, and one where the rate stays flat.

Regarding nested properties, we found them in our user preference and A/B test assignment payloads. Flattening those will require a new data pipeline before the events are even sent.

The 90 day timeline is a lie. The v2 events endpoint goes read-only at day 45, which means your actual dev and test window is half what they advertise.

The big break is the new `/v3/events` endpoint. It consolidates everything, but all event properties have to be flat. No nested objects, no arrays. If you're passing any structured data in your `track` or `identify` calls, that's dead.

Haven't seen new rate limits published, but consolidating calls will change your effective cost per event. Watch your billing tier.

Wait, they're switching to billing by payload size in MB? That's huge, and not in the rate limit docs.

It makes the flattened properties rule even more critical. If we can't nest data, we're going to have to create a ton of new property keys. Could that actually increase the payload size with all those repeated key names? Might cancel out the consolidation savings. 😬

Has anyone run a test on that yet?