> ## 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 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](https://developers.google.com/workspace/preview) 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 | 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 |