#Live API
Connected accounts are separate from Project Authentication. Project Authentication proves who an application user is; connected accounts hold permission to act on an external resource such as a calendar or messaging workspace.
/api/v1/memory/projects/:projectKey/connectors/api/v1/memory/projects/:projectKey/oauth/providers/api/v1/memory/projects/:projectKey/oauth/providers/:providerKey/api/v1/memory/projects/:projectKey/oauth/return-uris/api/v1/memory/projects/:projectKey/oauth/return-uris#Initial project-isolated mode
- 1Resolve an OEM end user
A project's Memory scope anchors the external connection.
- 2Start one-time authorization
HALO stores random state and PKCE context; the provider callback remains fixed per project, not per user.
- 3Store encrypted tokens
Provider access and refresh tokens remain in a server-side vault.
- 4Grant a Service capability
Runtime execution receives only the scopes approved for that Service, never the provider token itself.
/api/v1/memory/projects/:projectKey/scopes/:scopeId/oauth/start/api/v1/memory/oauth/callback/:providerKeyProvider callback authenticated by one-time hashed state.
/api/v1/memory/projects/:projectKey/oauth/sessions/:sessionId/api/v1/memory/projects/:projectKey/scopes/:scopeId/connections/api/v1/memory/projects/:projectKey/scopes/:scopeId/connections/:connectionId/refresh#Portable mode
A later opt-in portable identity can link verified OEM scopes and reuse an existing provider grant across those linked scopes. Email equality alone must never create this link. Missing upstream scopes still require incremental user consent.
#Token custody
| Actor | Receives provider token? |
|---|---|
| End-user hardware | No |
| Installed Service runtime | No |
| OEM application | No |
| HALO encrypted token vault | Yes, server-only |
#Legacy-service limits
A redirect hook cannot manufacture an upstream API permission. Services such as DoorDash that expose no suitable public OAuth/API contract remain partnership-required catalog entries.