If I am reading this correctly much of your question surrounds whether or not you want your client to be connected to your OpenAI account and you want it credentialed. My best suggestion is to see about having you onboarded to your clients accounts as your own user. They can setup their own project for you and you can connect Make to that and complete the verification.
It’s actually quite a common situation when trying to move from “it works in testing” to “it’s working for a paying client.”
On GCP OAuth verification: due to the mail.google.com scope, you need to pass through verification, as Google considers this scope to be sensitive. The good news is that your setup will stay fully operational until the moment while you’ve already added the client as a test user (that’s standard procedure and is not considered a hack).
If the client uses Google Workspace: if the GCP project is created and belongs to the client’s workspace, and OAuth consent screen is “Internal” user type, then Google verification is completely omitted regardless of whether it’s a sensitive scope or not. That only applies to the internal apps, used only within the organization and fits your case, as the client is the only user.
Regarding the account structure: always use the client’s Google Workspace account to create the GCP project and OAuth credentials. This allows you to get the internal app exemption above and additionally protects both of you in case something goes wrong between you two.
Organization structure for Make account: always have each client go through their own Make account or organization instead of using just one personal Make account for all clients. It keeps credentials, billing, and access cleanly separated as you take on more clients.
Realistic time frame: normally it takes a day or two to build the setup like yours. If the client has Google Workspace and you decide to go for an internal app, then it takes the same amount of time, as you don’t need to wait for Google verification process. Without Google Workspace it will take 2-6 weeks, and meanwhile you can keep the client as a test user.
What would I tell my past self? Would ask upfront if the client has Google Workspace, as that changes everything completely.
Thanks, this really clarified things for me. One follow-up I’m still trying to nail down:
You mentioned to always use the client’s Workspace account for the GCP project to get the Internal exemption — but what’s the recommended approach when a client has a legitimate business but not Google Workspace (e.g., their business email runs through Microsoft 365, or they just use a personal Gmail for everything)? In my experience that seems pretty common, especially for smaller clients.
In that situation, is the standard move to:
Recommend they pick up a cheap Workspace plan just to unlock Internal mode (even if they don’t otherwise need it for email)?
Just go through External + verification and eat the wait, keeping them as a test user in the meantime?
Something else you’ve found works better in practice?
Also curious — for non-sensitive/lighter scopes (like basic Sheets or Forms access, as opposed to full Gmail), have you found you can usually skip straight to “In Production” without a heavy review, since the 7-day test-token refresh issue seems to apply purely based on Testing status, not scope sensitivity? Trying to figure out whether it’s worth pushing for Production fast even for small/simple automations rather than living in Testing indefinitely.
Appreciate the detailed answer, this is exactly the kind of practical detail that doesn’t show up in the docs.
Great questions, indeed, the type of considerations one encounters constantly when dealing with real-life clients.
For clients without Workspace, in practice, option 1 becomes rather unfeasible - essentially, you would be asking them to purchase and administrate an entirely different platform to implement a technical solution that would save you time. On the other hand, option 2 would be my preferred approach - make them a test user while submitting for verification and simply communicate from the get-go that the process is expected to take 2-6 weeks in total. Usually, that would be acceptable to small clients once they understand that it’s a Google-only requirement.
One thing to consider in regard to your option 1 – even if they do have Workspace, Internal exemption is only possible if every single person who will use the app will belong to their organization within the workspace. If you as the developer authenticate within the OAuth consent process via your personal Google account, it would violate the internal exemption conditions, so, it is only possible if everyone uses their domain-based email address within the flow.
Regarding your production question, indeed, the 7-day expiration period is applicable specifically to Testing status, not to scope sensitivity. Thus, theoretically, you may push the app directly to production regardless of scopes used, although in practice you should be aware of consequences of such action. The catch is that if your scopes include anything sensitive or restricted, like full Gmail access, publishing to Production without completing verification first will trigger the “unverified app” warning screen for every user, not just test users, since the cap and warning are separate mechanisms from the token expiry.
Therefore, if you’re working on light scopes like Sheets, Forms or any other non-sensitive scope, you may safely push the app directly to production as soon as it’s ready, skipping verification altogether and saving your users from test account requirement. On the other hand, if you’re using Gmail and sensitive scopes, early publishing will result in changing 7-day limitation problem to a permanent pop-up screen problem.
If this clears things up for you, marking it as the solution would help others hitting the same Workspace/verification questions find it faster.
The Internal exemption catch is something I completely missed — the fact that even the developer needs to authenticate using the client’s domain email, not a personal Gmail, is the kind of detail that would have broken my setup without me understanding why. Really important to know upfront.
And the distinction between the two separate problems (7-day expiry from Testing status vs unverified warning from sensitive scopes in Production) finally makes it click. So for Gmail specifically, verification isn’t optional if you want a clean experience — you’re just choosing which pain to live with until it clears.
For lighter scopes like Sheets and Forms, pushing straight to Production and skipping verification entirely is clearly the move. No reason to sit in Testing and deal with the weekly re-auth when Production is immediately available for non-sensitive scopes.
Marking this as the solution — this is exactly the practical breakdown that should be in the docs but isn’t. Appreciate the time you put into this.
That part about the developer account breaking the internal exemption is a lifesaver. I was literally about to test a client’s flow using my own personal Gmail login, which would have messed up the whole setup.
Since option 2 is the only way here, how do you usually handle the client access during those 2-6 weeks of verification? Do you just ask them to reauthenticate their connection every 7 days when the token expires, or is there a way to automate the refresh token renewal while the app is still in testing?
What is your goal?
What is the problem & what have you tried?
Error messages or input/output bundles
Create public scenario page