How should I decide up front which credentials (API keys, usernames, passwords) to collect for a cloud skill workflow, assuming I have a basic workflow skeleton?
We cover this in Maker School, but here's a high‑level overview: if your cloud skill needs API X, you need access to API X. When building cloud workflows, you often create another workflow that extracts the specific platforms of interest, and that's what you require from the client. You don't need to do this up front or at the end—you can't build a system and then declare it ready to go live, because the whole thing is assembled with natural language in 30 seconds. Without a live version you can't test, which is the top reason developers are hated ('it worked fine over here'). Once you have API keys, things change, so allow some time. Get everything up front. Preferably use username/email and password; avoid OAuth Google sign‑in because it triggers constant 2FA requests from the original account owner. It's kind of annoying.
I'll do what's called a kickoff call where I get them together with me for a 30 to 45 minute period. I'll guide them through signing up for all the software platforms I want them to use. Typically I have three or four software platforms they need to sign up for. Most of the time, if we're doing something email-related, I'll have them sign up for a new Google Workspace profile. If they've never used a no-code platform, I'll make them sign up using my affiliate code—often something like PandaDoc. So I pretty much define sign‑up procedures for this: I send them all the links in the chat, they click the buttons, create the account, and then I have them do it with email and password so I can get it immediately and verify sign‑in right there. The issue with two‑factor authentication for most services is that people sign up using Google, which forces them through Google’s TFA system—a pain. If you get username‑password credentials, just add them to a password manager like 1Password, LastPass, or Dashlane; that eliminates a large portion of that issue. For the Google stuff, I typically log in using a software platform called Multi‑Login (multilogin). It’s great because you basically have to store the exact same credentials. Essentially this lets you set up dedicated browser profiles using residential and data‑center proxies so you can consistently log in with a static IP—the same IP address every time—minimizing the number of re‑authentications you need. Yeah, I use this for Google stuff from time to time; I don’t always use it, but that’s how I solve that problem. Hope that makes sense. If you guys have any more questions, feel free to drop them in the daily updates channel. Obviously this incentivizes my channel to grow because I get more engagement, and I can answer questions I get on this channel for the foreseeable future until it becomes unreasonable to do so.
I don’t actually sell these AI agents myself; I don’t find them super valuable right now. I don’t think they’re more valuable than a traditional linear left‑to‑right automation, and the agency aspect doesn’t make my clients’ lives better or solve a unique problem I couldn’t just build easier with a linear flow. In general, what you should do is first try to sell the thing before you’ve built it. Go out, hear what people have to say, learn their pain points and what they want, and assemble enough validation or proof that the service is in demand. Only then should you actually go about building it. AI agents are a bit special because they’re very easy to set up—you literally just drag and drop an agent node and say a couple of magic words and it works about 80 % of the time. If you’ve already built it, I get it, but for future reference, sell first. When you sell it, tell them your goal is to make the process as easy as humanly possible, that you don’t want to lock them into anything, and you want to give them maximum freedom and autonomy. Walk them through setting up NADN (the no‑code drag‑and‑drop platform I used) on their account. Have them sign up with their credentials, then use those credentials to access the account—this makes handoff easy if they later choose not to work with you. It also makes managing everything simple and gives them total control, which I think is fundamentally important. Have them sign up for the cloud plan, don’t self‑host, and run the NNA agent on that cloud plan for them. On the kickoff call, make sure you get all credentials, handle any two‑factor authentication, and take care of Google console access if needed (with make.com you just need Google account access). When you do the implementation, hold their hands: make them open the browser, open NADN, sign up, and then get the username and password. Ensure any accounts you use for this purpose aren’t created with OOTH, otherwise you’ll have Google‑based 2FA, which is a pain. Confirm they can sign in, then you’re building it all on their account. Don’t sweat the building before you sell—sell first, then build after.
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.
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.