Jordan: You should never know your client's password. Not their Google password. Not their HubSpot password. Not the API key to their Stripe account. None of it. And if you're storing that stuff — in a shared doc, in a Slack DM, in a sticky note screenshot somebody texted you at eleven PM — you are one breach away from a lawsuit you cannot afford.
I used to do this. I had a Google Doc called "Client Logins." Passwords in plain text. Shared with a link. No expiration. I look back at that and I genuinely cannot believe nothing went wrong.
But here's the part that actually matters — you don't need any of it anymore. Make shipped a feature in February called Credential Requests. Your client gets a secure link. They click it, they authorize their own apps, and you get the connection without ever seeing a password. They can revoke it anytime. You can tear it down when the project ends. And the whole authorization flow — tracking who's done, nudging who hasn't, logging everything for compliance — that's automatable too.
Today I'm building the entire system live.
Jordan: This is Headcount Zero. I'm Jordan. And today you're walking away with a complete credential intake system — Make Credential Requests generating secure links per app, a Notion tracker that shows you exactly who's authorized and who's stalling, and auto-nudges at twenty-four and seventy-two hours so you never have to send another "hey, did you get a chance to connect your Google account" email again. Plus the teardown flow that revokes everything clean when the project ends. Fifteen minutes. Let's build it.
Jordan: So let me set the scene for why this matters right now. Last month I onboarded a new client — e-commerce brand, needed me to connect their Google Ads, their Shopify, their Klaviyo, and their Slack workspace. Four apps. The old way? They'd screenshot their login pages, paste passwords into a Slack DM, and I'd manually log in and create the connections. Maybe they'd email me an API key with the subject line "here's the key" — no encryption, no expiration, sitting in both our inboxes forever.
That's not just sloppy. That's a liability. If my email gets compromised, every client credential I've ever received is exposed. And as a solo operator, I don't have a security team. I don't have cyber insurance that covers client credential breaches. It's just me.
So when Make launched Credential Requests on February tenth, I rebuilt my entire intake flow in an afternoon. And I want to walk you through exactly what I built, because the security improvement is only half the story. The operational improvement — knowing who's authorized, who's dragging their feet, and automatically nudging them — that's what actually changed my onboarding speed.
Jordan: First thing to know — and I need to be upfront about this — sending Credential Requests requires either a Make Enterprise plan or official Make Partner access. If you're on a Pro or Teams plan, you cannot send these yet. You can receive them on any plan, but sending is gated. If you're a working automation consultant doing client work on Make, the Partner program is worth pursuing for this feature alone. I'll leave it at that.
Jordan: Okay. Assuming you have access, here's where the feature lives. Left sidebar in Make, click Credentials, then the Credential Requests tab. You'll see two subtabs — Sent and Received. Sent is your view as the requester. That's where you'll work.
Now, you could create requests manually from this UI. Click the button, fill in the client's email, pick the apps, send. But we're not doing that. We're automating it, because if you're onboarding three or four clients a month with four or five apps each, that's fifteen to twenty manual requests. And each one needs tracking.
Jordan: So here's the architecture. Four scenarios in Make, plus a Notion database that ties everything together.
The Notion database is your command center. I call mine "Credential Intake." The key fields are Client, Project, App — like Gmail or Slack or HubSpot — Request Link, Request ID, Status, Owner, Last Nudge timestamp, Nudge Count, and a formula field called Next Nudge At that calculates when the next reminder should fire. There's also an SLA Breach formula — if a request has been pending for more than seventy-two hours, it flags automatically.
Jordan: The first scenario handles request creation. You trigger it manually or from a Notion button when a new project kicks off. It iterates through a list of apps the client needs to authorize — say Google Drive, Slack, and HubSpot — and for each one, it hits Make's Credential Requests API. That's a POST to the V2 endpoint. You send the client's email, the app you need, the scopes you're requesting, and a label like "Project Name — Google Drive." The API returns a request ID and a secure link. Your scenario writes both to a new row in the Notion database with status set to Pending.
Your client gets an email from Make with that secure link. They click it, they authenticate with their own credentials through OAuth, and Make creates the connection in your org. The client joins as a Guest — and this is important — a Guest with extremely limited scope. They can only view, authorize, revoke, or delete their own credentials. They cannot see your scenarios, your other connections, your other clients. Nothing.
Jordan: Now here's the operational nuance that the docs don't emphasize enough. There is no webhook for when a client completes authorization. Make doesn't fire an event you can listen for. So you need a watcher.
Scenario two is that watcher. It runs on a schedule — I use every fifteen minutes, but you could do every thirty if you want to conserve operations. It pulls every Notion row where status is not Authorized, not Declined, not Revoked, grabs the Request ID, and hits the GET endpoint on Make's API to check the current status. The API returns one of six statuses — pending, partially authorized, authorized, declined, invalid, or incomplete. Your scenario maps that status back to the Notion row and updates it. When a request flips to authorized, it timestamps the Authorized At field and captures the Credential ID — you'll need that later for teardown.
Jordan: Scenario three is the nudge engine. This runs hourly. It queries the Notion "Due for Nudge" view — any row where Next Nudge At is in the past and status is still Pending or Partially Authorized. For each one, it sends a message. I use Slack for clients who are already in a shared channel, email for everyone else. The first nudge at twenty-four hours is gentle — "quick reminder to authorize Google Drive for the project, here's the secure link." The seventy-two-hour nudge escalates — it mentions me by name, optionally CCs the client's project sponsor, and adds urgency. After each nudge, the scenario updates Last Nudge and increments Nudge Count. The Next Nudge At formula recalculates automatically.
I had a client last month — authorized three of four apps within an hour. The fourth one, Slack, sat at Pending for five days. Turns out their IT team had to approve the OAuth scope. The auto-nudges kept the conversation alive without me sending a single manual message. On day five, the IT admin clicked the link and authorized. My Notion board updated. I never had to chase it.
Jordan: Okay, scenario four — and this is the one most people skip, which is exactly why I'm spending time on it. Teardown.
When a project ends, you need to revoke the client's credentials. Not "should." Need. Leaving active OAuth tokens connected to a former client's Google account is a security risk you do not want to carry. Make gives you an API endpoint for this — POST to delete-remote on the credential ID. It removes the remote credential and resets the request status to Pending. Your scenario finds every Notion row for that project where status is Authorized, calls delete-remote on each one, and marks the row as Revoked with a timestamp.
If you skip this step, six months from now you'll have stale tokens connected to clients you haven't worked with in half a year. And if one of those tokens gets compromised — through no fault of yours — you're still in the blast radius because the connection lives in your Make org.
The reauthorization flow is the inverse. If a client's OAuth token expires mid-project — and they do, especially with Google — you hit the request-reauthorize endpoint on that credential ID. It transitions the status back to Pending, the client gets a new authorization prompt, and your watcher picks up the change when they complete it. No new request needed. No new Notion row. Same tracking, same nudges.
Jordan: Now — not every app supports OAuth through Make. Some tools only have API keys. Some have custom auth that Make doesn't have a connector for. You still need a secure path for those.
The answer is not email. Do not email API keys. Do not paste them in Slack. Do not put them in a shared Google Doc.
Use a password manager's secure sharing feature. 1Password lets you generate a time-limited share link for any vault item — even if the recipient doesn't use 1Password. Bitwarden Send does the same thing with encrypted, expiring links and an optional passphrase. Send the link through one channel, send the passphrase through a different channel. The client puts the secret in the share, you retrieve it, configure the connection in Make, and then immediately rotate the key in the client's system. The old key is dead. The share link is expired. The only copy of the live key exists in the client's own vault and in your Make connection.
At project end, you rotate again, delete the Make connection, and document the revocation in Notion. Same teardown discipline as the OAuth flow.
Jordan: Okay. I know what some of you are thinking. "Jordan, this requires Enterprise or Partner access. I'm on a Pro plan. This doesn't apply to me."
Fair. The gating is real. But here's my honest take — if you're doing client work on Make, the Partner program is the path you should be on anyway. It unlocks Credential Requests, it gives you better support, and it signals to clients that you're a vetted professional, not someone who learned Make from YouTube last week. The application process takes time, but it's worth starting now even if you can't use Credential Requests today.
And if you're not on Make at all — if you're on Zapier or n8n — the secure sharing fallback with 1Password or Bitwarden Send still applies. The principle is the same: never handle passwords directly, always use expiring links, always rotate after use, always revoke at project end. The Make-specific automation just makes the tracking and nudging automatic.
The other objection I hear is clients being uncomfortable joining your Make org as a Guest. And I get it — "join my organization" sounds like a big ask. But the Guest role is genuinely limited. They can manage their own credentials and nothing else. They can't see your scenarios, your data, your other clients. I explain this in the initial email, and in roughly forty onboardings using this system, I've had exactly one client push back. Their legal team reviewed the Guest permissions, confirmed the scope, and approved it in two days.
Jordan: One more layer for those of you on Enterprise plans or working with enterprise clients. Make's Audit Logs capture every Credential Request event — created, authorized, deleted — plus two-factor authentication enforcement changes. These logs are retained for twelve months at both the Organization and Team level. If your client's compliance team asks "can you prove when access was granted and when it was revoked," you can pull that from the audit log with exact timestamps.
You can also enforce two-factor authentication org-wide from your Organization settings. One caveat — if your org uses SSO through an identity provider, the two-FA enforcement has to happen at the provider level, not in Make. Make's enforcement only applies to native Make authentication.
For most solo operators, the audit logs are overkill. But if you're landing enterprise contracts — and some of you are — this is the kind of security posture that gets you past procurement. It's the difference between "we use Make" and "we have a documented, auditable credential lifecycle with enforced two-FA and automatic revocation." That second sentence wins deals.
Jordan: So let's bring this back to where we started. That Google Doc I used to keep — "Client Logins," passwords in plain text, shared with a link. That doc represented every bad habit solo operators fall into when they're moving fast and don't have a system. Credential Requests replace that entire pattern with something that's actually secure, trackable, and — once you build the four scenarios — completely hands-off.
The thing I want you to take away isn't just the technical build. It's the principle. You should never be the person holding your client's passwords. Not because you're untrustworthy — because the moment you hold them, you own the risk. Credential Requests let the client own their own authorization. They click, they authenticate, they can revoke anytime. You get the connection you need without the liability you don't.
If you want to ship this today, I put together the full Client Credential Intake System — the Make blueprint for all four scenarios plus the Notion database with the formulas, the SLA views, everything. It's on the Resources page. Import the blueprint, duplicate the Notion database, paste your API token, and you're live. Roughly twenty minutes if you already have Partner or Enterprise access.
One thing to do this week. Go check your current credential handling. Open your Slack DMs, search your email for "password" or "API key." If you find client secrets sitting in plain text — and you probably will — that's your sign. Replace that with this system or something like it. The build takes an afternoon. The risk you're eliminating is permanent.
That's it for today. I'm Jordan. This is Headcount Zero — proven builds you can ship solo. See you Wednesday.