Skavio Processing API: shared operations without sharing one secret
Skavio separates access for colleagues from access for software: team invitations bring people into the company workspace, while scoped API keys connect server-side integrations. Use those two paths deliberately. Collaboration should not require copying an existing integration secret into a team chat.
1. Establish the company boundary first
Start in the existing company workspace, where the navigation includes Team and API keys. These controls serve different purposes, but both operate within the company boundary. Skavio documents company-isolated jobs—not private job silos for each colleague. Ordinary company members can process and download company files, so joining the company is a meaningful access decision. Each account belongs to one company; confirm the intended company before onboarding someone. The financial boundary is shared too. Web processing tools and the API use one Pricing V2 company wallet. Separate credentials still use that shared wallet; do not treat them as separate budgets or assume per-member spending caps.
2. Invite colleagues instead of handing them an API key
Use Team for people who need to work in the company workspace. The documented invitation flow requires a registered colleague’s email address and acceptance by the matching signed-in account. An important operational detail: creating the invitation does not automatically send an email. Tell the colleague separately to check their dashboard. Do not treat the invitation as completed onboarding until they have accepted it.
- Open Team in the company workspace.
- Enter the registered colleague’s email address, select the intended role and create the invitation.
- Ask the colleague to sign in with the matching account and accept the invitation in their dashboard.
- Confirm that they have joined the intended company before directing them to company files.
3. Give integrations named, appropriately scoped keys
For software access, an administrator creates a key through an interactive web session. Skavio distinguishes read-only from read/write keys. Choose the access level according to the operations the integration needs, and consult the API documentation before implementing those operations. Name the key for its workload rather than treating it as a general team credential. Distinct workload credentials and limited access follow OWASP’s least-privilege guidance and reduce reliance on one broadly distributed secret. They should not be mistaken for a promise of per-person audit trails or document-level permissions.
- Use a workload-specific name that colleagues can recognize when reviewing integration ownership.
- Choose read-only or read/write access according to the integration’s needs.
- Store the secret securely when it is displayed: the workspace shows it only once.
4. Keep the credential on the server
The Processing API uses Bearer authentication over HTTPS. Make authenticated requests from your server-side integration, not from browser code containing the API secret. Keep the secret out of source control and restrict access to its storage. Keep credential administration separate from everyday processing. API keys cannot create additional keys; administrators create them through an interactive web session. A colleague who needs workspace access should receive an invitation, not a copy of the backend credential.
5. Treat offboarding as an integration change
Skavio keys are bound to both the company and their creator’s membership. Removing that membership invalidates access through those keys. Before removing someone, identify whether production integrations depend on credentials they created; staff offboarding and integration ownership are connected tasks. The documented rotation model is revoke-and-replace. Plan the replacement, update its consumers and test the required operations before retiring the old credential where circumstances permit. If a secret may be compromised, prioritize revocation and handle the resulting integration recovery explicitly. Neither automatic rotation nor uninterrupted service should be assumed.
- Maintain an internal record of each integration’s key owner, purpose, access level and consuming application—without recording the secret itself.
- Review credential dependencies before membership changes.
- When replacing a key, update every consumer and verify the required operations.
- Revoke credentials that are no longer needed and remove obsolete copies from your secret storage.