Overview
A client-mode connector for the Looker API 4.0. Use it to put Looker results on MQTT, such as OEE per line, scrap by shift or open maintenance orders for an andon board or HMI, and to let plant events drive Looker: run a scheduled plan once when a shift or batch closes, render a dashboard to PDF, or expire a datagroup cache after new data lands in the warehouse. The connectorLookerRestApi in LookerRestApi.lot has 44 events (30 GET, 11 POST, 2 PATCH, 1 PUT). Five are writes: ScheduledPlanRunOnceById, ScheduledPlanRunOnce, ScheduledPlanCreate, ScheduledPlanUpdate and DatagroupUpdate. There are no DELETE events.
Set BASE_ADDRESS to your Looker URL with no trailing slash and no /api, for example https://acme.cloud.looker.com or a Looker (Google Cloud core) instance URL ending in looker.app. Every endpoint already starts with /api/4.0. Some older self-hosted instances serve the API on port 19999 (https://acme.looker.com:19999). Topics use analytics/looker/<object>/<verb>; replies land on <topic>/response.
See the base guide: REST API Connectors.
Auth: a Looker admin creates an API key (client ID and client secret) on a user in Admin > Users > Edit Keys. The
Login event posts client_id and client_secret as a form to /api/4.0/login and gets back an access_token that lasts about an hour. Every other event except Versions sends Authorization: token <access_token> (the word token is required). The token acts as that user, so give the API user a role with only the models and permissions the broker needs. Keep LOOKER_CLIENT_ID, LOOKER_CLIENT_SECRET and the current token in broker secrets, read them with GET SECRET in the action that builds the payload, never retain topics that carry them, and restrict analytics/looker/auth/# with ACLs.Events
Payload fields are JSON on the source topic: ids (
query_id, look_id, dashboard_id, scheduled_plan_id, query_task_id, render_task_id, folder_id, alert_id, datagroup_id, connection_name, lookml_model_name, explore_name, slug), result_format (json, json_detail, csv, txt, md, sql, or png / jpg / pdf for renders), query (a URL query string without ?, or ""), width and height for renders, body (a JSON object) for POST and PATCH events, and form for Login.
Basic Syntax
An excerpt of the template (the full file has all 44 events and comments):Examples
Log in and keep the token in a secret-backed action (the response carriesaccess_token):
analytics/looker/auth/login. Then run an inline query and get the rows as JSON on analytics/looker/queries/run_inline/response:
analytics/looker/looks/run:
analytics/looker/scheduled_plans/run_once_by_id (this delivers email or other destinations):
analytics/looker/datagroups/update:
analytics/looker/render_tasks/dashboard, poll analytics/looker/render_tasks/get until status is success, then read the file from analytics/looker/render_tasks/results/response:
Notes
- Long queries: use
QueryTaskCreateand pollQueryTaskResultsinstead of waiting onQueryRunInline;RunningQueriesListshows what is running. - Field names for inline queries come from
ExploreGet(dimensions and measures of an explore). Dashboard tiles carry aquery_id(DashboardElements) thatQueryRuncan run directly. SqlQueryCreateandSqlQueryRunneed theuse_sql_runnerpermission.RenderTaskResultsreturns a binary file, published as received.- Not packaged on purpose: every DELETE (Looks, dashboards, schedules, alerts, logout, killing queries; pause a schedule with
ScheduledPlanUpdateand{"enabled": false}instead), user and content administration, LookML project and git operations, and embed SSO. A scheduled plan with a webhook destination can POST to a separate server-mode connector. - Requests are limited per instance; keep polling intervals coarse and prefer
cache=true.

