[9dev]

> The company doesn't need to expose custom APIs on their data. If they implement a chat protocol, they must allow other clients to interface with it.

And how would that work without a way to talk to the company’s chat server, and document the way to do that, and commit to keeping that way of communicating reasonably stable? In other words, an API?

Which implies sort of a commitment to the way that chat protocol works, maybe even before the company knows how that looks like. Modern development methodology, that is, working in sprints and iterating towards a local maximum, doesn’t really go well with an API that’s required to work pretty much stable from day one. So when would the point in time be where you’d be required to open up to other clients?

[adam_arthur]

The comment you're replying to already answers this, so I'll refer you to that

[9dev]

not really. An API doesn’t necessarily have to be a HTTP interface. A data schema is also an API, if the documents are made available. The endpoints where that data is available is. And you still need heaps of documentation that someone needs to maintain. Not every system has simple to, from, and content fields.

I just doubt you really thought this through.