Who should own the accounts and API keys when a freelancer builds your automation

The short answer

Create every account the automation depends on yourself, before the build starts, and give the freelancer access you can remove. That means the automation platform, the AI provider, the email sender, the code repository, the hosting and the domain. The freelancer builds inside your accounts; they do not bring their own.

The workflow itself is the easy part to hand over. It is a file or an export. The accounts behind it are what decide whether you can keep it running, see what it costs and give it to someone else. If one of them is in the freelancer’s name, you have not bought an automation. You have rented one.

Why the accounts matter more than the workflow

An automation is a set of permissions as much as a set of steps. Each step works because some account said yes: the platform runs it, the AI provider answers, the mailbox sends, the storage accepts the file. Whoever owns those accounts decides whether it keeps working.

Three things follow from that:

• Continuity. If the automation runs on the freelancer’s platform subscription or their API key, it stops the day their card expires, they close the account or they move on.
• Cost. Usage is billed to the account that owns the key. On your account you see the real monthly cost. On theirs you see an invoice, if anything.
• Proof. Sometimes you will need to show that something is yours. When I applied to the affiliate program this site uses, they asked me to prove I owned the site. What settled it was a screen from the domain registrar showing the domain active in my account, with its expiry date. If a freelancer had registered it in their name, I would have had nothing to show.

The same automation, two kinds of ownership

What happens later depends on whose name is on the accounts behind it.

Built on the freelancer's accounts

Their platform plan→Their API key→Their invoice, if any→Stops when their account does

Built on your accounts, with access you can remove

Your platform plan→Your API key→Your real usage bill→Hand it to anyone ✓

The inventory: every account, and who creates it

Copy this table into your notes before you order, and fill in the last column as the project goes on.

Account	Who creates it	Freelancer gets	How you take it back
Automation platform (n8n, Make, Zapier)	You	Invited as a member or editor	Remove the member
AI provider (for chatbots and AI steps)	You, with your card	A key you created, limited where possible	Delete the key, make a new one
Email sender, SMS, messaging bots	You	A key or token you created	Replace the key or token
Spreadsheets, CRM, forms the job reads	You (usually exist already)	Shared access to what the job needs	Remove sharing
Code repository (if there is code)	You	Collaborator access	Remove the collaborator
Hosting or server	You	A user account, not your login	Delete that user
Domain and DNS	You, always	Usually nothing; you add records they send	Nothing to take back
Webhook registrations in other apps	Created in your apps	Temporary access while setting up	Check the webhook points to your platform

Two rows buyers forget. The domain: if a site or email address is part of the job, register the domain yourself, even if it is the only thing you do yourself. Webhooks: they are registered inside the sending app and point to an address. Make sure that address belongs to your platform, not the freelancer’s server. The webhook explainer covers what else to ask about them.

Shared keys: one login, several jobs

Keys spread. One token ends up used by two or three jobs, and nobody wrote that down.

It happened to me. A token that my publishing job uses to upload images to a code-hosting service stopped being accepted. Five publishing slots in a row came up empty over two days. A separate job that backs up my files used the same token, so it stopped too, and four backups were waiting when I found it. Every scheduled task still reported success the whole time (the full incident).

So ask for a credential list at hand-over, one line per key or login:

• which app it belongs to, and which account
• which jobs use it
• what it is allowed to do
• when it expires, if it does

That list turns “three things broke” into “one token expired”. It is also the list you use to replace keys after the freelancer leaves.

What to do on day one, during the build and at hand-over

Step 6 doubles as a test. If the automation breaks when you swap a key, something was hard-coded somewhere, and it is better to find that before final payment than after. The acceptance checklist includes a revoked-key run for the same reason.

If you want ongoing help

Removing access does not mean ending the relationship. If you agree maintenance, the freelancer keeps access, but on your accounts, as a named user you can remove. That is one of the six lines in putting maintenance in the contract: access stays on your side, and is written down.

For AI steps and chatbots, there is one more reason to keep the provider account yours: the running cost. Usage is billed per request, so the key on your card is how you learn what each conversation or run costs, and how you notice when that changes.

Where it goes wrong anyway

• The freelancer builds a prototype on their account “to save time”. Fine for a demo. Agree in writing that it moves to your accounts before acceptance, and that the move is part of the price.
• An account was created with their email. Change the owner email to yours before acceptance, not after they have moved on.
• A key is inside the code. Ask for it to be moved to settings or a credential store, then replace the key.
• You never logged in yourself. Log in to every account on the list once before you pay. An account you cannot open is not yours in practice.

Wrap-up

The workflow is the visible part of the job. The accounts are what you actually own. Create them first, give access you can take back, collect a list of every key and what uses it, and replace the keys when the build is done. Then the automation keeps running whoever you work with next.