Unofficial API

An unofficial API is an interface a product uses internally but does not publish or support — usually the endpoints its own web or mobile client calls, found by watching the network traffic that client generates. Teams reach for one when a vendor offers no public API at all, or offers one that omits the exact object they need, and it is a real and unremarkable part of how integrations actually get built. It is also the least durable dependency available, and for a structural reason: there is no contract, so there is nothing to version. The response shape can change in any release, with no notice, no changelog and no deprecation window, because from the provider's side nothing was broken. Authentication is typically the client's own session rather than a credential designed for machines, which means the integration is one login-flow change or one bot-detection improvement away from stopping. And the traffic can be throttled, blocked or classified as abuse, sometimes taking the account with it. The non-technical risk deserves to be weighed first, because it is the one that is not yours to absorb. Terms of service generally address automated access, and building a customer-facing feature on a route the provider has not sanctioned puts your customers' accounts at risk of suspension alongside your own. That is a decision for whoever owns the customer relationship and the contract, not something to settle quietly inside an implementation. If the answer is still yes, contain it. Put it behind a single interface so replacing it later touches one file rather than the product. Monitor its shape and not merely its availability, so a change reaches you as a failed check rather than as a support ticket. Never present it to customers as a supported integration, since the word implies a commitment you cannot make. And keep asking the provider for the real thing — the durable fix is an API they publish, and demand they can see is the argument for building one.