What is an API key, and who should hold it?

What it is, in plain words

Think of a hotel key card. The front desk gives it to you so you can open certain doors without asking every time. The card only opens the doors it was set up for. It stops working on a certain date. The desk can cancel it at any moment. And anything charged with it goes to the room it belongs to.

An API key is that card for software. When your automation needs to use another app (send an email, read a spreadsheet, ask an AI model a question, upload a file), that app wants to know who is asking. The key is the answer. Your automation shows it with every request, and the app lets it in.

You will hear a few related names. They are not identical, but for a buyer they raise the same questions:

• API key: a long string of letters and numbers, usually created on a settings page of the app.
• Access token: similar, often issued after you log in and approve access, and more likely to expire.
• Credentials or secrets: the general word for all of these.

A concrete example

I run a scheduled publishing job. Before it can publish a post, it uploads the images and video to a code-hosting service, and that upload step uses an access token.

In September that token stopped being accepted. Every upload was refused, five publishing slots in a row came up empty over two days, and every scheduled run still reported success. A separate backup job used the same token, so it stopped too. The full story is in the field note my scheduled posts stopped for two days, and every job reported success.

A second case from the same pipeline: a job that published one chosen post at a set time worked when I ran it by hand but not when the scheduler ran it. The keys were kept in a settings file that my manual runs loaded and the scheduled run did not. So the key was simply empty when nobody was watching, and the job failed quietly. The fix was to load the file inside the job itself, plus a test mode that prints whether the account and key are present before anything is scheduled.

Neither problem was in the automation’s logic. Both were about the key: where it lives, and what happens when it is missing or no longer valid.

Why it matters when you hire someone

You will not create most keys yourself, but three things about them decide whether you stay in control of what you paid for.

1. The key decides who owns the automation. If the automation runs on a key from the freelancer’s account, it works only as long as their account, card and goodwill last. If it runs on yours, you can hand it to the next person. The acceptance checklist for unattended automations makes this its last check for that reason.

2. The key decides who pays. Many APIs, and all AI models, bill per use. The bill goes to the account that owns the key. On your account, you see the real running cost. On theirs, you see an invoice, or nothing until it stops.

3. Keys expire and get revoked. Some last for months, some for days, some until someone cancels them. When one stops working, every step that needs it fails. That is the most common silent failure in delegated automation, and the reason credentials with expiry dates belong in the maintenance terms.

There is also a safety point. Anyone who has the key can act as you, within what the key allows. A key pasted into a chat message, an email or the code itself is a key that can leak.

What to ask the freelancer

Paste these into your first message, or into the “Inputs” and “Handover” fields of the workflow automation brief:

A good answer is a short list: key, app, what it may do, where it lives, when it expires. Keep that list. When something stops, it is usually the first place to look.