It didn't work exactly right of course because the docs weren't exactly right. Indeed. That approach also won't pick up changes to the remote API that break yo

It didn't work exactly right of course because the docs weren't exactly right. Indeed. That approach also won't pick up changes to the remote API that break your integration. An alternative strategy in this situation if you have access to some kind of remote sandbox - but maybe just a single stateful one that must be shared by your whole org - is to factor out your integration with that service into its own component/service and deploy controlled updates to that service less frequently and after running through a comprehensive integration test using the real sandbox. This probably involves a much lower release frequency but it also keeps your integration as stable as possible for your internal clients and tested against the real external service. If you're talking about remote services that do things you can't trivially revert - like physically transporting some object or causing money to change hands - then the strategy you described of trying to manage expectations while testing in production is probably not an acceptable alternative anyway.