Getting started with Looker

Best Practices

Documentation

Community

Training

Certification

Articles in this section

See more

Workspace : Manage Workspaces

Avatar
Looker Support
  • Updated
Follow

update

You can also view Looker’s interactive API documentation on the Looker Developer Portal or by using the API Explorer extension.

Get All Workspaces beta

GET/api/4.0/workspaces
all_workspaces()

Implementation Notes

Get All Workspaces.

Returns all workspaces available to the calling user.

Response Class

  array

Parameters

  None

Response Messages

HTTP Status Code Reason Response Model
400 Bad Request
Error {
message (string, read-only, required): Error details,
documentation_url (string, read-only, required): Documentation link
}
404 Not Found
Error {
message (string, read-only, required): Error details,
documentation_url (string, read-only, required): Documentation link
}

Get Workspace beta

GET/api/4.0/workspaces/{workspace_id}
workspace(workspace_id)

Implementation Notes

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

Response Class

Workspace {
can (object, read-only): Operations the current user is able to perform on this object,
id (string, read-only): The unique id of this user workspace. Predefined workspace ids include "production" and "dev",
projects (Array[Project], read-only): The local state of each project in the workspace
}
Project {
can (object, read-only): Operations the current user is able to perform on this object,
id (string, read-only): Project Id,
name (string): Project display name,
uses_git (boolean, read-only): 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 (long): 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, read-only): If true the project is an example project and cannot be modified,
dependency_status (string): Status of dependencies in your manifest & lockfile
}

Parameters

Parameter Required? Description Parameter Type Data Type
workspace_id true Id of the workspace string string

Response Messages

HTTP Status Code Reason Response Model
400 Bad Request
Error {
message (string, read-only, required): Error details,
documentation_url (string, read-only, required): Documentation link
}
404 Not Found
Error {
message (string, read-only, required): Error details,
documentation_url (string, read-only, required): Documentation link
}