Authentication
Each driver declares which auth methods it supports. Credentials are stored encrypted insv_accounts and resolved at runtime through the driver’s key builder.
Auth types per driver
Run
php artisan sanvex:list to see auth metadata for installed drivers.
Core SANVEX_* settings: Configuration.
Token resolution
At runtime,KeyBuilder::getToken() resolves credentials in this order:
api_keybot_tokenaccess_token
bot_token first).
API key / token setup (CLI)
Thesanvex:setup command stores credentials for a driver:
--owner-type and --owner-id must be provided together, or neither.
Optional --backfill runs sanvex:backfill after setup (placeholder — no driver backfill logic implemented yet).
OAuth setup
Unified flow: OAuth concept (OAuthRoutes, OAuthManager, oauthConfig()).
Notion: set
NOTION_* env vars, then visit /sanvex/notion/login. Active when NOTION_CLIENT_ID is set or NOTION_AUTH_TYPE=oauth_2.
Gmail: set GMAIL_* env vars, then visit /sanvex/gmail/login. Active when GMAIL_CLIENT_ID is set.
Both use global owner scope by default. See Integration guide.
GitHub, Linear, Slack: no packaged login/callback routes yet. Follow each driver’s configuration page for provider registration and env vars, then store tokens via the driver key builder or oauth()->storeTokens().
Credential keys stored
Driver-specific key builders may store additional keys (e.g. GitHub webhook secret, OAuth refresh/expiry metadata).
Owner scoping
Credentials are scoped by(owner_type, owner_id):
- Global —
owner_type=global,owner_id=default(CLI default) - Tenant — pass
--owner-typeand--owner-id, or useSanvexManager::for($owner)at runtime
Security notes
- Use
SANVEX_KEK(fromsanvex:keygen) in production instead of relying onAPP_KEY - MCP
RunScriptToolis disabled by default and usesevalwhen enabled — only enable in trusted environments (SANVEX_MCP_ALLOW_RUN_SCRIPT=true)
