Greetings @hch_fiq , thanks for sharing the context—this behavior is almost always a permissions/entitlements mismatch between the service principal and the Genie space ACLs.
What’s happening
- The List Genie spaces endpoint (
GET /api/2.0/genie/spaces) only returns spaces the caller has access to; if the caller has no access, you’ll see an empty result (often rendered as {} by some clients).
-
To even see a space in the list, the caller needs at least CAN VIEW/CAN RUN on that space per Genie space ACLs.
-
For using the Conversation APIs, the caller also needs the Databricks SQL entitlement and warehouse access; if these are missing, subsequent calls will fail even after you can list spaces.
Fix it step-by-step
- In the Genie UI, open each space and use Share → add your service principal → grant CAN VIEW (or CAN EDIT). This is what allows the SP to see the space in listings.
-
Ensure the service principal has the Databricks SQL entitlement and at least CAN USE on the target SQL warehouse for that space (if you plan to call conversation/query endpoints).
-
Verify you are calling the workspace-scoped host (not the account-level host) and the correct endpoint: bash
curl -s -H "Authorization: Bearer $TOKEN" \
https://<workspace-host>/api/2.0/genie/spaces
-
Optionally, check audit logs for the aibiGenie.listSpaces event to confirm requests are reaching the workspace and how they’re being authorized.
Expected response shape
When the SP has access, the endpoint returns a spaces array with each space’s id, title, and description (and other fields depending on version).
Why your UI view differs from the API
You can see your two spaces in the UI because they’re shared with your user, but your service principal is a different identity without space-level permissions. The List Spaces API reflects the caller’s access, not the creator’s. The screenshot you attached matches this scenario (community post describing {} when listing with SP).
Hope this helps, Louis.
