Ask the API when your calendar is busy
Your connected Google Calendar now answers busy-time questions over the API, and widget failures report their own cause.
The API knows when you're booked
There's a new availability endpoint: GET /orgs/:orgRef/integrations/googlecalendar/availability. Give it a start and an end, and it returns the merged busy intervals across every calendar the connected Google account owns or can write to, along with the window it checked and how many calendars went into the answer.
Busy time is the only thing that leaves Google. The response carries no event titles, attendees, descriptions, or calendar names, so you can point a booking form or a scheduling automation at real availability without exposing what any of those meetings actually are.
Calendars you only subscribe to sit this one out. A client's shared holiday feed, or a colleague's calendar you follow read-only, won't make the organization look booked, and events Google already marks as free don't block.
The window is required. Both ends need a timezone offset, they have to be in order, and the range caps at 31 days. If a single calendar can't be reached the request fails instead of returning a partial picture, because a gap in the data would read as free time. It runs on the Google Calendar connection the organization already has, needs integrations:read on org API tokens, and lands in the audit log like every other integration call.
When the support widget can't reach the assistant
"Couldn't reach the assistant." used to be where the trail went cold. That turn now reports itself with a cause attached, so a content security policy blocking the connection, a browser that went offline, an expired widget session, rate limiting, and a stream that died halfway are five different problems instead of one. Before, they all looked the same from the outside.
When the widget breaks on a client's website, the cause is already recorded and nobody has to reproduce it first. The visitor's message text is never part of the report, only its length, and visitors don't get a profile created for them.
One thing this state doesn't cover: a problem with the assistant itself. Those come back as the normal fallback reply. If you're seeing "Couldn't reach the assistant.", the request never completed.
Under the hood
Boards created from the Content System template now start with a To do column between Backlog and In Progress, so planned work has somewhere to queue before anyone picks it up. Existing boards keep the columns they have. Nothing in this release needs a migration, a new secret, or a feature-flag change.