.png)
Looker Integration Guide
Integrate Looker’s governed analytics with enterprise applications through its REST API, scheduled deliveries, supported webhook-style actions, and controlled Martini workflows.
Looker integration options at a glance
Looker’s primary integration mechanism is the Looker API 4.0 REST API, which provides programmatic access to dashboards, Looks, queries, Explores, models, users, groups, folders, and scheduled plans. Looker also supports asynchronous query tasks, scheduled delivery, and result export in formats such as JSON and CSV. Selected configurations provide webhook-style outbound delivery for query results or scheduled analytics, but these are not universal object-change events. Martini can authenticate with Looker API credentials or applicable OAuth 2.0 flows, orchestrate API and scheduler-triggered workflows, transform results, expose controlled REST APIs, and route governed analytics to enterprise systems.
| Integration point | Supported by Looker? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Looker API 4.0 provides access to dashboards, Looks, queries, Explores, models, users, groups, folders, scheduled plans, and administrative resources. | Martini can consume Looker REST endpoints from workflows, authenticate requests, transform payloads, apply business rules, and expose downstream REST APIs. |
| Webhooks / outbound callbacks | Limited | Supported configurations can deliver query results or scheduled analytics output to webhook-style destinations through selected actions or integrations. | Martini can expose an authenticated API endpoint or webhook-triggered workflow, validate the payload, transform it, and route it to downstream systems. This should not be treated as a universal Looker event stream. |
| Bulk / async / batch APIs | Limited | Asynchronous query tasks and scheduled deliveries support longer-running or recurring analytics workloads, but Looker does not provide a general bulk CRUD API for all objects. | Martini can submit or retrieve asynchronous query tasks, poll for completion, enforce timeouts, and process scheduled results with checkpointing and retry controls. |
| File / result export | Limited | Queries, Looks, and dashboards can return or render results in supported formats such as JSON, CSV, and other instance-supported rendering formats. | Martini can consume structured or file-like result payloads, parse JSON or CSV, map fields, validate schemas, and send the output to applications or databases. |
| Database / analytics access | Yes | Looker exposes governed analytics through models, Explores, queries, Looks, dashboards, and result endpoints. The Looker API is not general-purpose direct SQL access to every underlying database. | Martini can consume governed analytics through Looker APIs and can separately connect to an underlying database when that database integration is explicitly configured. |
| Authentication | Yes | Looker supports API client credentials exchanged for access tokens. OAuth 2.0 and Google Cloud IAM may apply depending on the deployment and API surface. | Martini can store secrets in environment configuration, call the applicable authentication flow, and send bearer tokens with Looker API requests. |
| GraphQL APIs | Not confirmed | No public Looker GraphQL API was confirmed in the supplied official documentation. | Martini supports consuming GraphQL APIs generally, but Looker integrations should use the confirmed REST API unless a separately documented endpoint is provided. |
| SOAP APIs | Not confirmed | No current public Looker SOAP API was confirmed. | Martini can consume SOAP services generally, but SOAP should not be used for Looker unless a separate supported service is documented. |
How Looker exposes data and business events
Looker REST APIs
The Looker API 4.0 is the primary programmatic interface for dashboards, Looks, queries, Explores, models, users, groups, folders, scheduled plans, and other resources. Access is governed by the authenticated user’s permissions, model restrictions, access grants, user attributes, and row-level rules.
Martini implementation pattern
Martini implementation pattern: Martini authenticates against the applicable Looker login or OAuth flow, calls the required REST operation from a workflow, validates the response, maps the result to a canonical model, and routes it to an application, database, or Martini API.
Implementation sequence
Looker scheduled deliveries
Looker supports scheduled delivery of query results and dashboards for recurring analytics processing. Scheduled delivery is batch-oriented and can be preferable to repeatedly executing the same query from an external workflow.
Martini implementation pattern
Martini implementation pattern: A scheduled Martini workflow can retrieve or process the delivered output, or coordinate with Looker API operations for the same reporting window. The workflow records the Looker object, filters, execution time, and destination to support reconciliation.
Implementation sequence
Looker webhook-style deliveries
Selected Looker actions and integrations can deliver query results or scheduled analytics output to webhook-style destinations. This capability depends on the Looker edition, deployment, administrator configuration, enabled actions, and use case; it is not a universal notification stream for object changes.
Martini implementation pattern
Martini implementation pattern: Martini exposes an authenticated REST endpoint or webhook-triggered workflow, validates the incoming payload and request context, deduplicates deliveries, transforms the analytics output, and routes it to downstream services.
Implementation sequence
Looker asynchronous queries
Looker provides asynchronous query execution through query tasks and related API operations for longer-running or larger analytics requests. These operations support batch-style processing but are not a general bulk CRUD interface for all Looker objects.
Martini implementation pattern
Martini implementation pattern: Martini submits an asynchronous query, stores the task reference and query context, polls for completion with bounded intervals, handles timeout or failure states, and processes the completed result once.
Implementation sequence
Looker result exports
Looker can return or render query, Look, and dashboard results in supported formats including JSON and CSV, subject to the instance configuration, requested object, and permissions. These exports represent governed analytics output rather than a general attachment-management API.
Martini implementation pattern
Martini implementation pattern: A workflow retrieves the selected result, parses the chosen format, validates schema and data types, converts it to the target representation, and sends it to an operational system or database.
Implementation sequence
Common Looker integration patterns
Pattern 1: Deliver governed analytics to an operational application
When to use this pattern
Use this pattern when an operational team needs selected Looker metrics in Salesforce, ServiceNow, NetSuite, or another application. The workflow should preserve the Looker model context and permissions while converting analytical output into an operational schema.
Integration direction
Example Mapping
| Looker Field | Canonical Field | Target Field |
|---|---|---|
| order_count | orderCount | u_order_count |
| revenue | revenueAmount | u_revenue_amount |
| report_date | reportDate | u_report_date |
Martini implementation pattern
A scheduler-triggered Martini workflow executes a permitted Look or query, handles pagination or asynchronous completion, validates expected dimensions and measures, maps the result to the target API, and applies an idempotent key based on the reporting period and analytical subject. Transient API failures are retried with backoff, while schema or permission failures are routed for review.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Load Looker results into a database
When to use this pattern
Use this pattern when a downstream application needs a periodically refreshed operational table rather than interactive BI access. It is suitable for curated metrics, reporting snapshots, and reconciliation datasets.
Integration direction
Example Mapping
| Looker Field | Canonical Field | Target Field |
|---|---|---|
| customer_id | customerId | customer_id |
| gross_margin | grossMargin | gross_margin |
| updated_at | sourceUpdatedAt | source_updated_at |
Martini implementation pattern
Martini invokes a Looker query on a defined schedule, submits it asynchronously when the workload requires, polls for completion, and transforms JSON or CSV results into database rows. The workflow uses a stable reporting-period and business-key combination to prevent duplicate writes, commits in controlled batches, and records the Looker query context for reconciliation.
Martini capabilities used
- workflows
- scheduler triggers
- API consumption
- JSON and CSV handling
- data mapping
- database connectivity
- error handling
Pattern 3: Expose a controlled Looker analytics API façade
When to use this pattern
Use this pattern when an embedded application, partner, or internal service needs selected Looker analytics without direct access to Looker credentials or unrestricted API resources.
Integration direction
Example Mapping
| Looker Field | Canonical Field | Target Field |
|---|---|---|
| account_id | accountId | filters.account_id |
| period_start | periodStart | filters.order_date_start |
| pipeline_value | pipelineValue | response.pipeline_value |
Martini implementation pattern
Martini exposes a REST API that validates business parameters, checks caller authorization and entitlements, invokes a permitted Looker query or Look, masks or reshapes sensitive fields, and returns a normalized response. Rate control, request correlation, timeouts, and bounded retries protect both the façade and the Looker instance.
Martini capabilities used
- API exposure
- workflows
- authentication and authorization
- API consumption
- data transformation
- business rules
- monitoring
Pattern 4: Process supported Looker delivery notifications
When to use this pattern
Use this pattern for Looker configurations that support webhook-style actions or outbound delivery of query results and scheduled analytics. It should not be used as a substitute for universal change notifications for dashboards, Looks, users, models, or permissions.
Integration direction
Example Mapping
| Looker Field | Canonical Field | Target Field |
|---|---|---|
| dashboard_title | dashboardName | message.title |
| scheduled_at | deliveryTime | message.timestamp |
| result_url | resultReference | message.link |
Martini implementation pattern
Martini receives the delivery through an authenticated endpoint, validates its structure, checks for replay or duplicate processing, enriches the payload when required, and routes the normalized message to Slack or another target. Failed downstream calls are retried safely, while invalid payloads are quarantined with correlation details.
Martini capabilities used
- API exposure
- webhook consumption
- workflows
- data mapping
- business rules
- duplicate handling
- error handling
Applications commonly integrated with Looker
Looker is commonly positioned as a governed semantic and analytics layer alongside operational applications, data platforms, and collaboration tools. Martini can coordinate these relationships through Looker’s REST API, scheduled deliveries, supported outbound actions, and separate APIs exposed by downstream systems. The direction depends on the system of record and whether the use case is analytics consumption, operational write-back, or data preparation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Deliver sales pipeline, account, opportunity, and performance analytics to operational teams, or use Salesforce data as a governed source for Looker reporting. | Looker → Martini → Salesforce | A scheduled Martini workflow executes a permitted Looker query or Look, validates the result, maps metrics to Salesforce fields or a downstream Salesforce API model, and applies idempotent writes with retry handling. |
| ServiceNow | Send service-level, incident, request, and operational performance metrics to ServiceNow workflows or combine ServiceNow data with other governed sources in Looker. | Looker → Martini → ServiceNow | Martini retrieves a Looker result on a schedule or receives a supported delivery, transforms the analytics payload into the ServiceNow API schema, validates required values, and records correlation and retry status. |
| NetSuite | Provide finance, revenue, inventory, and order analytics to operational or finance processes while preserving Looker’s model and access controls. | Looker → Martini → NetSuite | A workflow invokes a Looker query or Look, normalizes JSON or CSV results, applies business rules for reporting periods and currencies, and sends selected outputs to NetSuite through its available API. |
| BigQuery | Use Looker models and Explores as a governed analytics layer over BigQuery data, or deliver selected Looker results to downstream processing. | BigQuery → Looker → Martini | Martini can orchestrate Looker API extraction for downstream use, or separately connect to BigQuery when direct database integration is required; mappings, checkpoints, and validation keep analytical outputs consistent. |
| Snowflake | Use Looker as a semantic and visualization layer over Snowflake data and make selected governed results available to operational workflows. | Snowflake → Looker → Martini | Martini retrieves approved Looker query results, converts structured output into a target schema, and routes it to applications or databases; direct Snowflake access remains a separate database integration. |
| Jira | Combine issue, project, sprint, and delivery metrics with business data in Looker, or distribute selected analytics to engineering operations. | Jira → Martini → Looker | Martini can process Looker-derived metrics for Jira-related workflows or coordinate Jira data through its own API and a data platform, applying field mapping, validation, and duplicate protection. |
| Slack | Deliver scheduled Looker reports, alerts, or selected analytics results to channels used by business and operations teams. | Looker → Martini → Slack | Where the Looker configuration supports an outbound action or delivery, Martini can receive the payload, validate and enrich it, then call the Slack integration endpoint with controlled routing and logging. |
| Workday | Combine workforce and finance analytics with other enterprise data sources, or route selected governed metrics to workforce processes. | Workday → Martini → Looker | Martini can orchestrate Looker result delivery for selected Workday-related processes or separately consume Workday data for Looker-bound pipelines, with access-aware mappings and audit logging. |
How to build a Looker integration in Martini
Objective
Establish the Looker API connection using the authentication method supported by the target deployment and keep credentials outside workflow definitions.
Instructions in Martini
- Confirm the Looker deployment and API version
- Configure API client credentials or the applicable OAuth 2.0 flow
- Store client secrets and tokens in protected Martini environment configuration
- Grant only the required Looker model, Explore, content, and administrative permissions
Objective
Select the execution model that matches the analytics requirement, distinguishing recurring extraction from supported Looker delivery events.
Instructions in Martini
- Use a scheduler for recurring query, Look, or dashboard retrieval
- Use an authenticated Martini API endpoint for supported Looker deliveries
- Use a workflow trigger for inbound webhook-style payloads
- Define reporting windows, time zones, and concurrency limits
Objective
Call the appropriate Looker REST operation and handle pagination, asynchronous query tasks, and supported result formats.
Instructions in Martini
- Select the permitted model, Explore, Look, dashboard, or query
- Retrieve list pages until the documented result set is complete
- Submit and poll asynchronous query tasks for larger workloads
- Prefer structured JSON or CSV output when downstream mapping is required
Objective
Coordinate API calls, validation, enrichment, routing, and persistence as a maintainable Martini workflow rather than a single unmanaged script.
Instructions in Martini
- Store request context, query filters, and correlation identifiers
- Branch on query status, permissions, validation results, and target response codes
- Use reusable workflow logic for common Looker retrieval and normalization
- Keep source and target responsibilities explicit
Objective
Convert Looker dimensions, measures, pivots, and result formats into the target application or database model.
Instructions in Martini
- Define a canonical representation for analytical results
- Normalize dates, numbers, currencies, pivots, and localized values
- Validate expected dimensions and measures before writing
- Apply target-specific field mappings and transformations
Objective
Enforce access, reporting-period, entitlement, masking, and duplicate-prevention rules before data reaches downstream systems.
Instructions in Martini
- Preserve Looker model and permission context
- Validate filters and permitted business subjects
- Mask or omit sensitive analytics fields where required
- Generate stable idempotency keys for recurring deliveries
Common Looker data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Dashboards | Collections of visualizations and tiles used to present governed analytics to business users or external applications. | Salesforce, ServiceNow, Slack, portals, operational databases | Martini can retrieve, render, or export supported dashboard results through the Looker REST API, then validate, transform, and route the output. |
| Looks | Saved queries or reports that can be retrieved, executed, scheduled, or rendered for recurring analytics delivery. | NetSuite, Salesforce, Slack, data warehouses, SQL databases | A workflow can execute or retrieve a permitted Look, process the result format, apply business rules, and write idempotently to a target. |
| Queries | Definitions containing dimensions, measures, filters, pivots, sorts, and result formats based on an Explore. | Operational applications, reporting stores, SQL databases, APIs | Martini can submit synchronous or asynchronous queries, poll query tasks when required, normalize results, and checkpoint execution metadata. |
| Explores | Queryable business subjects exposed by LookML models and used as the basis for governed queries. | Data platforms, reporting services, API façades | Martini uses permitted Explores through Looker API operations while preserving model context, access restrictions, filters, and selected fields. |
| Models | LookML-based semantic definitions for database connections, Explores, joins, dimensions, and measures. | Analytics pipelines, governance processes, monitoring systems | Martini can retrieve model-related metadata where permitted and validate expected fields and data types against workflow mappings. |
| Users and Groups | Identity and authorization objects controlling access to Looker content, models, Explores, and administrative resources. | Identity platforms, governance stores, audit systems | Martini can synchronize or audit permitted users and groups through paginated API workflows while applying least-privilege handling and duplicate protection. |
Authentication and security considerations
Authentication and authorization
Looker API credentials are typically issued for a Looker user and exchanged for an access token through the Looker login endpoint. OAuth 2.0 and Google Cloud IAM may apply depending on the deployment and API surface, but they should not be assumed to replace Looker API credentials for every operation.
- Use a dedicated integration user with least-privilege access.
- Protect client secrets and tokens with Martini environment configuration or secrets management.
- Account for model permissions, Explore permissions, folders, access grants, user attributes, and row-level security.
- Use HTTPS for API calls and inbound delivery endpoints.
- Limit logs and retention when results contain customer, employee, financial, or other sensitive data.
Operational considerations for Looker integrations
API and workload controls
Looker list endpoints may paginate, while large queries may require asynchronous execution or scheduled delivery. Control concurrency, use bounded polling and backoff, and confirm applicable quotas and limits with the Looker administrator.
Data contracts and idempotency
Result schemas can change when LookML models, Explores, joins, dimensions, measures, pivots, filters, or access grants change. Validate fields and data types, use stable business keys, and record query context and execution time to prevent duplicate writes.
Delivery security and monitoring
Supported webhook-style deliveries should be authenticated, checked for replay, and protected with payload-size limits. Monitor workflow outcomes, target responses, missing fields, timeouts, and permission failures, and test changes against representative Looker models before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini coordinates Looker authentication, query execution, asynchronous polling, scheduled processing, transformation, target writes, and error handling in maintainable workflows. This avoids duplicating operational logic across point-to-point scripts.
Controlled API access
Martini can expose a REST API façade that centralizes validation, authorization, entitlement checks, masking, rate control, logging, and response transformation without distributing Looker credentials to every consumer.
Reusable integration assets
Teams can reuse workflow patterns for pagination, result normalization, checkpointing, retries, and reconciliation across Looker integrations. Martini also supports separate database, file, and application integrations when governed analytics must reach systems outside Looker.
Frequently asked questions
Looker can be integrated primarily through its Looker API 4.0 REST API, which provides access to dashboards, Looks, queries, Explores, models, users, groups, folders, and scheduled plans. Enterprise workflows can also use asynchronous query tasks, scheduled delivery, supported result exports, and selected webhook-style outbound actions.
Yes. Martini can consume Looker REST API endpoints, authenticate with Looker API credentials or an applicable OAuth 2.0 flow, execute or retrieve queries and Looks, transform results, receive supported webhook-style deliveries, and route governed analytics to applications or databases.
No. A dedicated Looker connector is not required. Martini can integrate with Looker using its confirmed REST API, applicable authentication methods, scheduled workflows, supported outbound deliveries, and Martini APIs for controlled downstream access.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Looker with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Looker, Google Cloud, infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
The Looker REST API is the primary method for current integrations. Use asynchronous query tasks or scheduled delivery for larger or recurring workloads, structured result exports for data movement, and supported webhook-style actions when the Looker deployment and use case provide them. No public Looker GraphQL or current SOAP API was confirmed.
Looker supports webhook-style outbound delivery for selected action, query-result, or scheduled-delivery scenarios. It should not be treated as a universal event stream for dashboard, Look, model, user, permission, or Explore changes. Scheduled Martini polling may be required for broader change detection.
Synchronization commonly uses scheduled Martini workflows that retrieve permitted Looks, dashboards, or queries, handle pagination or asynchronous execution, transform results, and write them to target systems. Checkpoints, reporting-period keys, query context, and idempotent writes help prevent duplicate processing and support reconciliation.
Martini can map dimensions, measures, pivots, JSON, and CSV results into canonical and target-specific models, while applying validation and business rules. Workflows can use bounded retries, timeout handling, duplicate protection, logging, and quarantine paths. Martini can also expose a controlled REST API façade that validates parameters, invokes permitted Looker operations, and returns normalized responses.
Related Martini documentation
Workflows
Data
Connect Looker to your enterprise workflows
Use Martini to turn Looker’s governed analytics into reliable, secure workflows and APIs for the applications, databases, and teams that depend on them.