Several external tools will connect to Busabase for different purposes, such as reading reference data or creating records. Sharing one API key would simplify setup, but disabling one tool later could affect the others. Should keys be created per tool or grouped by purpose? How should their names, permissions, and ownership be organized for ongoing maintenance?
Give each external tool its own Busabase API key. Then you can rotate or revoke one connection without breaking the others, and the key name tells you what it was issued for. Separate production and testing as well; two tools doing similar work should still have different keys if they have different owners or lifecycles.
Name keys for the integration and purpose, such as crm-sync-prod-read and content-agent-prod-propose. Give a reference-data reader Read access. Give a tool that should suggest new records Change Request access, so a person can review before the changes become current. Use direct Write only when that tool genuinely needs immediate changes, and set an expiry you can maintain. Record who owns each integration, where the key is configured, and its rotation date; never put the secret in a shared document or repository.
One important boundary: a Busabase key belongs to the account that created it, not to just one Space. Its actual access also depends on that person's membership in each Space. Check the account and Space used by each tool; a Space ID selects a target but does not turn the same key into a Space-only credential. Is any of your tools meant to write immediately, or could all writes wait for review?
Sign in to join the discussion. Reading is always open; you only need an account to post.
Sign in