Hi @simonhamp, founder/CEO of Akita here. :) It sounds like you have good internal discipline about what could potentially break your API and that's great. The

Hi @simonhamp, founder/CEO of Akita here. :) It sounds like you have good internal discipline about what could potentially break your API and that's great. The point you bring up, that surely the code can't be the only documentation of an implicit contract, is exactly what we've been observing, in that the code is often the only documentation. The example we gave (service/service dependency) was an extreme case of this, though we have seen this. More subtle examples would be changing an error code, or changing from one specific type of string to another (for instance, two datetime formats). Propagating these changes to dependencies, especially in larger systems, can cause some real headaches. Would love to talk more to understand how you've gotten around some of these with good process! Shopify has this great blog post about their solution for change management in their external APIs that also makes the point that change impact analysis is not easy: https://engineering.shopify.com/blogs/engineering/shopify-manages-api-versioning-breaking-changes https://engineering.shopify.com/blogs/engineering/shopify-ma... Also, quick point: we don't proxy for precisely the reason you brought up. Akita works without sending any user data back to our servers, just the metadata.