Understanding Users
The User Model
In Connectivity API, a user is:- An isolation boundary: Each user’s credentials and data are completely isolated from other users
- A credential container: Users own credentials for one or more third-party connectors
- A tenant identifier: Maps directly to end-users, organizations, or workspaces in your application
- Persistent: Once created, users persist until explicitly deleted
User-to-Application Mapping
The relationship between your application’s users and Connectivity API users should be 1:1: Best Practice: Create a Connectivity API user for each end-user in your system when they first need to connect an integration. Store the mapping between your user ID and the Connectivity APIuserId
in your database.
Creating Users
Basic User Creation
Create a user by providing a unique username and optional full name:userId
is the unique identifier you’ll use for all subsequent operations involving this user.
Username Requirements
- Must be unique across your account
- Recommended format: Use a combination of your internal user ID or email
- Examples:
user_12345
(based on your internal user ID)jane@example.com
(based on their email)jane_doe_acme_corp
(based on email + organization)org_456_user_789
(multi-tenant approach)
Request Parameters
Parameter | Type | Required | Description |
---|---|---|---|
username | string | Yes | Unique identifier for the user |
fullName | string | No | Human-readable name for the user |
User Lifecycle Management
Storing User Mappings
After creating a Connectivity API user, store the mapping in your database:- Retrieve the
userId
when executing operations - Track which users have connected integrations
- Clean up credentials when users delete their accounts
Retrieving User Information
Get details about a specific user:Listing All Users
Retrieve all users in your account:Updating Users
Update a user’s information:username
field cannot be changed after creation.
Deleting Users
Delete a user and all associated credentials:- Permanently deletes the user
- Revokes and deletes all credentials associated with the user
- Cannot be undone
User Context in Operations
Specifying User Context
Most operations require specifying which user’s context to operate within using thex-alloy-userid
header:
x-alloy-userid
header ensures:
- Operations execute with the correct user’s credentials
- Data isolation between users
- Proper authorization and access control
When User Context Is Required
Thex-alloy-userid
header is required for:
- Executing actions: All operations that interact with third-party platforms
- Managing credentials: Creating, updating, or listing a user’s credentials
- User-specific queries: Any operation that acts on behalf of a specific user
Error Handling
Common Errors
Duplicate Username
User Not Found
userId
is correct and the user hasn’t been deleted.
Missing User Context
x-alloy-userid
header in your request.
Best Practices
Username Conventions
- Be consistent: Use the same naming pattern across all users
- Include context: Add organization or tenant info for multi-tenant apps
- Avoid PII: Don’t use email addresses directly if avoidable
- Plan for scale: Use IDs that won’t conflict as your user base grows
Testing
Test User Creation
Create test users with a clear naming convention:Clean Up Test Users
Always clean up test users after testing:Next Steps
- Learn about Credentials and how to attach them to users
- Explore Authentication patterns
- Start Executing Actions on behalf of users