- Use a separate credential per integration.
- Prefer read-only access for inventory.
- Store secrets outside public code.
Create a named credential
In Security, name a credential after its purpose, such as inventory-reader. Choose the narrowest scope. Copy its secret when shown and store it privately; the list keeps a label and scope rather than redisplaying the complete secret.
Never place an API token in a URL, source repository, screenshot or support ticket.
Read before preparing changes
Inspect the stable server identifier, region, plan and current state. Build a reviewable desired configuration before a write. Display names are convenient labels, not guaranteed unique identifiers.
GET /v1/servers
GET /v1/servers/{server_id}
GET /v1/invoices/{invoice_id}Design around uncertain outcomes
A timeout does not prove that a write failed. Record a request identifier and inspect the resulting state before retrying a deployment or billing action. A repeatable workflow recognises an already-completed operation.
Use bounded retries for transient reads. Stop and investigate an uncertain write instead of repeating it indefinitely.
Separate environments
Use different credentials for development and production. Keep inventory access read-only. A job that uploads an application does not need permission to remove every server or rotate the account’s access key.
Put sensitive changes into your own review and change process. Automation should make an approved decision reproducible.
Rotate and revoke
Create a replacement, update the integration and verify it works before revoking the old credential. Check that the revoked secret no longer works and document the recovery path. Review unused credentials periodically.