Automate database management
The management API is intended for provisioning, lifecycle operations, credentials, backups and observability. Use native database drivers for normal application queries.
Use an expiring Lordbase developer token with the required scopes. Account access, billing and token issuance stay in the signed-in dashboard.
Establish access first
- Sign in to Lordbase and activate the required plan.
- Create a workspace and verify your role.
- Create a short-lived developer token in Settings with
read_workspaces,read_databasesandwrite_databasesfor the provisioning flow below. Store it in your automation system’s server-side secret store. - Confirm protected access with the workspace-list request. Do not proceed with mutating automation until that check works.
Scopes are enforced in addition to workspace roles. A read_databases token cannot fetch administrative credentials or execute commands. Backup automation needs backup scopes; restoring also requires write_databases. Token authentication uses the account ID recorded at issuance, never a caller-supplied account ID.
Provisioning sequence
| Step | Operation | What to retain/check |
|---|---|---|
| Discover workspace | GET /developer/workspaces/ | ID from owned_workspaces or member_workspaces |
| Create database | POST /developer/workspaces/{workspace_id}/databases/ | id, engine, status; owner/admin and quota required |
| Read connection settings | GET /developer/databases/{database_id}/connection/ | Public host/port, database, TLS, Redis prefix; response is secret |
| Create application credentials | POST /developer/databases/{database_id}/users/ | Returned username and password; combine with public connection settings |
| Connect application | Native driver | A minimal successful operation from your runtime |
Paths in the table are relative to https://api.lordbase.com/e/v1. The database reference and user reference contain payloads and responses.
Minimal PostgreSQL provisioning body:
{"display_name":"Application development","engine":"postgres"}
Minimal writable application-user body:
{"username":"app","permissions":"write"}
Build recoverable automation
No idempotency-key contract is documented. Save returned resource IDs and check current state before repeating a timed-out create, clone or restore. A timeout can happen after the operation has changed state.
Handle 204 without attempting JSON parsing. Use the documented envelope for each list; workspaces, users and standard paginated resources differ. Store secrets outside logs and artifacts. Poll backup detail after job creation; 201 is not backup completion.
Before destructive operations, verify the exact database/backup ID and intended target. Restore examples must use an explicit disposable PostgreSQL target; omitting the target restores over the source database.
For AI-assisted integrations, provide the engine, desired operation, workspace/database IDs and non-secret configuration. Supply secrets through the runtime environment. Require the integration to use the documented request fields and check errors; it must not invent endpoints, token workarounds or unsupported engine features.