Accounts
An account is your compliance workspace. It carries the configuration that governs how applications are scored and verified, and it owns the users who can access the API.
Account configuration
Section titled “Account configuration”GET /account returns your account, including its risk scoring strategy and identity-verification provider. PATCH /account updates the account name and riskScoreStrategy.
| Field | Values |
|---|---|
riskScoreStrategy |
CUMULATIVE or MAXIMUM (governs how risk scores map to bands; see the Risk Scoring guide) |
idvProvider |
ONFIDO or TRULIOO (the identity-verification provider) |
Risk factor configuration lives under GET/PATCH /account/{accountId}/risk-settings.
A user can belong to more than one account; the account/users endpoints manage membership of this account. Listing excludes internal Steward staff.
| Operation | Endpoint | Notes |
|---|---|---|
| List | GET /account/users |
Members of this account |
| Create | POST /account/users |
New user defaults to the read-only role if none is given |
| Update | PATCH /account/users/{id} |
Name, title, roles. Changing a user’s email returns 403 |
| Remove | DELETE /account/users/{id} |
Deactivates the user (it is not a hard delete). For a PENDING user this also revokes their invitation |
A user’s status is one of PENDING, ACTIVE, or INACTIVE. The role available through the public API is read-only.
Inviting an email that already belongs to a user returns 409 with code EMAIL_ALREADY_EXISTS. When that user is already a member of your account, the body also carries user: { id, status }.
Example
Section titled “Example”# Fetch your accountcurl https://api.getsteward.ai/api/v1/account \ -H "Authorization: Bearer stw_live_your_api_key_here"
# Add a read-only usercurl -X POST https://api.getsteward.ai/api/v1/account/users \ -H "Authorization: Bearer stw_live_your_api_key_here" \ -H "Content-Type: application/json" \ -d '{ "email": "analyst@example.com", "firstName": "Ada", "lastName": "Lovelace", "roles": ["read-only"] }'