Developer Preview

The hub does not reach Gmail, Calendar and Drive on its own. It asks Google’s own servers for those, and Google keeps them closed to projects that have not been approved for its Developer Preview Program. Until your project is approved, the hub installs, runs, and looks completely healthy, and every tool call comes back refused. That is this gate, not anything you did wrong. Approval usually comes back within one working day. Apply in the morning and the email often arrives the same day or the next.

​

Apply from the installer

The installer has an Apply for the Developer Preview Program card. Use it rather than going to the form yourself: it fills in your project number and your address for you, so the two fields most likely to be wrong are already right. The card appears once your hub is deployed, because that is when your project number is known. So the order is: install first, apply second, and use the hub properly once approval lands. You are not waiting on us in between. Press Apply here and the form opens ready to submit. You still tick the terms box yourself.

​

Filling in the form

​

If you do not have a Workspace account

You do not have to go and buy one. Under the apply card there is Don’t have a Workspace account?. Send a request from there and we apply on your behalf after reviewing it. Your project number goes along with it automatically, and you can add a note if there is anything we should know. We reply by email.

​

Read the terms once

The Program Terms are short, and for almost everybody they come down to one line: If you are setting this up for yourself or your own team, carry on. If you are planning to put it in front of your own customers, say so in the form’s use-case field and let Google answer. The reason is clause (iv), which prohibits sharing an integration built on preview features with customers before those features launch generally. It turns on the act of sharing rather than on where the thing is hosted or who owns the data, so running your own copy does not automatically put you outside it.

​

After approval

Two emails arrive: one adding you to the program’s group, and one confirming your project is registered. Check spam, both come from Google. Then open your hub’s admin screen and press Refresh next to the schema status. While the gate was closed nothing could be registered, so there is nothing for Claude to call until you ask for that refresh once. This is not a redeploy and takes a moment. If the approval email arrived but things still fail, the usual cause is that the project you had approved is not the project you are using.

​

When you need a second project

Most people need one project. Check this only if the account you are connecting is a Workspace account. Google’s consent screen has one setting for the whole project, so a single project cannot hold both an Internal client and an External one. That is what forces a split, and only when the Workspace side has to be Internal:

• Your Workspace administrator blocks unverified apps. This is a common setting. If it is on, that account cannot consent to your own app at all, and only an administrator can allow it.
• You do not want people in your organization seeing the unverified warning. Internal has no warning.

If either applies, the Workspace side needs its own project and its own client, and that project needs approving too. The installer has a card for this, Does your Workspace org block unverified apps?, which sets up the second project and then gives you both project numbers in one line to paste into the application. Getting both numbers into your first application saves applying a second time and waiting again.

​

Why publishing matters more than verification

These two get mixed up, and it costs people a reconnect every seven days. A consent screen set to External with a publishing status of Testing issues sign-ins that expire in seven days. Both conditions have to be true, and verification has nothing to do with it. An unverified app stops expiring sign-ins the moment its publishing status is raised to production. So publish the consent screen. What you keep is the unverified warning at consent time and a cap on how many people can use it, neither of which matters for a hub you run for yourself.

​

If something goes wrong

​

Checking this yourself

The admin screen checks it for you now. Open Clients and any OAuth client whose project does not match the one your hub runs in gets a highlighted box naming both project numbers. This is a warning, not an error, so it never blocks adding the account or the client. Having a client in a different project is normal for the second-project case above. It only means something if that second project was never registered for Developer Preview: check the two numbers the box gives you against what you applied with. If you did not mean to use two projects at all, and the client simply came from the wrong one, replacing it is the fix rather than registering it. See connecting an account with the wrong OAuth client.

​

Turning the warning off

Once you have confirmed the second project is deliberate and both numbers are on your application, press This is what I meant on the warning. It stops appearing for that client, on the account page and in the hub’s own health check, and any account you attach to the same client later will not raise it again. Nothing is hidden by this. The Clients screen keeps showing both project numbers as a plain note, with Show the warning again beside it if you change your mind.