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 takes about a week.
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.
Apply with a Workspace address. Google’s form rejects Gmail addresses,
service accounts and group addresses. This is the most common reason an
application comes back rejected.If you do not have a Workspace account, see below. Do not apply with a
Gmail address hoping it goes through.
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. Clause (iv) is the one to read: it prohibits sharing an integration
that uses preview features with your own customers before those features
launch generally.
The clause is about the act of sharing an integration. It does not turn on
where it is hosted or who owns the data, so running it yourself is not
automatically outside it. If you plan to put this in front of your own
customers rather than use it yourself, describe that in the form’s use-case
field and let Google answer 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 is the difference between
waiting a week and waiting two.
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