Booking write published as closed beta on every page
The status list already carried the booking write as in verification. Page copy, meta descriptions, structured data and llms.txt now say the same: reads are live, the write is in closed beta.
Last entry 29 July 2026
Changelog: dated changes to what WhatsDo can do
Every entry carries the date the change was confirmed, not the date it was written up. Nothing is backfilled from memory and no release dates appear here.
Every capability claim re-checked against the live product
The production site, the onboarding flow and the AI readiness map were captured with a real browser on this date. Each statement published on this site was checked against that capture.
Backend status published as one list rather than per page
Square Appointments is supported. One other booking system is in verification. Every other platform in the public list is published without an agent path.
Public platform list returned no agent path for eight platforms
Eight platforms on the public list came back with no agent path. They stay published without an agent path until that answer changes.
Square Appointments confirmed as the priority backend
Calendars, services and availability are read from a connected Square account and served to external agents. It is the first backend, and the one the rest of this site is written against.
A second booking system recorded as in verification
The agreement is signed and verification is under way. It does not widen coverage for appointment-based businesses yet.
An early, limited path recorded as early and limited
One limited path exists and it holds at the level of a single agreement. It is not a general integration and it is not published as one.
MCP connector recorded as unfinished
The connector is still being completed. There is no public endpoint, no install path inside ChatGPT or Claude, and no published date for either.
Cancellation confirmed as unavailable on the agent path
An agent creates a booking and stops there. Cancellation and reschedule stay with the business and the client inside the provider system.
Focus narrowed to appointment-based services
Massage, spa and wellness studios are the segment the connected path is built around. Restaurants are the harder case and are deferred.
What goes into this log
An entry is added when a capability, a backend status or a published boundary changes. The date on it is the date the change was confirmed against the product.
- A backend moving between on request, in verification, early and supported.
- A capability opening or closing on the agent path.
- A published statement corrected after a check against the product.
- A source re-verified, with the date of that re-verification.
What this log will not carry
The absences are deliberate. A changelog that quietly drops the awkward entries is worth less than no changelog at all.
- Release dates. Status is published here; timelines are not.
- Merchant counts, booking counts, traffic or growth figures.
- Named customers without that merchant's written permission.
- Pricing, until commercial terms are approved in writing.
Current platform status lives on the integrations index, and the commercial position lives on pricing. This page updated 29 July 2026.
Questions about this log
How often is this page updated?+
When something changes, not on a schedule. Each entry carries the date the change was confirmed, so you can judge how current the page is without asking us.
Does an entry here mean a feature shipped?+
It means the statement was true on that date. Where a capability is unfinished the entry says so, and no release date is attached to it.
Why are there so few entries?+
The log starts on 2026-07-21, the day the product state was confirmed first-hand. Nothing earlier is reconstructed from memory.
Where do I see current backend coverage?+
The integrations page names the system we support. This log records the date a status changed and why.
Want to be told when a status changes rather than checking?