Data Studio custom connector: when to build one, how it works and what it costs

What is a Data Studio custom connector?

It is code that teaches Data Studio how to log in to a source, which fields it offers and how to fetch rows on request. Google's developer documentation calls these community connectors (they kept that name through the Looker Studio years), and they are written in Google Apps Script against Google's Connector API.

Every connector must define four functions. getAuthType tells Data Studio how the user signs in. getConfig asks the user for settings, such as an account ID or a date range requirement. getSchema returns the list of dimensions and metrics with their types. getData returns rows for the fields a chart actually requested. Once deployed, the connector appears as a data source like the native GA4 or Google Ads connectors, and your reports, calculated fields, filters and scheduled delivery work on top of it as usual.

Google's documentation lists seven supported auth types: OAuth 2.0, USER_PASS, USER_TOKEN, KEY, PATH_USER_PASS, PATH_KEY and NONE. Credentials must be stored in the user's own properties (PropertiesService.getUserProperties), not typed into configuration fields, so an API key never ends up visible to other report editors.

Do you need a custom connector, a partner connector or a data pipeline?

Most teams that ask me for a custom connector end up needing something else. Before any code is written, I put the source through three questions: is there already a connector for it, how much data does each report need, and how fresh must it be?

Data Studio connects natively to GA4, Google Ads, Search Console, Sheets, BigQuery, YouTube, Campaign Manager 360, Display and Video 360, Ad Manager, Cloud SQL, MySQL, PostgreSQL, SQL Server and Redshift. Partner connectors from vendors such as Supermetrics, Windsor.ai, Porter Metrics, Funnel, Power My Analytics and Catchr cover hundreds of common platforms for a monthly fee. A custom build only makes sense where neither covers your source, or where the vendor cannot shape the data the way your reports need.

What can a community connector connect to?

Almost anything reachable over the internet. Google's documentation names four routes: web APIs, JDBC databases, flat files in CSV, JSON or XML, and other Apps Script services. In practice the requests I see fall into three groups.

The first is an in-house system with an API, such as an order platform, a booking engine or a policy administration tool. The second is a niche SaaS product that the big connector vendors do not support. The third is a product company that wants its own customers to report on its data in Data Studio, which is the case where publishing the connector publicly makes sense.

• Internal REST APIs with key or token authentication.
• Industry SaaS tools with an API but no partner connector.
• Databases reachable through JDBC that the native connectors do not cover.
• Hosted CSV, JSON or XML files that update on a schedule.

How is a Data Studio custom connector built, step by step?

The build itself is the smaller part. Most of the effort sits in agreeing the fields, handling the source's quirks and testing against numbers the business already trusts. This is the sequence I follow.

• Scope: list the reports the connector feeds, every field they need, its type, and the totals to reconcile against.
• API review: authentication method, pagination, rate limits, date filtering and how far back history goes.
• Auth: pick the matching auth type and store credentials in user properties, with clear errors when a key expires.
• Config and schema: define the settings users choose and a typed schema, with dimensions and metrics named the way your team talks.
• getData: fetch only the requested fields and date range, page through results, and map them to the schema.
• Caching: store recent responses so repeated chart loads do not call the API again.
• Errors: return readable messages instead of a blank chart, because Data Studio gives no warning when a connector breaks.
• Deploy and test: create a versioned deployment, connect it in a test report, reconcile totals, then share it with your team.
• Handover: code in your own Google account, a short document of fields and limits, and a walkthrough.

What limits should you plan for before building a connector?

Apps Script quotas set the ceiling, so check them against your data volume first. The figures below come from Google's Apps Script quotas page and Cache service reference, both read in October 2026. The URL Fetch figure is per day for the account running the script, which matters when many viewers open a report at once.

Data Studio's own limits still apply on top. Blends hold up to 5 data sources with equality joins only, and very large queries return too many rows errors. A connector does not lift either limit.

