Looker

In Looker, go to Admin (gear icon at the top right of your Looker instance) → Users → find or create a service user specifically for Bubble API access. Using a dedicated service user (rather than your personal admin account) limits the scope of access and makes it easy to revoke if needed. On the user's profile page, scroll down to 'API Keys' and click 'Edit Keys' → 'New API Key'. Looker generates a client_id and client_secret pair. Copy both values immediately — the client_secret cannot be retrieved again after you close this modal. Grant the service user a Looker model permission set that allows Read access to the explores and models you want to query from Bubble. Work with your Looker admin to define the minimum permission set needed. Also note your Looker instance base URL (e.g., https://yourcompany.looker.com) — this is the base for all API calls. Do not confuse this with the Looker API base URL, which is https://yourcompany.looker.com/api/4.0. One critical point to understand: Looker has two completely separate secret credentials with different purposes. - client_secret: used in the /api/4.0/login call. Grants API access to query data, list explores, run queries. - embed secret: used to sign SSO embed URLs. Found in Looker Admin → Platform → Embed. Only needed if you are building the iframe embed path. Using the embed secret in the /api/4.0/login call (or vice versa) will always produce an authentication error. Make sure you are copying the API Key client_secret, not the embed secret, for the setup in the next step.

1{
2  "looker_credentials_to_copy": {
3    "client_id": "from Looker Admin → Users → [service user] → API Keys",
4    "client_secret": "from the same API Keys section [shown only once]",
5    "instance_base_url": "https://yourcompany.looker.com",
6    "api_base_url": "https://yourcompany.looker.com/api/4.0"
7  },
8  "important": "Do NOT confuse client_secret (API access) with embed secret (SSO embed URL signing) — these are separate credentials in different parts of Looker Admin"
9}

