Looker provides multiple API versions and multiple language SDKs that use those APIs. This document describes the status and support policies for the Looker API versions and language SDKs.
Support levels
Looker API versions and SDKs have varying levels of support:
The support levels are described in the following sections.
Looker supported
Looker supports these API versions and language SDKs. Support tickets can be filed with the Department of Customer Love (DCL) and conform to Looker Support guidelines.
Community supported
This level only applies to language SDKs. Issues are filed and managed in the OpenSource repository that is used for that SDK.
A language SDK can be at the community support level for several reasons:
- It lacks the features required to achieve the Looker-supported level.
- It needs more support and automation infrastructure (automated testing, packaging, documentation, examples, etc.) before it can be fully supported by Looker.
- It is based on deprecated technology.
- It has not been tested by enough different users to be deemed ready to move out of “alpha” status.
Not supported
No support is provided. Currently, only API version 3.0 is unsupported.
API versions
The following table lists the three documented API versions as of Looker 22.4 and shows their support levels.
| Version | Support | Status | Description |
|---|---|---|---|
| 3.0 | Not supported | Deprecated | No longer supported. This API still exists in Looker but may be removed in the future without any further notice. |
| 3.1 | Looker | Deprecated | Deprecated. Only additive changes are allowed, but Looker tries to avoid changing API 3.1 at all. Instead, changes are made to API 4.0.API 3.1 is deprecated in Looker 22.4. Support for API 3.1 is expected to end in Looker 23.4, 12 months after deprecation. After the support period expires, this API may still exist in Looker, but it could be removed at that time without additional notice. |
| 4.0 | Looker | Stable | Current release. New endpoints, arguments, and structure properties as well as changes to types are still being created.Most Looker language SDKs use API 4.0, which is where new API development is done. 4.0 corrects property types that are improperly encoded by API 3.1 payloads. |
Any future API versions will be introduced as alpha and then move through the beta, stable, and deprecated lifecycles.
Language SDKs
Looker’s language SDKs have evolved throughout Looker’s lifetime and are produced with a variety of tools and techniques. All SDKs directly or indirectly use Looker’s API specification documents. The support status of the language SDKs is described in the following table.
| Language | Support | Tooling | Description |
|---|---|---|---|
| Ruby | Looker | Hand-written | The current Ruby SDK reads the Looker API specification to dynamically construct the SDK methods. It uses the API 3.1 specification by default, but it can be initialized with the 4.0 API instead. |
| Python | Looker | codegen | The Python SDK is used wherever Python can be used. The SDK can be used with either API 3.1 or 4.0, but API 4.0 is strongly recommended. See the Python SDK readme for the latest information on supported Python versions. |
| TypeScript | Looker | codegen | The TypeScript SDK is used for both node and browser applications. The SDK can be used with either API 3.1 or 4.0, but API 4.0 is strongly recommended. |
| Kotlin | Community | codegen | The Kotlin SDK is used for Android mobile and Java Virtual Machine (JVM) applications. It requires API 4.0 for type correctness. |
| Swift | Community | codegen | The Swift SDK is used for iOs and MacOS applications. It requires API 4.0 for type correctness. |
| R | Community | Swagger | LookR is the Looker SDK for the R programming language and works with R Studio. It uses an older version of API 3.1. |
| Other | Community | codegen | Other language SDKs that are generated by Looker’s codegen project — such as C# (Look#) and Go (GoLook) — are Community supported. Issues should be filed in the sdk-codegen repository. |
Tooling legend
- codegen — Generated by Looker’s SDK codegen project and uses a hand-written run-time library for each SDK.
- Swagger — Generated by the Swagger code generator OpenSource tool. For programming languages not directly supported by Looker’s code generator, we have provided a legacy generator option in the codegen repository that should simplify the custom generation. This “legacy” generator uses the OpenSource OpenAPI code generator, which is the replacement for the Swagger code generator.
- Hand written — All source code is written by hand with no code generation involved.
SDK versioning
Looker recently adopted a versioning scheme that matches language SDKs with the Looker release that was used to generate them. For example, this means an SDK that was produced using Looker 21.10 specifications will have a version that starts with 21.10.*.
Language SDKs
The most recent language SDKs (produced by Looker codegen) match Looker release versions. For example, the Python and TypeScript SDKs match their respective Looker release versions.
As we move our older language SDKs to codegen, or publish existing codegen SDKs to their package managers, the SDK version will be set to match the Looker release version.
Runtime library package versions
The TypeScript SDK depends on a separate runtime library (RTL) package, written by Looker, that generically supports REST APIs. Because it is not specific to any Looker release, this package is versioned independently of the language SDKs that use it.
When other language SDKs are published to package managers, their RTLs may become a separate package. Any separate RTL package will use semantic versioning rather than matching Looker release versions.