Why are custom connectors slow, and how do you keep them fast?

Each request for data runs Apps Script before your source is even asked, and pages with many charts and many viewers make many requests. In a July 2025 thread on Google's developer forum (discuss.google.dev, titled Custom Connectors Very Slow), a developer reported that charts took more than 10 seconds to render even when the connector returned a tiny hardcoded result, and the thread had no solution posted. That matches what I see: overhead per call, multiplied by charts per page.

The fixes are mostly design decisions rather than clever code. Fewer charts per page, filters that narrow the request, and responses aggregated before they reach Data Studio all help. Where the data is large or the API is slow, the better answer is to load it into BigQuery on a schedule and point Data Studio at a partitioned table, which removes Apps Script from the viewing path entirely.

• Return only the fields and date range the chart requested.
• Aggregate in the API or in a cache layer, not row by row in Data Studio.
• Cache per user and per query so repeat visits do not hit the API.
• Keep pages to the charts people actually read.
• Move to a scheduled BigQuery load once volume or viewer count grows.

Should the connector stay private or be published in the gallery?

Keep it private if it reads your own company's data. Google's documentation confirms a connector can be shared directly with any user, which is all an internal reporting team needs, and it avoids a review process built for public products.

Publish it if you are a software company and want customers to report on your data. Google's partner connector requirements are specific: a Production deployment, view access shared with Google's review addresses, a hosted page on your own domain with a privacy policy and terms of use, a support page rather than an email link, a logo hosted under your control, explicit OAuth scopes, completed OAuth client verification, and a connector that is finished rather than in beta. Budget time for that review on top of the build.

How much does a Data Studio custom connector cost?

The build is the main cost, and running costs are usually small. Apps Script itself has no licence fee within the quotas above, and Data Studio is free for creators and viewers. Data Studio Pro, at $9 per user per project per month, is only needed if your team wants Pro workspaces and organisation-owned content, not to use a connector.

What moves the build price is the source, not the charts. An API with key authentication, clean JSON and a date filter is a modest job. OAuth, deep pagination, inconsistent field names, missing history or strict rate limits each add work, and a gallery submission adds more. For context, rates published by agencies such as halo-lab.com put freelance Data Studio consultants at roughly $100 to $200 per hour, though a fixed price against a written scope is easier to compare.

Do the comparison honestly. If a partner connector already covers your platform, its subscription is often cheaper than building and maintaining your own code, and I will say so in the review.

Common mistakes, and when not to build a custom connector

Most failed connector projects share the same causes, and none of them is the code. They are scoping and ownership problems that show up months later, usually when someone leaves or the source API changes.

Sometimes the right answer is no connector at all. For an Australian insurance brokerage that received messy .xls files from several insurers, a project I led at Greenwolf Tech Labs automated the files into Google Drive, mapped them into a central Google Sheet with business rules applied, and fed the dashboard from there. Report preparation fell from 4 to 5 hours to under 5 minutes, and reporting accuracy rose from about 75% to 99%. A connector would not have fixed those files; a pipeline did.

• Building for a platform that a partner connector already supports.
• Fetching raw rows and aggregating in Data Studio, which hits quotas fast.
• Leaving the script in a contractor's personal account.
• Putting API keys in configuration fields instead of user properties.
• Skipping reconciliation, so nobody trusts the first report.
• Do not build one when the source is a file export, the data is very large, or nobody will maintain the code after launch.

How I work on connector projects

You work with me directly, from the first review to the handover. I start by reading your API documentation or a sample export and the reports you want, then recommend the cheapest route that will hold up: a partner connector, a custom connector, or a Sheets or BigQuery pipeline. You get a fixed quote for that route after a free review, with running costs listed separately.

The code, deployments and data sources live in your Google account from day one, so nothing depends on me staying involved. If the connector feeds a new dashboard, I build that too, and if an existing report broke after a source change, I can repair it instead.