In your Bubble app, click the Plugins tab → API Connector → 'Add another API'. Name this group 'Looker Auth'. Set the base URL to your Looker instance URL (e.g., https://yourcompany.looker.com). Click 'Add another call'. Name it 'Get Access Token'. Set the method to POST. Set the endpoint path to /api/4.0/login. In the Body section, set the body type to 'Form data' (application/x-www-form-urlencoded — the Looker login endpoint requires this, not JSON). Add two body parameters: - client_id: your Looker API client_id. Private checkbox: UNCHECKED (client_id is a public identifier in Looker's API model). - client_secret: your Looker API client_secret. Private checkbox: CHECKED. This is the sensitive credential — marking it Private ensures Bubble never logs it in the API Connector response panel or the Logs tab. Set 'Use as' to 'Action'. Click 'Initialize call'. Bubble will send the POST request to Looker. A successful response looks like: {"access_token": "abc123...", "token_type": "Bearer", "expires_in": 3600, "refresh_token": null} If you see 'There was an issue setting up your call', check: - The endpoint URL path is exactly /api/4.0/login (not /api/3.1 or /api/4.1) - The body type is Form data, not JSON - The client_id and client_secret are from the Looker Admin → API Keys section, not from SSO embed settings - Your Looker admin has enabled API access for the service user Note that Looker tokens expire after 1 hour and there is no refresh_token mechanism — you must call /api/4.0/login again when the token expires. This is a Looker API design choice; plan your Bubble token-refresh strategy around it.

1{
2  "method": "POST",
3  "url": "https://yourcompany.looker.com/api/4.0/login",
4  "body_type": "form_data",
5  "body_params": {
6    "client_id": "{{client_id}}",
7    "client_secret": "<private>"
8  },
9  "use_as": "Action",
10  "expected_response": {
11    "access_token": "eyJ...",
12    "token_type": "Bearer",
13    "expires_in": 3600
14  }
15}

Click 'Add another API' in the API Connector to create a second group. Name it 'Looker Data API'. Set the base URL to https://yourcompany.looker.com/api/4.0. Add a shared header to this group: Key = Authorization, Value = Bearer [leave empty — you will populate this dynamically from a Workflow], Private = CHECKED. Add two calls inside this group: Call 1 — 'List Explores': GET /lookml_models. Use as Data. Initialize with a real Bearer token in the Authorization header (use the token you got from the login call above for initialization — it is valid for 1 hour). This returns your available LookML models and their explores — useful for discovering what data you can query. Call 2 — 'Run Query': POST /queries/run/json. Use as Action. Body type: JSON. The body specifies what data to query: { "model": "{{model_name}}", "view": "{{view_name}}", "fields": ["{{field1}}", "{{field2}}"], "filters": {}, "limit": "100" } The 'fields' array specifies which LookML dimensions and measures to include in the result (format: 'view_name.field_name', e.g., 'orders.total_revenue'). Ask your Looker admin or data team for the correct model, view, and field names for your use case. Initialize the Run Query call with real values for model, view, and at least one field, using a live Bearer token. The response is a JSON array of row objects where each key is a field name (e.g., {"orders.total_revenue": 12345, "orders.count": 87}). If you see 'There was an issue setting up your call' when initializing, the most common causes are: the access_token has expired (they last only 1 hour — get a fresh one from the login call), the model or view name is misspelled, or the service user does not have permission to access the specified explore.

1{
2  "api_group": "Looker Data API",
3  "base_url": "https://yourcompany.looker.com/api/4.0",
4  "shared_headers": [
5    {
6      "key": "Authorization",
7      "value": "Bearer {{dynamic_from_workflow}}",
8      "private": true
9    }
10  ],
11  "run_query_call": {
12    "method": "POST",
13    "path": "/queries/run/json",
14    "body": {
15      "model": "{{model_name}}",
16      "view": "{{view_name}}",
17      "fields": ["{{field1}}", "{{field2}}", "{{field3}}"],
18      "filters": {
19        "{{filter_field}}": "{{filter_value}}"
20      },
21      "sorts": ["{{sort_field}} desc"],
22      "limit": "100"
23    },
24    "use_as": "Action"
25  }
26}

Create a Repeating Group on your Bubble page. Set its Type of content to a new data type called 'Looker Row' with fields matching the Looker query response (for example: revenue number, order_count number, region text). Add text elements inside the Repeating Group cell for each field. Alternatively, use a Custom State of type 'text' (or a custom type) to hold the query result in memory without writing to the Bubble database — this avoids WU costs from database operations for one-time dashboard displays. Create a Workflow event: 'When page is loaded' → add actions: Action 1: Check if the stored token is still valid. Add a condition: 'Only when App Data Looker Token's expires_at < Current date/time'. If true, proceed. If false, skip to Action 3. Action 2 (token refresh, conditional): 'Plugins → Looker Auth - Get Access Token'. Run this when the stored token is expired. Then: 'Make changes to App Data Looker Token': access_token = Result of Step 2's access_token, expires_at = Current date/time + 3540 seconds. Action 3: 'Plugins → Looker Data API - Run Query'. In the Authorization dynamic field, enter 'Bearer ' + 'App Data Looker Token's access_token'. Set model, view, and fields dynamically (from Option Sets or hardcoded values). Set limit to 100. Action 4: 'Set Custom State' or 'Make changes to a list of Looker Row Things' — populate with the results from Step 3's response array. Bind the Repeating Group to the Custom State or the database search. In each Repeating Group cell, bind each text element to the corresponding Looker Row field. For large Looker explores returning many rows: use the 'limit' and 'offset' parameters with Bubble Pagination or a 'Load More' button. Querying Looker explores with complex joins and many rows can exceed Bubble's 30-second workflow timeout — keep queries focused and use Looker's filters to scope results before they reach Bubble. Add Bubble privacy rules to the Looker Row data type: Data tab → Privacy → Looker Row → restrict read access to logged-in users with the appropriate role. This prevents raw business data from being exposed via Bubble's public Data API.

1// Workflow: When page is loaded
2//
3// Condition check: Does Looker Token record's expires_at < Current date/time?
4//
5// Action 1 (if token expired):
6//   Plugins → Looker Auth - Get Access Token
7//   Result → access_token
8//
9// Action 2 (if token expired):
10//   Make changes to Looker Token
11//   access_token = Action 1's access_token
12//   expires_at = Current date/time + 3540 seconds
13//
14// Action 3:
15//   Plugins → Looker Data API - Run Query
16//   Authorization = "Bearer " + Looker Token's access_token
17//   model = your_model_name
18//   view = your_view_name
19//   fields = ["your_view.dimension1", "your_view.measure1"]
20//   limit = 100
21//
22// Action 4:
23//   Make changes to Looker Row list (or set Custom State)
24//   Populate from Action 3's result array
25//
26// Repeating Group data source: Search for Looker Rows
27// Cell bindings:
28//   'Revenue': Current cell's revenue formatted as currency
29//   'Region': Current cell's region

Looker access tokens expire after exactly 1 hour and there is no refresh token — you must call /api/4.0/login again. On a Bubble free plan, the page-load token check (from step 4) handles this adequately for pages loaded within session boundaries, but users who keep the same page open for over an hour will see stale or missing data until they reload. For a more robust production setup on a paid Bubble plan: 1. Go to Settings tab → API → check 'This app exposes a Workflow API' to enable Backend Workflows. 2. In the left sidebar, click 'Backend workflows' → 'Add a new API workflow'. Name it 'Refresh Looker Token'. 3. Inside this workflow, add two actions: (a) Plugins → Looker Auth - Get Access Token, (b) Make changes to App Data Looker Token: access_token = Step 1's access_token, expires_at = Current date/time + 3540 seconds. 4. Click the clock icon to create a recurring schedule: run every 55 minutes. With this scheduler running, the Looker token in the Bubble database is always fresh. Page-load Workflows can use the stored token directly without a login call most of the time, reducing WU consumption. For the WU-conscious: each /api/4.0/login call and each /queries/run/json call consumes WUs. Cache Looker query results in the Bubble database with a fetched_at timestamp and only re-query Looker when the cache is older than your acceptable freshness window (for most business data, 15–60 minutes is fine).

1// Backend Workflow: 'Refresh Looker Token'
2// Settings → API → expose Workflow API → enabled
3// Backend Workflows → New API Workflow → 'Refresh Looker Token'
4//
5// Action 1: Plugins → Looker Auth - Get Access Token
6//   Returns: access_token (valid 3600 seconds)
7//
8// Action 2: Make changes to App Data Looker Token
9//   access_token = Action 1's access_token
10//   expires_at = Current date/time + 3540 seconds
11//
12// Scheduled: every 55 minutes (3300 seconds)
13//
14// Note: Backend Workflows require a paid Bubble plan.

If you need to embed a full Looker dashboard iframe rather than displaying queried data in Bubble's native UI components, you must use Looker's SSO embed URL feature. This requires generating a signed URL using your Looker embed secret and a HMAC-SHA1 algorithm. Bubble's API Connector cannot compute HMAC-SHA1 signatures natively — there is no native Bubble action for cryptographic signing. This is the key architectural limitation for the Looker embed path in Bubble. The practical solution for teams that need the full embed: deploy a minimal external function (a Cloudflare Worker is a good fit — free tier, global edge, ~10 lines of JavaScript) that accepts an unsigned Looker embed URL and returns a signed version. Call this external endpoint from Bubble's API Connector. The embed secret stays in the Cloudflare Worker's environment variables and never enters Bubble. In Bubble, the workflow for embed is: 1. Build the unsigned SSO embed URL (path + params including session length, user attributes, permissions) — this can be done with Bubble's dynamic text operators. 2. POST to your Cloudflare Worker endpoint with the unsigned URL as a body parameter. 3. The Worker returns the HMAC-SHA1 signed URL. 4. Inject the signed URL into an HTML element iframe src attribute in Bubble. The embed secret NEVER enters Bubble. The Cloudflare Worker holds it in its own environment variable (secure, not logged). This is the honest recommendation for this specific integration — attempting to sign the URL inside Bubble using workarounds (e.g., Toolbox plugin JavaScript) would leak the embed secret to the browser. If you do not have a Cloudflare Worker or similar endpoint, use the data-query path (steps 1–5) instead — it is fully supported natively in Bubble with no external dependencies.

1// Cloudflare Worker (external, NOT in Bubble) — minimal HMAC-SHA1 signing
2// Store LOOKER_EMBED_SECRET in Cloudflare Worker environment variables
3
4// workers/looker-sign.js
5export default {
6  async fetch(request, env) {
7    if (request.method !== 'POST') return new Response('Method not allowed', { status: 405 });
8    const { embed_url } = await request.json();
9    const secret = env.LOOKER_EMBED_SECRET;
10    // Build the string to sign per Looker SSO embed specification
11    // See: https://cloud.google.com/looker/docs/single-sign-on-embedding
12    const encoder = new TextEncoder();
13    const keyData = encoder.encode(secret);
14    const msgData = encoder.encode(embed_url);
15    const key = await crypto.subtle.importKey('raw', keyData, { name: 'HMAC', hash: 'SHA-1' }, false, ['sign']);
16    const sig = await crypto.subtle.sign('HMAC', key, msgData);
17    const hexSig = Array.from(new Uint8Array(sig)).map(b => b.toString(16).padStart(2, '0')).join('');
18    const signed_url = embed_url + '&signature=' + hexSig;
19    return new Response(JSON.stringify({ signed_url }), { headers: { 'Content-Type': 'application/json' } });
20  }
21};
22
23// Bubble HTML element (after calling the Worker from an API Connector call):
24// <iframe src="[Dynamic: Result of Worker Call's signed_url]" width="100%" height="600" frameborder="0"></iframe>