Your scripts deserve their own keys
Scripts, scheduled jobs, and vendor integrations keep important work moving. Give each one its own M7 API key, so you can see its purpose, set useful boundaries, and manage its access through the life of the job.
M7 API keys are available to people and organizations for supported automations and integrations. A separate key for each script or vendor keeps ownership clear and gives you a direct way to manage the credential when that work changes.
Start with a key you can control
New keys begin disabled, giving you time to set them up before they are used. The secret appears once at creation, so put it in the script or vendor’s secure secret store at that moment.
Before activating the key, choose the boundaries that fit the task: an expiry date, a use limit, IP restrictions, audiences, and scopes. Personal and organization keys have separate management contexts, which keeps the owner of each integration visible.
Set those limits around the automation itself. A vendor that calls one service can use the audiences and scopes chosen for that connection, while a job that runs from known infrastructure can use its IP restriction. Review the limits whenever the work changes.
Give an integration a clean handoff
Consider a scheduled job that calls an API your team operates. Its owner creates a dedicated key, stores the one-time secret in the job’s secure secret store, sets an expiry and the needed restrictions, then activates it.
When that API supports M7 API-key verification, it can ask the verifier to check the key’s lifecycle and configured policy. The API then applies its own resource authorization rules. For organization work, it can also require the verified key to match the organization’s tenant before allowing the action.
OAuth client credentials remain useful where an integration needs OAuth machine access tokens. For supported M7 API-key verification, use the verification guide to connect the receiving API.
Keep the next change simple
The management view lets you track keys and their last use, then disable or revoke a key when a job retires or its access needs to stop. If a key is compromised or revoked and the integration must continue, create a new key and update the secure secret store.
That gives scripts and vendors a clear access record from setup through retirement. Start in Applications → API Keys, create one key for one moving part, and give each integration a credential you can manage.