Skip to main content

Looker API Overview

This document connects the end-to-end path from tenant initialization → metadata modeling → data read/write → views/metrics → dashboards, and provides quick entry points to the related API docs.

1. API layers and gateway prefixes

  • Metadata service (Metadata)
    • Gateway prefix: ${API_BASE}/metadata/...
    • Typical capabilities: tenant operations, entities/fields/relations, views/metrics, UI Schema overlays, resource policies, dashboard configuration
  • Data service (Data)
    • Gateway prefix: ${API_BASE}/data/...
    • Typical capabilities: generic query DSL, mutation DSL, view query, metric query

2.1 Create tenant and initialize sample data (optional)

  1. Send email verification code
  • Doc: tenant-ops
  • API: POST /metadata/ops/tenants/email/verify/request
  1. Create tenant (with verification code)
  • Doc: tenant-ops
  • API: POST /metadata/ops/tenants/seed-admin
  • Notes: asynchronous initialization; when initSample=true the system seeds sample metadata/data

2.2 Modeling (two options)

Option A: use entity/field/relation APIs directly (for production-grade fine-grained modeling)

Option B: generate model via DataModel (for quickly creating usable table structures from scratch)

  • Doc: data-model
  • API: POST /metadata/models
  • Notes: automatically uses the tenant’s default data source primary and enables DDL creation

2.3 Configure UI (optional)

  1. Create/update UI Schema overlays
  • Doc: ui-schemas
  • API: GET/POST/PUT/DELETE /metadata/ui-schema-overlays
  • Notes: when schemaJson is empty, the server can generate a default UI Schema from entity fields

2.4 Configure entity Webhooks (optional)

  • Doc: webhooks
  • API: GET/POST/PUT/DELETE /metadata/entity-webhooks
  • Notes: configure change webhooks for a given entity on INSERT/UPDATE/UPSERT/DELETE, with retry and signature support

2.5 Configure permissions (optional, but required for production)

  • Doc: resource-policies
  • API: POST /metadata/resource-policies and related query/update endpoints
  • Notes:
    • objectLevelPolicy: object-level (who can do what on a resource)
    • columnLevelPolicy: column-level (field visibility/masking)
    • rowLevelPolicy: row-level (RLS predicates)

2.6 Data writes and mutations

  • Doc: mutation
  • API: POST /data/mutation/execute
  • Usage: insert/update/upsert/delete (can include transaction=true)

2.7 Data query (two paths)

Path A: generic query DSL

  • Doc: query
  • APIs:
    • POST /data/query
    • POST /data/query/validate
    • POST /data/query/explain

Path B: view query (query template + parameterization)

  • Doc: view-query
  • API: POST /data/views/{viewName}/query

2.8 Metric query (business metrics oriented)

  • Doc: metric-query
  • APIs:
    • POST /data/metric/{metricName}/query
    • POST /data/metric/query/batch
  • Notes: the server expands metric definitions into QueryRequest and runs through the unified query execution path

2.9 Dashboards

  • Doc: dashboards
  • APIs:
    • POST /metadata/dashboards (upsert by code)
    • GET /metadata/dashboards/by-code/{code}
    • GET /metadata/dashboards/{id}
    • GET /metadata/dashboards (paged)

2.10 Configure and dry-run rule engine (optional)

  • Doc: rules
  • APIs:
    • GET/POST/PUT/DELETE /metadata/rules
    • POST /metadata/rules/batch
    • POST /metadata/rules/evaluate
  • Notes: configure explainable rules via JSON predicate trees and use online dry-run (evaluate) to test them

3. Common combinations (recommendations)

  • Data entry applications:
    • Entities/fields (metadata) → UI Schema overlays (optional) → Mutation writes → Query for list/detail
  • Business analytics applications:
    • Entities/relations → Views (templated queries) → Metrics (reusable aggregation definitions) → Dashboard widget composition
  • Multi-tenant SaaS in production:
    • TenantOps → initialize samples (optional) → Resource Policy (object/column/row level) → Data service query/mutation