Skip to main content
An auth provider is your account’s own credentials for one authentication method of one application - typically your own OAuth app registered with the vendor. You fill it in once, and every connection signed in through it uses those credentials. Auth providers are for OAuth2 methods only, and only for methods whose connector allows them. Without a provider, a connection signs in through the connector’s own OAuth client. With one, you control the OAuth app the vendor shows your users.

​
What a provider holds

A provider is a name plus values for the method’s “Set on provider” fields - the fields the connector author marked to be filled on the provider rather than on each connection. Each value is addressed by its connection slot:
  • Key1 through Key10 - connector-specific fields (for an OAuth app, usually the client id and client secret)
  • ApiUser / ApiPassword - API credentials
  • BaseUrl - a vendor or custom endpoint URL
Which slots a method takes, and which are secret, varies by connector. engini connections auth-providers sources lists them. There is no clientId / clientSecret property: the API rejects both with 400 INVALID_AUTH_PROVIDER. Where a connector lets you bring your own OAuth client, it marks those fields “Set on provider” and you send them as slot values. A secret slot is write-only: you send it once, it is stored encrypted, and a response carries hasValue: true with a null value - never the secret.

​
Setting one up

  1. Find the application, method and slots - engini connections auth-providers sources.
  2. Get the callback URL - engini connections auth-providers redirect-uri --app <app> - and register it in your OAuth app with the vendor.
  3. Create the provider with the credentials the vendor gave you.
The slot names above are an example - read yours from sources. All commands and options are in the CLI reference, and the output shapes in the machine contract.

​
Signing in through a provider

Pass --provider - a provider name, a numeric id, or none for the connector’s own OAuth client:
The provider fixes the authentication method, so --auth defaults to the provider’s own. The fields it already holds are not prompted for again. --provider is also accepted by engini connections sign-in-url and engini connections create. Both a name and an id are looked up among the providers engini connections auth-providers usable shows you, so a provider that is disabled or not available to you is not found (exit 4).

​
Where the provider is pinned in the API

There are two places, and they are not the same call:
  1. OAuth2 sign-in - authProviderId in the body of POST /v1/connections/get-sign-in-url. The server keeps it with the sign-in state, so the connection that follows is created through the same provider.
  2. OAuth2 client-credentials methods (no sign-in) - authProviderId as a query parameter on POST /v1/connections. The server ignores it for every other method.
In both, authProviderId has three states: omitted uses the account’s default provider (when its method matches and you may use it), 0 uses the connector’s own OAuth client, and an id uses that provider. Test for “omitted” explicitly - a falsy check swallows 0.

​
Access control

  • list, get and redirect-uri need permission to manage auth providers.
  • sources needs permission to create auth providers.
  • usable, and --provider <name|id> need only permission to use auth providers (any member when RBAC is off). usable returns ids, names and methods - never field values.

​
From the SDKs

The Python SDK exposes client.auth_providers (list, get, create, update, delete, redirect_uri, sources, usable), and the TypeScript SDK client.authProviders (the same, redirectUri in camelCase).
On update, a slot you leave out keeps its stored value and "" clears it. Deleting a provider that connections are signed in through is refused with 409 AUTH_PROVIDER_IN_USE.