> ## Documentation Index
> Fetch the complete documentation index at: https://docs-hub.magicmealkits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Developer Preview
> Google gates the services this hub talks to. Read this if tool calls are refused, or before you apply.
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](https://developers.google.com/workspace/preview).
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.
**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](https://developers.google.com/workspace/preview) 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
| What you see | What it means |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| No reply a week after applying | Check spam first. Then contact [workspace-dpp-mod@google.com](mailto:workspace-dpp-mod@google.com) |
| The application was rejected | Almost always a Gmail address, a service account or a group address in the registered email field. Reapply with a Workspace address |
| Approved, but the hub still says permission denied | The approved project is not the one your account's credentials live in. Approval is per project, not per person |
| One account works, another does not | Same cause. That account's credentials belong to a project that was never registered |
| You tried to register a service account | Google does not accept them. Register the person's own project and have them sign in normally |
## 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.