An API is a product with developers as its users. If integrating means a call with your team, a shared document, and two rounds of clarification, the interface isn't finished — regardless of what it returns.
Returning JSON is a day's work. Versioning, limits, and documentation are what make it something a partner will build a business on top of.
Whichever fits the consumer rather than the fashion — REST where caching and simplicity matter, GraphQL where clients need to shape their own queries.
OAuth, API keys, or signed tokens, with scopes granular enough that a partner integration can't read everything by accident.
A deprecation path that doesn't break a customer's integration on a Tuesday, and a clear answer to how long old versions live.
Generated from the spec so it can't drift, with real request and response examples — the difference between adoption and support tickets.
Rate limiting, retry semantics, and idempotency keys, so one badly-behaved client can't take the service down for everyone else.
Per-endpoint latency, error rates, and consumer-level usage — so you know an integration is failing before the customer emails.
Almost never in the response body. Almost always in what happens the second time someone calls it.
Often the API exists to serve something we're also building — a web application or a mobile backend.
Whether it's a public API, a partner integration, or the seam between your own services — send us the use case and we'll come back with a contract and a plan.