Version 4.0.24.12
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}
Expand HTTP Path definition...
workspace_id
string
Id of the workspace
Response
200: Workspace
can
lock
object
Operations the current user is able to perform on this object
id
lock
string
The unique id of this user workspace. Predefined workspace ids include "production" and "dev"
Expand Project definition...
can
lock
object
Operations the current user is able to perform on this object
id
lock
string
Project Id
name
string
Project display name
uses_git
lock
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
lock
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
message
lock
string
Error details
documentation_url
lock
string
Documentation link
404: Not Found
message
lock
string
Error details
documentation_url
lock
string
Documentation link
429: Too Many Requests
message
lock
string
Error details
documentation_url
lock
string
Documentation link
Examples