Connect provider with the tenant's client credentials
Proves the tenant’s stored client_id/client_secret can mint a provider access token, persists it, verifies that the credential resolves to exactly one usable provider account, and resolves the provider company_id.
Send an EMPTY JSON OBJECT as the body: . The body carries nothing — the provider implements the client_credentials grant only, so there is no authorization code to exchange and no redirect to honour — but it is still required, so omitting it entirely answers 400, and so does null. Any unknown field is rejected rather than ignored.
Account verification is a fresh read of the provider’s account list, never a cached one, and it does not populate any runtime cache: it observes. It answers 422 when the provider side is misconfigured in a way an operator can fix — no default account, more than one, or a default that is locked or not active — and 502 when the provider breaks its own contract or the account does not belong to the credential that would pay for it.
account_verified reports whether the check actually ran. It is false, with the connection still established, on a deployment where the provider’s Common Methods base URL is not configured; provider_account_id is then absent. A false here means nothing proved that the credential resolves to one usable account, and at the provider a wrong account does not error — it settles.
Authorizations
JWT bearer token issued by the identity provider.
Headers
Tenant organization ID. Accepted but ignored: the tenant is determined by the credentials you authenticate with, so sending this header, or sending a different value in it, changes nothing.
Client-supplied idempotency key. Required in practice even though the schema marks it optional: a request that omits this header is refused with 400 PBP-0012.
Body
The body is of type object.

