Get Workspace

Version 4.0.24.20 (latest)

Get A Workspace

Returns information about a workspace such as the git status and selected branches of all projects available to the caller's user account.

A workspace defines which versions of project files will be used to evaluate expressions and operations that use model definitions - operations such as running queries or rendering dashboards. Each project has its own git repository, and each project in a workspace may be configured to reference particular branch or revision within their respective repositories.

There are two predefined workspaces available: "production" and "dev".

The production workspace is shared across all Looker users. Models in the production workspace are read-only. Changing files in production is accomplished by modifying files in a git branch and using Pull Requests to merge the changes from the dev branch into the production branch, and then telling Looker to sync with production.

The dev workspace is local to each Looker user. Changes made to project/model files in the dev workspace only affect that user, and only when the dev workspace is selected as the active workspace for the API session. (See set_session_workspace()).

The dev workspace is NOT unique to an API session. Two applications accessing the Looker API using the same user account will see the same files in the dev workspace. To avoid collisions between API clients it's best to have each client login with API credentials for a different user account.

Changes made to files in a dev workspace are persistent across API sessions. It's a good idea to commit any changes you've made to the git repository, but not strictly required. Your modified files reside in a special user-specific directory on the Looker server and will still be there when you login in again later and use update_session(workspace_id: "dev") to select the dev workspace for the new API session.

Request

GET /workspaces/{workspace_id}
Datatype
Description
Request
HTTP Request
path
HTTP Path
Expand HTTP Path definition...
workspace_id
string
Id of the workspace

Response

200: Workspace

Datatype
Description
(object)
can
object
Operations the current user is able to perform on this object
id
string
The unique id of this user workspace. Predefined workspace ids include "production" and "dev"
projects
Expand Project definition...
can
object
Operations the current user is able to perform on this object
id
string
Project Id
name
string
Project display name
uses_git
boolean
If true the project is configured with a git repository
git_remote_url
string
Git remote repository url
git_username
string
Git username for HTTPS authentication. (For production only, if using user attributes.)
git_password
string
(Write-Only) Git password for HTTPS authentication. (For production only, if using user attributes.)
git_production_branch_name
string
Git production branch name. Defaults to master. Supported only in Looker 21.0 and higher.
use_git_cookie_auth
boolean
If true, the project uses a git cookie for authentication.
git_username_user_attribute
string
User attribute name for username in per-user HTTPS authentication.
git_password_user_attribute
string
User attribute name for password in per-user HTTPS authentication.
git_service_name
string
Name of the git service provider
git_application_server_http_port
integer
Port that HTTP(S) application server is running on (for PRs, file browsing, etc.)
git_application_server_http_scheme
string
Scheme that is running on application server (for PRs, file browsing, etc.)
deploy_secret
string
(Write-Only) Optional secret token with which to authenticate requests to the webhook deploy endpoint. If not set, endpoint is unauthenticated.
unset_deploy_secret
boolean
(Write-Only) When true, unsets the deploy secret to allow unauthenticated access to the webhook deploy endpoint.
pull_request_mode
string
The git pull request policy for this project. Valid values are: "off", "links", "recommended", "required".
validation_required
boolean
Validation policy: If true, the project must pass validation checks before project changes can be committed to the git repository
git_release_mgmt_enabled
boolean
If true, advanced git release management is enabled for this project
allow_warnings
boolean
Validation policy: If true, the project can be committed with warnings when `validation_required` is true. (`allow_warnings` does nothing if `validation_required` is false).
is_example
boolean
If true the project is an example project and cannot be modified
dependency_status
string
Status of dependencies in your manifest & lockfile

400: Bad Request

Datatype
Description
(object)
message
string
Error details
documentation_url
string
Documentation link

404: Not Found

Datatype
Description
(object)
message
string
Error details
documentation_url
string
Documentation link

429: Too Many Requests

Datatype
Description
(object)
message
string
Error details
documentation_url
string
Documentation link

Examples