Creating a Kibana space separates dashboards, data views, alert rules, and other saved objects so one Elastic deployment can serve different teams, environments, or workstreams without mixing Kibana content.
A space is a Kibana saved-object boundary with its own URL identifier, avatar, optional feature visibility, and solution view. The identifier becomes part of non-default space URLs under /s/<space_id>/, and Kibana does not let you rename it after creation.
Creating spaces requires the Admin role, kibana_admin, or an equivalent custom privilege set. The Spaces API accepts API key or basic authentication, non-GET requests require the kbn-xsrf header, and feature visibility only changes Kibana navigation; it does not replace role-based access control for the data behind the space.
Related: How to delete a Kibana space
Related: How to export Kibana saved objects
Related: How to import Kibana saved objects
Tool: API Testing Tool
Steps to create a Kibana space with the Spaces API:
- Set the Kibana base URL and API key header.
$ export KIBANA_URL="https://kibana.example.net:5601" $ export KIBANA_AUTH_HEADER="Authorization: ApiKey BASE64_ENCODED_API_KEY"
Include any configured server.basePath in KIBANA_URL, such as https://kibana.example.net/kibana. Add --cacert /path/to/ca.crt to the curl requests when the deployment uses a private certificate authority. Use --user username:password instead of the header when basic authentication is the approved method.
- List the existing spaces and confirm the target id is unused.
$ curl --silent --show-error --fail \ --header "$KIBANA_AUTH_HEADER" \ "$KIBANA_URL/api/spaces/space" | jq '[.[] | {id: .id, name: .name, _reserved: ._reserved, solution: .solution}]' [ { "id": "default", "name": "Default", "_reserved": true, "solution": null } ]The id is the short URL identifier Kibana uses in /s/<space_id>/ and current API docs limit it to lowercase letters, numbers, underscores, and hyphens.
Reserved spaces such as default cannot be deleted and should not be reused as the target id for automation.
- Create the space.
$ curl --silent --show-error --fail \ --header "$KIBANA_AUTH_HEADER" \ --header 'kbn-xsrf: true' \ --header 'Content-Type: application/json' \ --request POST "$KIBANA_URL/api/spaces/space" \ --data '{ "id": "ops", "name": "Operations", "description": "Operations dashboards and alerts", "initials": "OP", "color": "#1EA593", "solution": "oblt", "disabledFeatures": [] }' | jq '{id: .id, name: .name, initials: .initials, solution: .solution, disabledFeatures: .disabledFeatures}' { "id": "ops", "name": "Operations", "initials": "OP", "solution": "oblt", "disabledFeatures": [] }Current Spaces API values for solution are es, oblt, security, and classic. The UI labels for those views are Search or Elasticsearch, Observability, Security, and Classic depending on the deployment navigation.
Disabling features in a space only hides them from the space navigation. It does not remove the user's underlying Kibana or Elasticsearch privileges.
- Fetch the new space by id.
$ curl --silent --show-error --fail \ --header "$KIBANA_AUTH_HEADER" \ "$KIBANA_URL/api/spaces/space/ops" | jq '{id: .id, name: .name, description: .description, solution: .solution}' { "id": "ops", "name": "Operations", "description": "Operations dashboards and alerts", "solution": "oblt" }The id cannot be renamed later, so this check is the best time to catch a typo before the space collects dashboards, rules, and other saved objects.
- Check a space-scoped API path.
$ curl --silent --show-error --fail \ --header "$KIBANA_AUTH_HEADER" \ "$KIBANA_URL/s/ops/api/saved_objects/_find?type=index-pattern&per_page=1" | jq '{total: .total, saved_objects: .saved_objects}' { "total": 0, "saved_objects": [] }The /s/ops/ path confirms later saved object, rule, and data view API calls will target the new space instead of the default space.
- Open Stack Management → Spaces and confirm Operations is listed with the expected URL identifier and solution view.
The Spaces management page is also reachable from the global search field. Use it to review avatar, description, feature visibility, and access assignments before handing the space to users.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.