Before you give a partner API access, define the narrowest scope that works, decide where their credential will live, set a rotation and expiry rule, turn on logging you control, and write down how access is removed. A key shared in an email thread with full rights is the pattern behind many avoidable incidents.
Start with what the partner needs
Write the integration in one sentence: "The partner reads invoice status for our customers' accounts." If the sentence needs the word "everything", the scope is too wide. Then translate it into the smallest set of permissions your system supports: read or write, which objects, which environments, which tenants.
The checklist
- Scope. Least privilege, read only where possible, production separate from test.
- Identity. One credential per partner and per environment. No shared keys, no personal accounts.
- Issuance. Hand the credential over through a secrets manager or a one time link, not email or chat.
- Storage on their side. Ask where it will be kept. A secrets manager is better than a config file, and a config file is better than source code.
- Rotation and expiry. Short lived tokens where the platform allows. Otherwise a calendar rotation and a named owner.
- Network limits. Restrict by source address if the partner has stable ones.
- Logging. Record calls under that credential on your side, and ask how the partner logs access to your data.
- Rate and volume limits. They reduce harm from a stolen key.
- Incident contact. Names and numbers on both sides, and a promise to notify you if their credential may be exposed.
- Exit. A written step list for revoking access and deleting data, tested once.
Ask the partner these questions
- Who in your company can see our credential?
- Is it ever copied into tickets, chat, CI variables or developer laptops?
- Do your own contractors or subprocessors get access to it?
- What do you do if you suspect it leaked?
If a key does reach a repository, rotate it right away. See rotate first, rewrite later.
Scoping table
| Partner need | Poor scope | Better scope |
|---|---|---|
| Show order status | Full admin API key | Read only on orders for one tenant |
| Send notifications | Full user directory read | Write to a single notification endpoint |
| Sync reports | Production database login | Scheduled export to a bucket they can read |
Review on a schedule
Access granted for a pilot tends to outlive the pilot. Put an expiry date in the grant and an owner on the calendar. At each review, ask if the partner still needs it, whether the scope can shrink and whether logs show anything unusual.
Try it yourself
Open the demo to see an API security scan identify weak spots such as missing authorization and exposed endpoints. Pay attention to which findings relate to scope.
Click through it at your own pace, or open it full screen.
Safeguard's API security scanning, asset discovery and policy guardrails help teams see what is exposed before a partner connects. You can start with a free scan.
Quick check
Is an OAuth grant safer than an API key?
It can be, thanks to scopes, expiry and revocation. A broad, long lived grant is still a risk.
How often should partner credentials rotate?
Pick a schedule your team can actually keep, and rotate at once after any suspected exposure or staff change.
Last reviewed: 19 October 2026.
