API Access
Three namespaces governing how systems and people authenticate into your company: api-keys for programmatic access, oauth-clients for registered applications, and sso for workforce identity. All 29 commands are listed by the CLI and none are runnable — every one is administered in the web app.
Why none of this is scriptable
These namespaces mint and rotate credentials, and grant the permissions those credentials carry. Autessa keeps that behind a browser session deliberately: a credential-minting endpoint reachable from a script is a credential-minting endpoint reachable from a stolen script.
The commands still appear in the help tree so discovery tells you the capability exists and where it lives, rather than leaving you unsure whether you mistyped:
autessa api-keys create
Create a new API key (done in the web app).
API keys
Programmatic API keys and their per-resource permissions — created, listed, updated, enabled/disabled and rotated, with permissions granted or revoked per resource and per type. Managed from account settings in the web app.
The namespace also carries the observability commands: monthly-stats for a key's usage and transaction-history for what it has actually done. Both are web-app views.
What matters when you are working from the terminal: an API key is the credential a client application uses against the Client API, scoped by the per-resource permissions you grant it. It is not what the CLI itself uses — autessa login mints a separate, short-lived, tenant-scoped session credential. See Install and sign in.
| Command | What it does |
|---|---|
| autessa api-keys add-permission-group | Web appAPI key permissions are managed from your account settings in the web app. |
| autessa api-keys add-resource-permission | Web appAPI key permissions are managed from your account settings in the web app. |
| autessa api-keys create | Web appAPI keys are created from your account settings in the web app. |
| autessa api-keys delete | Web appAPI keys are deleted from your account settings in the web app. |
| autessa api-keys delete-specific-permission | Web appAPI key permissions are managed from your account settings in the web app. |
| autessa api-keys disable | Web appAPI keys are disabled from your account settings in the web app. |
| autessa api-keys enable | Web appAPI keys are enabled from your account settings in the web app. |
| autessa api-keys get | Web appAPI key details are viewed from your account settings in the web app. |
| autessa api-keys grant-esignature-permission | Web appAPI key e-signature permissions are managed from your account settings in the web app. |
| autessa api-keys list | Web appAPI keys are listed from your account settings in the web app. |
| autessa api-keys monthly-stats | Web appAPI key usage stats are viewed from your account settings in the web app. |
| autessa api-keys refresh | Web appAPI keys are refreshed from your account settings in the web app. |
| autessa api-keys remove-all-permissions-for-type | Web appAPI key permissions are managed from your account settings in the web app. |
| autessa api-keys revoke-esignature-permission | Web appAPI key e-signature permissions are managed from your account settings in the web app. |
| autessa api-keys set-all-permissions-for-type | Web appAPI key permissions are managed from your account settings in the web app. |
| autessa api-keys transaction-history | Web appAPI key transaction history is viewed from your account settings in the web app. |
| autessa api-keys update | Web appAPI keys are updated from your account settings in the web app. |
OAuth clients
Registering OAuth client applications for your company, rotating their secrets, and revoking them. Five commands, all web-app-only.
Use these when an external application needs to act on behalf of your users, rather than with a fixed company-scoped key.
| Command | What it does |
|---|---|
| autessa oauth-clients create | Web appRegistering an OAuth application is done from your developer settings in the web app. |
| autessa oauth-clients delete | Web appDeleting an OAuth application is done from your developer settings in the web app. |
| autessa oauth-clients list | Web appYour OAuth applications are managed from your developer settings in the web app. |
| autessa oauth-clients rotate-secret | Web appRotating an OAuth application's client secret is done from your developer settings in the web app. |
| autessa oauth-clients update | Web appEditing an OAuth application is done from your developer settings in the web app. |
Single sign-on
Configuring the identity provider, managing verified email domains, setting the auto-join role, and toggling login enforcement.
Domain verification involves DNS records and a verification step, and enforcement changes how everyone in the company signs in — both are firmly human-confirmation territory.
| Command | What it does |
|---|---|
| autessa sso add-domain | Web appSSO email domains are claimed from your company's settings in the web app. |
| autessa sso get-config | Web appSingle sign-on is viewed and configured from your company's settings in the web app. |
| autessa sso remove-domain | Web appSSO email domains are removed from your company's settings in the web app. |
| autessa sso set-auto-join-role | Web appThe SSO auto-join role is set from your company's settings in the web app. |
| autessa sso set-enforcement | Web appSSO enforcement is toggled from your company's settings in the web app. |
| autessa sso set-provider | Web appThe SSO identity provider is chosen from your company's settings in the web app. |
| autessa sso verify-domain | Web appSSO domain verification is done from your company's settings in the web app. |
What to use for unattended automation
Since you cannot mint a credential from the CLI, the question this page usually raises is: how do I run automation with no human present?
Three answers, in the order worth trying:
- Put the work on the platform. Scheduled jobs, table triggers and inbound webhooks run server-side with no session to expire. Use the CLI to create them and let the platform run them. This is the durable answer for most cases.
- Use a poweruser key over HTTP. The Poweruser API covers the same operations the CLI exposes, and every CLI command has a poweruser equivalent. Keys are minted in the browser — see Poweruser keys.
- Use an API key from your application. For a client app acting against the Client API, with per-resource permissions scoped to exactly what it needs.
What not to do is wrap the autessa CLI in a cron job: autessa login mints a credential that expires in roughly eight hours with no silent refresh, so the job will start failing and the failure will look like a bug in your script.
Related
- Autessa CLI — what stays in the browser, and why
- Install and sign in — how the CLI's own credential works
- Poweruser API and Poweruser keys
- API keys and OAuth clients
- Company and account