fixmation.Get my quote
Make14 min readPublished September 2026

Make connects to Google, then the file picker returns 403

The connection is created, the authorisation succeeded, and the spreadsheet dropdown returns "Method doesn't allow unregistered callers". Five community threads carry that error over nine months and none has an answer from Make. The one-line test below tells you what is actually broken.

Why does the Make file picker return 403 when the connection succeeded?

The sequence is always the same. You build a custom Google OAuth client because Make asks for one, the authorisation screen appears, the connection is created, and then you click the field that lists your files:

I am using the Google Drive "Create a File from Text" module with a custom Google OAuth connection. Google authentication succeeds and the connection is created successfully. However, when I click "Click here to choose folder" in the module, the folder picker fails with a 403 error. I have also refreshed the connection and created a new connection with the same result.

The error text, which is worth reading closely because it is the whole clue:

[403] Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.

  • the same user, same thread, Make Community, 4 September 2026

The same string turns up on the Sheets side, where the field that fails is the spreadsheet name:

403: PERMISSION_DENIED - Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.

The Spreadsheet Name field also shows "Failed to load data!"

So the issue also occurs with Search Rows, not only Add a Row.

That last line matters. It is not one module misbehaving: the same reporter hit it on Add a Row and on Search Rows, and the Drive thread hit it on a folder field. The common factor is a field that wants to show you a list.

Does "unregistered callers" mean your permissions are wrong?

The instinct on seeing 403 PERMISSION_DENIED is to go back to Google Cloud and add scopes. That is the wrong direction, and Google's own documentation says so by showing what produces this exact sentence.

The string is not specific to Drive or Sheets. Google documents it for its API frontend, the layer that sits in front of Cloud Endpoints and API Gateway, and prints it in its own quickstarts as the expected result of calling an endpoint with no credential at all:

This should result in the following error: UNAUTHENTICATED:Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.

In that walkthrough the request is a bare URL with nothing attached, and adding ?key=API_KEY makes it succeed. Google's Endpoints troubleshooting page says the same thing about the same message:

ESP responds with the error, Method doesn't allow unregistered callers, when you have specified an API key in the security section in your OpenAPI document, but the request to your API doesn't have an API key assigned to a query parameter named key.

So in Google's own documentation the message is not about a user lacking access to a file. It is what Google returns when a request arrives with no API consumer identity attached, which is a different failure with a different fix.

What Google means by "API consumer identity"

Two different things identify a request, and Google keeps them separate:

API keys identify the calling project - the application or site - making the call to an API.

Authentication tokens identify a user - the person - that is using the app or site.

While API keys identify the calling project, they don't identify the calling user.

Your OAuth connection proves who you are. Google's own framing keeps that separate from the project identity an API key carries, and the error names the second of the two, not the first.

Read the error as "we do not know which application is asking" rather than "you are not allowed". Google's wording points that way, even though nobody has documented what Make sends. It redirects the investigation away from the scopes page, where most people spend the afternoon.

How do you tell whether the connection or only the picker is broken?

Before changing anything in Google Cloud, find out whether the connection works at all. Every list-backed field in Make can be typed into instead of picked from, and if the module runs with a typed ID, the connection was never the problem.

On Sheets modules the switch is a documented field:

Search Method - Select a method to choose the spreadsheet whose rows you want to watch. Search by path / Select from all / Enter manually

Spreadsheet ID - Select the Spreadsheet ID whose rows you want to watch. You can extract the Spreadsheet ID from the spreadsheet URL. For example, the URL is the following: https://docs.google.com/spreadsheets/d/abc1234567/edit#gid=0 where abc1234567 is the Spreadsheet ID.

Elsewhere it is the generic toggle:

For some parameters (mostly arrays with several fields that Make retrieves depending upon the selected connection) you can see a Map toggle. Switching on the Map toggle brings up a text field where you can map items from the preceding modules.

A member of the community put the diagnostic in one sentence, and it is the most useful sentence in any of these threads:

If the module works with the manual ID, the failure is limited to the browse/list path.

Run that test first. It takes half a minute, and it splits the problem into two very different jobs: a scenario that can ship today with typed IDs, or a connection that genuinely cannot read your files.

