Do clients always accept giving you their credentials (email/password or API keys) when you set up automation for them?
I never give my own credentials to others. When you ask if clients use their API keys on their account, yes—they do. Do they always accept giving me their credentials? No, not everyone does, but the vast majority do. I think this happens because I frame it matter‑of‑factly; I don’t make it a big deal. It’s simply how the service works: you give me your email and password (make sure it’s unique), I log in, set everything up, and then manage everything end‑to‑end. That’s the expectation. I don’t even mention it because it’s obvious to me, and I’ve rarely had issues. Occasionally a technical client prefers to give me their API keys instead, which works just as well since API keys grant the same authorization—I can do everything through the API without logging into their account. Logically, if they give me API keys, I can accomplish the same tasks. I’ve always assumed that if someone hires me for a technical purpose, they’ll accept sharing credentials because otherwise there’s no point. Of course there are exceptions: some platforms let you delegate sub‑accounts, and many are built exactly for that. In short, the simplest approach is to have the client provide a user password and then grant full access in one go.
Clients provide their login credentials. I run a kickoff call SOP where I ask them for all their logins, which I then use to set up the automations. I only use an API key if they’re comfortable sharing it, otherwise I work with their direct login.
You can ask for API access, but it’s essentially the same as having their credentials—full API access lets you do everything the password would. It’s a bit of intellectual dishonesty to claim otherwise. If you go the API route, you can query sent emails, but you’re still controlling their account. I don’t recommend it; it’s better to get the password during the kickoff call.
The reason I do this is twofold. First, it makes handoffs really easy. If you're no longer working with someone on this thing, you can say, 'Hey, you have everything you need. Here's the documentation on projects I've already delivered. Good to go. Goodbye. I love you. See you never.' Second, when you get people to sign up to these platforms, you can use your own affiliate link, which adds 3 to 5% to your margins almost immediately. That's how I do it—I don't have them deal with API keys or anything; I handle it all myself.
It depends on what you actually need. In some cases you need to pretend to be the client — for example if you're sending emails as them, from their domain, you need their Gmail credentials (or API creds), full stop. You'll need their username and password, or at least a service account with equivalent access, and in that case you really do need to be handed their credentials. But a lot of the time you don't need to impersonate them at all — you only need Google Workspace access. If all you need is something like Sheets or Drive, have the client create you a new account on their own domain (e.g. yourname@theirdomain.com) so you have your own login rather than theirs. Then, when you create an asset — a Sheet, a Drive file, whatever — Google Workspace lets you share it domain-wide instead of restricting it to just you: on the file's share settings, instead of "anyone with the link," you add the domain itself as a group, set the access level (viewer/commenter/writer), and now everyone at that domain — including the client — automatically has access to anything you create, no individual re-sharing needed. Most integration platforms' Google modules (Sheets, Drive, etc.) support creating that kind of share link directly. So the short version: only ask for their actual Gmail/email credentials when you genuinely need to send or receive email as them, or need a webhook listening on their inbox — for everything else, a domain account plus domain-wide sharing gets the job done without ever touching their real login. And yes, Google's 2FA is genuinely one of the more annoying parts of this to deal with.