Cohesity Developer Portal
The cohesity developer portal gives teams the docs and tools to automate backup tasks. You use it to build scripts that manage data protection across your storage systems. Many teams start by creating a shared admin account to test their first scripts. That shortcut works early on, but broad roles create risk when scripts run in production. A single leaked key or bad script can wipe out critical backup snapshots fast. How the cohesity developer portal works in practice The cohesity developer
Developer Portal Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The cohesity developer portal gives teams the docs and tools to automate backup tasks. You use it to build scripts that manage data protection across your storage systems. Many teams start by creating a shared admin account to test their first scripts. That shortcut works early on, but broad roles create risk when scripts run in production. A single leaked key or bad script can wipe out critical backup snapshots fast.
How the cohesity developer portal works in practice
The cohesity developer portal brings together API reference guides, software development kits, and workflow examples. Engineers read these guides to learn how the storage cluster handles web requests. Instead of clicking through dashboards, you send structured calls to trigger backup runs. You can also check job status, restore files, and pull audit reports through code.
To get started, an admin creates a user profile or role on the cluster. That role defines which backup objects and storage domains the script can touch. Next, the developer generates an API key or token tied to that specific role. Your automation tool sends this secret with every request to prove its identity.
Teams also use the portal to find prebuilt plugins for common automation tools. Whether you use Python scripts or config tools, the core pattern stays the same. Your code logs in, runs a sequence of backup commands, and logs the output. Scoping each role to specific tasks keeps a single broken script from causing harm.
What native API roles solve and where gaps remain
Native roles in the storage cluster solve the first layer of access control. They decide who can log in and which high-level resource groups they can reach. You can split duties so a reporting script only reads job logs. At the same time, a recovery script gets permission to write and restore volumes.
Still, static keys and broad role assignments leave a major gap during daily work. Once a user or script logs in, the native role cannot check single commands. An admin role meant to fix one failed job can also delete whole backup policies. Also, shared keys sit in plain text on laptops and build servers for months.
Developer Portal Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When an engineer runs a manual fix against the API, logs lack clear context. You might see that a service account changed a policy, not which person did it. On top of that, API responses can return sensitive metadata or contact details. Without inline checks, emails or phone numbers flow straight into unsecured local log files.
Safer patterns for backup automation and team workflows
Closing these gaps requires moving away from static keys stored on engineer laptops. First, map every script to a narrow role that matches its exact daily task. Never reuse a human admin account for an automated pipeline or monitoring job.
Second, require human review before any user runs destructive API calls against production backups. Reading job status is safe, but changing retention rules should need a quick peer check. Third, keep a clear audit trail that ties every API call to an individual user. Finally, mask sensitive fields like emails or card numbers when responses return to terminals.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What resources are inside the cohesity developer portal?
The portal hosts REST API docs, SDKs for popular languages, and integration guides. Teams use these resources to write scripts that automate backup and recovery workflows.
Why are static API keys risky for backup automation?
Static keys do not expire on their own and often sit in local files. If someone steals a key, they gain ongoing control over your backup cluster.
How can teams restrict what backup scripts can change?
Assign each script a custom role with only the minimum required read or write rules. Pair that role with action checks and approval steps for any destructive commands.