How should API keys and CRM logins for AI integrations be handled?
Each integration gets its own credential, scoped to the minimum permissions it needs, stored in a secrets manager rather than in code or a spreadsheet, and rotatable without downtime. Never run an integration under a named employee's login — it breaks when they leave and it makes your audit trail meaningless. Use read-only wherever writes are not required, and log everything the integration writes back.
The employee-login problem is the common one
An integration gets built quickly, someone uses the office manager's credentials because they already have the right permissions, and it works. Then the office manager leaves, the account is disabled correctly, and reporting silently breaks for a week before anyone notices.
Worse, until that moment every write the integration made looked like it came from a person. If you ever need to reconstruct who changed a record, you cannot. Service accounts — named for the integration, owned by the company — fix both problems at once.
Scope down, specifically
"Minimum necessary" is easy to agree with and rarely implemented. Make it concrete.
- Read-only by default. A reporting integration should be incapable of modifying anything.
- Object-level limits. Access to jobs and invoices does not require access to payroll or user administration.
- One credential per integration. So revoking one thing does not break four others.
- Separate keys per environment. A test system should never hold a production credential.
- No credentials in code or spreadsheets. Secrets belong in a manager that supports rotation and access logging.
Rotation only happens if it is cheap
Everyone agrees keys should rotate. Almost nobody does it, because in most setups rotation means an outage and a scramble. If the system reads credentials from a secrets store at runtime, rotation is a value change and a restart.
Build that in at the start. Retrofitting rotation into a system with keys hardcoded across several services is a project nobody schedules, which is why those keys are still in place years later.
Write access needs its own record
When an AI system writes back into your field service platform or CRM — tagging a call, appending a note, setting a source field — that write should be logged on your side with what changed, when, and why. Otherwise a data quality dispute becomes unresolvable.
This matters most in systems where the write affects reporting. If an integration sets the lead source on a job in ServiceTitan or Jobber, that value flows into every revenue report you run, and you need to be able to explain where it came from.
Topics: credentials · API keys · security · integrations
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.