One caveat for Drive: the folder field on Create a File from Text has no documented Enter manually option. Make's own module reference describes it only as "Select the target location where you want to create the new file", so the map toggle is the escape hatch there.

Where the escape hatch lives, by module:

Where the 403 appearsThe field that failsTyped-ID escape hatch
Google Sheets - Watch Rows, Search Rows, Add a RowSpreadsheet Name, Sheet NameSearch Method set to Enter manually, then paste the ID from the URL
Google Drive - Create a File from Text"Click here to choose folder"No documented manual option, so use the Map toggle
Any list-backed parameter showing "Failed to load data!"The dropdown itselfMap toggle, then paste or map the ID from an earlier module

Do more scopes, a developer key or a new connection fix it?

"Add the missing scopes." The most complete report in the set had the textbook setup already: Sheets API and Drive API enabled, an external consent screen, a Web application client, the documented redirect URI, both scopes, his own account added as a test user, the client ID and secret in Make's advanced settings, and the connection recreated afterwards. The picker still returned 403. A community member suggested adding the read-only scopes with an explicit "most likely ... ?" - and no thread reports that fixing it.

"It is the Google Picker's developer key." Plausible, since the Picker does require both a token and a key:

The PickerBuilder takes a View, an OAuth 2.0 token, a developer key, and a callback function to call upon success (pickerCallback).

But the only key-related failure that page documents is a different message. Where it explains restricting a key to specific websites, it warns that leaving https://docs.google.com/* off the list "causes the Google Picker to display an 'API developer key is invalid' error". Nothing on the page ties a key problem to the sentence Make users see, so the tidy explanation is not supported either way.

"Recreate the connection." Everyone tries it. The first thread above records refreshing the connection and creating a new one, "with the same result". This is not the same failure as a connection that has genuinely expired, and treating it as one costs an hour.

Nobody at Make has explained this, and that is a finding

A search of the Make community for the error string returns five topics about a Google connection - September 2026, August, July, June, and one from December 2025 - plus an unrelated thread about an HTTP module. None of the five has a technical answer from Make. The people answering are other users, some carrying Community Champion titles, which is a community rank and not a vendor badge, and one of them says so plainly:

this is not an official Make support channel. This community is driven by users such as yourself, trying to help fellow makers.

Make's own help page for custom Google OAuth clients has a "Common problems" section listing eight Google errors - expired connections, redirect URI mismatch, invalid client, Access Not Configured, access denied in Testing status, Insufficient Permission, restricted scopes on a gmail.com account, and the 100-refresh-token limit. The unregistered-callers error is not one of them, and none of Make's Google-connection pages mentions an API key or the Picker API.

So here is the honest boundary of what can be said. Google documents that this message means a request arrived with no consumer identity. Make documents that typed IDs work. Put together, the parsimonious reading is that Make's list request reaches Google without something Google wants, and the read/write calls do not. Nobody - not Make, not Google, not the threads - has published that as the cause, and it is inference. Which is exactly why the manual test above beats any theory: it tells you what to do next without needing the mechanism.

The setup that is documented, and worth checking anyway

None of this is a reason to skip the parts Make does specify, and two of them catch real mistakes:

  1. Enable the right APIs in your Google Cloud project. Make's Sheets page says to search for the Google Sheets API and the Google Drive API - and then, in a copy-paste slip, tells you to "Click Gmail API, then click Enable". The Drive page gets the same step right, so it is a slip rather than a policy. Enable the two you actually need.
  2. Use the redirect URI for that specific app. Sheets and Drive do not share one. The Sheets page gives https://www.integromat.com/oauth/cb/google/, the Drive page gives https://www.integromat.com/oauth/cb/google-restricted. Make's page says it outright: "Each app, however, requires different Redirect URIs."
  3. Add both authorised domains, make.com and integromat.com.
  4. Move the consent screen out of Testing. Make's page is specific about the cost of leaving it there: "If you keep your project in the Testing status, you will be required to reauthorize your connection in Make every week."
  5. Add the scopes the app lists, which for Sheets are the spreadsheets and drive scopes, per Make's page.

