Each customer gets their own organization, not a row in your users table.

The first partner integration is a shared API key in a password manager. By the tenth, you are building a customer portal: invitations, a list of who may call what, a way for the partner to add a second engineer, and a way to take a key away without breaking everyone else who shares it.

None of that is your product, and all of it has to be right, because it decides who can reach your API.

The organization is the tenant. You are one, and every client that calls your API is another, with its own members, groups, applications and credentials. A client's engineers sign in to their own organization; they never get an account inside yours.

Group endpoints into API packages, then invite a client organization by code or email. It accepts from its own organization, and a package you assigned on the invite is granted once it does. Until then the grant waits as pending, so nothing is reachable before the client has agreed to the connection.

Grants are per organization and checked on every call, so revoking one package cuts off that client and only that client.

Some customers will never create an account. For them you create a managed client organization through the management API and set it up from code: environments, applications and credentials. When someone at that customer is ready, they claim it; the first person to accept becomes its owner, and its credentials are rotated: the secrets you handled stop working when the rotation's grace window ends, or at once if the new owner chooses.

Everything above is also in the management API and the client libraries, so onboarding a customer can be a step in your own signup flow rather than a ticket for your team.