Security
API Keys vs OAuth: How Should an Automation Agency Get Client Access?
Use OAuth where the service offers it, it gives scoped, revocable access without handling a raw secret. Where only a raw API key exists, collect it through an end-to-end encrypted request. Here's how to decide, and why it matters for the keys you hold.
Use OAuth where the service offers it, because it grants scoped, revocable access and you never handle the client's raw secret. Where only a raw API key exists, collect it through an end-to-end encrypted request, not a Slack message. The two aren't rivals so much as a preference order: delegate with OAuth first, collect a raw key only when you must.
What each one actually is
OAuth lets the client authorise your agency or app to act on their behalf, and hands back a token scoped to specific permissions that the client can revoke at any time. The client never gives you their password or a master key. Much of the automation ecosystem has moved this way for exactly that reason.
A raw API key is a single long-lived credential, often with broad access, that the client copies and gives to you. It works everywhere OAuth isn't set up, legacy APIs, database credentials, service-account keys, but it's blunt: hard to scope, hard to rotate, and damaging if it leaks.
How they compare
| OAuth token | Raw API key | |
|---|---|---|
| Scoped to specific permissions? | Usually | Rarely |
| Revocable without breaking other access? | Yes | Often not |
| Client hands over a secret? | No | Yes |
| Available everywhere? | No | Yes |
| Right way to transfer it | Built-in authorise flow | Encrypted request |
The decision, in one line
If the service supports OAuth, use it. If it doesn't, collect the raw key through an encrypted request, keep it isolated per client, and rotate it at project boundaries. What you never do is paste a raw key into chat or a shared doc, where it can't be scoped, revoked, or expired.
Why the leftover raw keys still matter
Even in an OAuth-first setup, most automation projects still need a handful of raw keys. Those are the credentials that end up in a Slack thread if you don't give them a safe home. Collecting them in one structured, encrypted request keeps them out of chat and gives you a clean list to rotate later.
Where doconvoy fits
For the raw keys OAuth can't cover, a doconvoy request collects them encrypted, one labelled field per key, isolated per client, with a record you can use to rotate at handoff. It doesn't replace OAuth; it handles what OAuth leaves behind. See the full setup in how to collect API keys from clients securely.
Send one encrypted request for the raw API keys an automation still needs, isolated and ready to rotate.
Collect the keys OAuth can't coverRelated: How to collect API keys from clients securely · How to rotate and expire client API keys · Collect API keys for AI automation agencies · Access Controls
Common questions
Should an automation agency use API keys or OAuth for client access?
Prefer OAuth when the service supports it, because it grants scoped, revocable tokens and you never hold the client's raw secret. Use a raw API key only where OAuth isn't offered, and collect it through an end-to-end encrypted request rather than chat.
Why is OAuth safer than a raw API key?
An OAuth token is scoped to specific permissions and can be revoked by the client without breaking their other integrations. A raw API key is usually broad, long-lived, and hard to rotate, so if it leaks, more is exposed and for longer.
What do I do with the raw keys I still have to collect?
Collect them through an encrypted request, keep each project's keys isolated, and rotate them at project boundaries. Never leave a raw key in Slack, email, or a spreadsheet.