A setup that satisfies all five and still cannot list files is the case this article is about. A setup that fails one of them has a different problem with a known fix, which is worth ruling out before concluding anything.

Is n8n affected the same way?

There is a similar report - a Google Sheets node where authentication succeeds and the document list returns 403, with the same manual-ID workaround - filed in January 2026 and closed as stale in March without a fix. It never quotes the unregistered-callers string, so it is the same shape rather than provably the same bug. If you are hitting this on n8n, the manual-ID test applies just as well; the diagnosis does not transfer.

How to get the scenario shipped today

  1. Switch the field to Enter manually or the map toggle and paste the ID from the URL. For Sheets that is the segment between /d/ and /edit.
  2. Run the module once. If it reads or writes, your connection and its scopes are fine and only the browse path is broken.
  3. Leave the typed ID in place for now. A hardcoded ID is a real dependency worth writing down, but it is a smaller problem than a scenario that cannot be built at all.
  4. Check the five documented setup points above, in that order. Wrong redirect URI and Testing status are the two that produce a slow-burning failure a week later.
  5. Open a ticket with Make Support, not the forum, if the manual ID also fails. Five unanswered threads is good evidence that the community route ends nowhere on this one.
  6. Note the date and the exact string in whatever you use to track it. When a vendor eventually documents this, the search that finds the fix will be for that string.

When this is a job to hand over

Typing an ID into a field is not a job for anyone else, and if that unblocks you, you are done.

It becomes a job when the scenario needs to pick files dynamically and cannot, when the same connection has to serve a client's Workspace domain and their admin is asking what you are enabling and why, or when you have already spent a day inside Google Cloud adding scopes at a message that was never about scopes. Those are bounded pieces of work with a known price, which is what Fix S and Fix M exist for. Make jobs we take are scoped for exactly this: something that authorises cleanly and still refuses to work.

Sources

  • Google Drive folder picker returns 403 unregistered callers - Make Community, 4 September 2026, read 6 September 2026. The symptom on a Drive module with a custom OAuth client, the verbatim error, and the map-manually workaround offered by another community member.
  • Google Sheets module returning 403 PERMISSION_DENIED error when selecting spreadsheet - Make Community, 3-5 September 2026, read 6 September 2026. The same shape of failure on the Sheets dropdown, reported without the unregistered-callers wording, and the browse-versus-manual diagnostic.
  • Google Sheets node: 403 error when loading Document list via OAuth2 - n8n on GitHub, opened 15 January 2026, closed 11 March 2026 as stale, read 6 September 2026. Authentication succeeds, the document list returns 403, the workaround is a pasted ID, and the unregistered-callers string never appears.
  • Google Sheets 403 permission denied - Make Community, 19-21 August 2026, read 6 September 2026. A complete custom OAuth setup that still fails, "Failed to load data!" in the field, the failure appearing on Search Rows as well, and the reminder that the forum is not an official support channel.
  • Quickstart: Secure traffic to a service with the Google Cloud console - Google Cloud API Gateway documentation, read 6 September 2026. The identical error string produced deliberately by a request carrying no credential.
  • Troubleshooting response errors - Google Cloud Endpoints documentation, read 6 September 2026. The same message described as the response when a request lacks the API key the API expects.
  • Why and when to use API keys - Google Cloud Endpoints documentation, read 6 September 2026. API keys identify the calling project; authentication tokens identify the user.
  • Integrate the Google Picker into web apps - Google Workspace documentation, updated 31 August 2026, read 6 September 2026. The Picker requires both an OAuth token and a developer key, and the documented symptom of a missing key is a different message.
  • Connect to Google services using a custom OAuth client - Make Help Center, updated 4 September 2026, read 6 September 2026. Which APIs to enable, authorised domains, app-specific redirect URIs, the weekly reauthorisation cost of Testing status, and a list of common Google errors that does not include this one.
  • Google Sheets modules and Google Drive modules - Make apps documentation, read 6 September 2026. The Enter manually search method and spreadsheet ID extraction, and the Drive folder field that offers no manual entry.
  • Module settings - Make Help Center, read 6 September 2026. The Map toggle as the documented way to type a value into a list-backed parameter.

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.