Ask a developer what was hard about the last integration they shipped and they will not describe a request. They will describe the OAuth app review, the scope that was not the scope the docs promised, the refresh token that rotated and killed the sibling connection, the rate limit that was theirs rather than the customer's, and the afternoon spent finding which of three tenants a 403 was talking about.
Whose account is it?
The first decision, and the one most often made wrong, is whose credentials the integration uses. A platform that connects with its keys on the customer's behalf owns the rate limit, the audit trail and the liability. A platform that connects the customer's own account through consent owns none of those, and the customer can revoke it from their side. castomAPI does the second, for all 30 integrations, without exception — even where the first would have been easier to build.
What "connected" has to mean
A stored token is not a usable token. Consent can be partial (Google's granular scopes), a provider can collapse the scopes it granted into a different list (Shopify), and a refresh can rotate the credential for every sibling row at once (Cloudflare). "Connected" has to mean a real call was made and answered. Every platform on the catalogue was verified that way, against a real account, and the verification is written down per platform.
The bill is part of the interface
An HTTP 200 that carries ok: false is not a success, and billing it is a bug that costs the customer money silently. The platform classifies provider responses where they are consumed, so a failure is an unbilled error however the provider chose to spell it. The ledger then says what every token bought — by endpoint, by client, by day.
Interconnectivity, in the end, is one account that many systems trust and one ledger that says what happened. The code is the small part.