Tenant-side proxy for the GL connection state stored onDocumentation Index
Fetch the complete documentation index at: https://docs.ntropii.com/llms.txt
Use this file to discover all available pages before exploring further.
tenant.config.gl in api-workspace. Reads the GL adapter’s connection state and projects it into a small response shape the ui-tenant header consumes for the GL status surface (logo + state dot + last-sync time).
GL config is currently tenant-scoped, so all entities under a tenant share the same GL connection. The header surface lives in the entity layout but reflects tenant-level state.
GL connection status
{ "connected": false } when the tenant has no GL configured — the header renders a placeholder.
Response — connected
| Field | Notes |
|---|---|
connected | true only when conn.status === "ACTIVE". |
provider | The registered GL adapter that owns this connection. |
service | Underlying provider service id (e.g. "xero", "quickbooks"). |
status | Raw connection status from api-workspace. |
lastSyncAt | Latest of metadata.updated_at / metadata.connected_at, or null. |
workspaceName | metadata.name (or metadata.service fallback). |
Start a GL connect session
sessionUrl (typically in a popup / new tab); the GL adapter handles the OAuth dance with the underlying provider (Xero / QuickBooks / …) and fires a webhook back to api-workspace on success which flips tenant.config.gl.options.status to ACTIVE. The UI polls GET /gl/status after the user completes the connect flow.
Body
| Field | Required | Notes |
|---|---|---|
serviceId | No | Pre-select a provider in the connect UI. Omit to let the user pick. |
Disconnect
204 No Content.
Cross-links
General ledgers (SDK)
ntro.capabilities.gl — the Python surface workflows use to post journals + bills against the connected GL.Tenant architecture
Where the GL connection sits in the cell topology.