Direct answer
Give every integration its own identity. Instead of connecting an automation with a staff member's login, create a dedicated account or credential for the integration, give it only the access it needs, store its secret in a proper place, and record who owns it. That way the integration keeps working when a person leaves, can be switched off without locking anyone out, and leaves an audit trail that says what it did.
This page is deliberately vendor-neutral. Every system names these things differently and has its own screens, so it does not describe any specific product's steps. It gives you the decisions to make and the questions to put to whoever is setting things up. For what a vendor will typically ask you for, see access requirements for an AI automation agency.
Service accounts versus personal accounts
A personal account belongs to a person: their permissions, their multi-factor prompts, their departure date. Using it for an integration ties the business process to that individual. A service account (sometimes called an integration user, machine user, API client or application credential) belongs to the integration itself.
- Personal login: fails when the person leaves, changes their password or has their access reduced; actions in logs look like that person did them
- Service identity: survives staff changes, can be given narrow rights, and shows up in logs under its own name
- Some systems do not offer service identities on every plan. If that is the case, use a dedicated account tied to a role mailbox, never a named person's, and record the limitation
- Avoid sharing one identity across several integrations, because you can no longer tell them apart or revoke one safely
Decide the scopes: least access that works
Scopes or permissions define what the identity may do. Start from the workflow: which records must it read, which must it create or change, and what must it never touch? Grant exactly that. Read-only is often enough for the first stage of a project, and access can be widened later with a reason, which is far safer than narrowing after a mistake.
Write down the scope for each integration in plain language, for example 'reads new orders, writes a status note, cannot delete or export'. If the system's permission model is too coarse to express that, note the gap: you have accepted more risk than the workflow needs, and monitoring matters more.
Sandbox first
If the system offers a test or sandbox environment, build and test against it before touching live data. Ask early whether one exists, because some systems provide none, and then you need another way to test safely, such as a small set of clearly marked test records.
Keep sandbox and production credentials separate and clearly named, and make sure it is impossible to mistake one for the other. A production key in a test configuration is how test runs send real emails or change real records. The workflow automation and systems integration page describes how we approach staged rollout.
Secret storage
API keys, tokens and passwords are secrets. Treat them that way from the first day.
- Hand secrets to the builder through a password manager share or another secure channel, never by email or chat
- In the running system, keep them in environment configuration or a secrets store, never in the source code or in a spreadsheet
- Give each secret a label that says what it is for, which environment it belongs to and who owns it
- Make sure secrets do not appear in logs, error messages or screenshots sent to others
- If a secret was shared in an insecure way even once, replace it
Rotation
Rotation means replacing a credential with a new one on a schedule or after an event. Decide the events in advance: someone with knowledge of the secret leaves, a secret was exposed, a vendor contract ends, or a project phase completes. Also record whether the credential expires by itself, and who is reminded before it does.
The practical test of your design is whether you can rotate a key without an outage. That usually means the system can hold a new value while the old one is still valid, or that the change can be made in a planned window. Ask the builder how it works in this case, and have them do it once during setup.
Ownership
Every credential needs a named business owner, a technical contact, and an account registered to your organisation. The account that issues the credential should belong to you, not to the builder. LATYNEX commits to handing over code, domain and accounts in the client's name, and that principle applies equally to integration accounts. Keep one register listing each integration, the system it connects to, the identity used, its scope, the storage location and the owner. The handover items in the software handover checklist show how this register fits into a wider transfer.
Offboarding and audit
When a project ends, a vendor leaves or an integration is retired, disable its identity, revoke its keys and remove any access the builder had, then confirm the integration actually stopped. Leftover credentials are one of the most common quiet risks.
For audit, check that the systems record which identity performed each action and that someone can retrieve that history. Review the register periodically: is each integration still needed, still correctly scoped, and still owned by someone who is still here? When a workflow needs a purpose-built interface between systems rather than a connection through existing ones, see when a business needs a custom API.
Questions
Is it acceptable to use my own login for a quick test?+
For a very short, supervised experiment it may be tolerable, but do not leave it in place. Move to a dedicated identity before anything runs unattended or on live data.
What if the system does not support service accounts?+
Use a dedicated account tied to a role mailbox rather than a named person, restrict it as far as the system allows, record the limitation in your register and monitor it more closely.
How should we share an API key with a vendor?+
Through a password manager share or a secure channel agreed in advance, with the vendor's own access recorded. Do not send it by email or chat message.
How often should credentials be rotated?+
There is no single correct schedule. Rotate on defined events (departures, exposure, project end) and on whatever cycle your own security policy sets, and check that rotation can be done without an outage.
Does LATYNEX need production access at the start?+
Not usually. Starting with the narrowest access and a test environment, where one exists, is the safer path, and access is widened only for a stated reason.