Providing SDK's and a good onboarding experience, and having a mechanism to commuicate changes to an api (sandbox envs) are great. Just think about what you love when you use another API and things that give you gripes, and solve the former, quash the latter.
within organisations where teams communicate is perfectly suited and all of our docs/examples support those cases, and suggest where failures occur, teams communicate in order to ascertain the way forward, contract testing is that early communicator to a change in intent of a service, be it intended (which promotes discussion) or unintended (which leads to remediation)