Current integration limitations
These limitations affect how to integrate safely. They describe the reviewed version; hosted availability can differ. Confirm required capabilities for your deployment and test them before relying on them.
Developer-token authentication
Scoped standalone tokens are supported on the operations listed in the API reference. Account, billing and token-management operations reject tokens. New tokens expire after 30 days by default, with a maximum of 365 days. See token permissions.
Older deployments may still reject standalone tokens before authentication. Verify a workspace-list request using a valid read_workspaces token after an upgrade. If it returns 401, check expiry/revocation, account status and the deployed version. Do not export dashboard cookies or combine unrelated credentials as a workaround.
Tokens apply across the owner's accessible workspaces; per-workspace token restrictions are not provided. Subscription changes follow the entitlement cache/invalidation window. Revocation blocks subsequent authentication but does not cancel operations already running.
Plans and account screens
Plan loading/activation in the reviewed dashboard has an availability gap. If it fails, contact support with the error and request ID; there is no documented alternative purchase endpoint in this reference. Account-security screens also depend on the supported hosted account flow and are not a separate public database API.
Invitations and collaboration
Invitation records and cancellation exist, but invitation acceptance and email delivery are not a complete API workflow. Direct membership creation exists for known developers. A pending invitation is not membership. Members can perform manual-backup deletion and restore, so membership is not universally read-only.
Database credentials and network controls
PostgreSQL user permission changes update metadata without applying grants. is_active metadata is not proof of engine access revocation. Replace/delete credentials and test actual engine access when reducing permissions.
Application-user URIs can be masked or use a destination different from public connection details. Construct application configuration from the real username/password and the public destination. URI-reserved password characters require correct encoding.
Source-IP restrictions are deployment-dependent for PostgreSQL/Redis; check allowlist_enforced. TLS is also deployment-specific. A saved allowlist or HTTPS dashboard does not establish native database protection.
Engine-specific features and recovery
Clone, pooling, extensions and query analytics are PostgreSQL features. Restore supports PostgreSQL, MongoDB archives and new Redis logical backups, with matching source/target engines. Historical whole-server Redis .rdb artifacts are not accepted. MongoDB/Redis logical exports are not a transactional snapshot across all collections/keys; stop application writes for a consistent backup and restore. No point-in-time recovery or automatic rollback is provided.
No public backup-download endpoint, point-in-time recovery guarantee or idempotency-key contract is documented. Empty analytics can reflect collection unavailability rather than no workload. Management audit logs do not cover every native database query.
These constraints should appear in an application’s design and runbook. An AI-generated integration must follow them rather than inferring support from a similarly named endpoint or another provider’s API.