The second most common request in our inbox, after "is there a mobile app," is "do you have an API." We don't — not a public, documented, versioned one that anyone can build against. I own the conversation engine at AIVA, and I want to explain why, because "we haven't gotten to it" is true but incomplete, and it undersells how deliberate the decision actually is.
What we do have
AIVA already talks to other systems constantly — it reads and writes to booking calendars, pulls customer context, and connects into the CRMs, helpdesks, commerce platforms, and messaging tools our customers already run their business on. Those integrations exist and work well, and for the large majority of what a business actually needs AIVA to connect to, one of them already covers it. On top of that, webhooks let AIVA notify an external system — your own database, an internal Slack channel, a tool that isn't on the standard list — the moment something happens, without anyone waiting on us to build a bespoke connector for a workflow only one customer has.
What doesn't exist is the general-purpose, stable, publicly documented version of that — the kind where any developer can read a doc page and build something against AIVA without ever talking to us first. Webhooks are one-directional and event-shaped: AIVA tells you when something happened. A public API would be the other, much larger thing — letting an external developer reach in and query, filter, and act on AIVA's data structures directly, on their own schedule, however they want to shape the request. That's a meaningfully different commitment than "we can connect to your system." It's "we promise this interface will keep working, in this exact shape, indefinitely, for people we've never met and can't call when something breaks on their end."
Why that promise is harder than it sounds
A public API is a contract. The moment we publish one, we've committed to versioning it, maintaining backward compatibility, documenting every field, and supporting developers who hit edge cases at 11pm on a Saturday — for integrations we can't see and didn't design. Internally, we can change how conversation data is structured whenever we find a better shape, because we control every caller and can update them all at once. The instant that's public, every change becomes a potential breaking change for someone else's production system, discovered not by us but by a developer whose integration silently stopped working.
We've actually felt a smaller version of this cost already, and it's worth being specific about it rather than leaving the argument abstract. Our webhook payloads carry a signature header so a receiving endpoint can verify a request actually came from us. Earlier this year we needed to rename that header — a change that would be trivial in a purely internal system — and because webhooks are a small, semi-public surface that customers build against, we couldn't just ship the rename. We ran a 90-day window where both the old and new header worked, specifically so nobody's integration broke without warning. That's the versioning discipline a single header rename required, on a surface far narrower than a full API. A public API multiplies that same discipline across every field, every endpoint, every response shape, indefinitely, for as long as the API exists — not a one-time cost, a permanent one.
We've watched other companies our size ship a public API early, then spend a disproportionate share of engineering time maintaining compatibility with integrations built by a handful of external developers — time that came directly out of the product every other customer was using. We're not willing to make that trade yet.
We're also still changing our own data model more often than a stable public API would tolerate. We've reshaped how conversations, bookings, and escalations are represented internally more than once in the last year, each time because it made the product better — a cleaner way to represent a multi-step booking, a better shape for how an escalation carries context to a human agent. A public API would have meant either freezing that evolution or breaking external integrations every time we improved something. Neither is acceptable at this stage, and choosing between them is exactly the choice we'd be forcing on ourselves the day after we shipped one.
The closest we've come to building one anyway
We've had at least one enterprise conversation serious enough that we scoped what a narrow, single-partner integration contract would actually look like — effectively a private, single-tenant version of a public API, built and versioned for exactly one counterparty instead of an unknown and unbounded set of them. It's the closest we've come to the real thing, and it's genuinely useful groundwork: it forced us to think through versioning and documentation discipline in a contained setting, with one relationship to manage instead of hundreds. It also confirmed, from the inside, how much harder the general version is — a single-partner contract lets you pick up the phone when something's ambiguous. A public API doesn't, by definition, and that gap is exactly the part we're not ready to promise yet.
The security question underneath it
There's a second reason that's less about maintenance burden and more about exposure. A public API multiplies the ways someone can reach into a system that holds real customer conversations — booking details, phone numbers, sometimes sensitive context depending on the business. Every new endpoint is a new thing to secure, rate-limit, and audit, and every new authentication path is a new way for a credential to leak or be misused. That's the same reasoning that shows up across how we approach security generally: fewer doors, each one watched carefully, rather than many doors opened quickly. We'd rather add that surface area deliberately, once, done properly, than incrementally under pressure from whoever asks loudest this quarter.
What would change this
This isn't never. It's "not before the pieces that make it safe to promise are actually in place." That means our internal data model needs to be stable enough that we're not reshaping it every quarter, and it means having engineering capacity specifically dedicated to API support — not borrowed from whoever's free that week, the way a rushed version would inevitably be staffed. A public API sits on the same list as a native mobile app — both things we could technically build sooner, and both things we don't think would be built well if we rushed them just to close a feature-comparison gap.
When both of those conditions are true, we'll build it properly: versioned from day one, documented before the first external developer touches it, with the same care we've put into voice latency. That version would also need the parts that don't show up in a demo but matter enormously to a real developer — a staging environment separate from production, sane rate limits that don't punish a well-behaved integration, client libraries in more than one language, and a support channel that isn't just whoever answers email first. Shipping the endpoints without that surrounding infrastructure would be shipping the appearance of a public API rather than one anybody could safely build a business on, and we'd rather wait than hand developers that appearance.
Until then, if you need AIVA to talk to a specific system, tell us which one. We're still doing that integration work by hand, on purpose, because it's more honest than a promise we're not ready to keep.