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
$ 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.
$ 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.
$ 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.
$ 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.
$ 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.
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.