canonical: https://jentic.com/apis/coro.net/coro # Coro API Jentic publishes the only available OpenAPI specification for Coro API, keeping it validated and agent-ready. The Coro API exposes the Coro cybersecurity platform for programmatic management of endpoint devices, security threats, and protection policies across an organisation. Through 12 endpoints under api.coro.net/v1, it covers device inventory lookups, threat triage and status updates, policy lifecycle management, and user listings. It is designed for security operations teams that want to automate triage, enforce policy from CI, or feed Coro signals into SOAR and SIEM workflows. ## For AI agents Inspect Coro-managed devices, retrieve and update detected threats, and manage protection policies for an organisation. Bearer-token authentication with 12 endpoints under /v1. ## Scope Does not handle network firewalling, SIEM event storage, or vulnerability scanning - use for endpoint protection policy and threat management only. ## Capabilities - List managed devices and inspect a single device by ID for OS, posture, and protection status - Retrieve detected threats across the tenant and update an individual threat's status to triage incidents - Create, update, and delete protection policies that govern endpoint behaviour - Fetch a specific policy by ID to audit configuration drift before rollout - List users associated with the Coro tenant and look up an individual user's profile - Drive incident response loops where an agent reads a threat, applies a policy change, and confirms the update ## Use cases ### Automated Threat Triage Pull the open threat queue from Coro, enrich each entry with device context from the devices endpoint, and update the threat status once the agent or analyst has decided on a disposition. This compresses the manual SOC loop of opening the console, reading the threat, checking the device, and clicking through status changes. Example prompt: List all threats with status open from GET /threats, for each call GET `/devices/{deviceId}` to get device posture, then PATCH `/threats/{threatId}` with the resolved status. ### Policy as Code for Endpoint Protection Manage Coro protection policies from a Git workflow by reading current policy state, diffing against the desired state in a repo, and pushing changes through POST, PUT, and DELETE on the policies endpoints. Lets security teams review policy changes in pull requests instead of dashboard clicks. Example prompt: Read all current policies via GET /policies, compare with the desired YAML in the repo, and call POST /policies, PUT `/policies/{policyId}`, or DELETE `/policies/{policyId}` to converge state. ### Device Inventory Sync to a CMDB Periodically pull every device managed by Coro and reconcile the inventory with an internal asset database or CMDB so that ownership, OS, and protection status stay aligned across systems. Useful for compliance reports and audit trails. Example prompt: Page through GET /devices, fetch per-device detail via GET `/devices/{deviceId}` when needed, and upsert each record into the target CMDB. ### Agent-Driven Incident Response via Jentic An AI agent loaded with Coro tools through Jentic responds to security alerts by inspecting the affected device, reviewing the threat detail, applying or tightening a policy, and then marking the threat resolved. The agent reasons over policy state rather than memorising endpoints. Example prompt: Search Jentic for 'manage Coro security threats', load the threats and policies operations, then chain GET `/threats/{threatId}`, PUT `/policies/{policyId}`, and PATCH `/threats/{threatId}` into a single response. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/devices` | List managed devices | | GET | `/threats` | List detected threats | | PATCH | `/threats/{threatId}` | Update threat status | | GET | `/policies` | List protection policies | | POST | `/policies` | Create a protection policy | | PUT | `/policies/{policyId}` | Update a protection policy | | DELETE | `/policies/{policyId}` | Delete a protection policy | ## Key resources - **Devices** — List devices and retrieve individual device records by ID. - **Threats** — List detected threats, fetch threat detail, and update threat status. - **Policies** — Create, read, update, and delete endpoint protection policies. - **Users** — List users and retrieve a single user by ID. ## Why Jentic - **Setup:** Wiring Coro by hand means holding its bearer token and coding the device, threat, and policy calls yourself. Through Jentic you install once, import the Coro API from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** Coro's threat and policy operations carry the target id in the request, so scope this by operations: allow the agent the calls it needs, such as listing devices and reading threats, and leave writes like updating a threat or deleting a policy out unless you add them. Each operation you credit the agent with stays inside that allowed set. - **Credential handling:** Your Coro token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list Coro threats' or 'update a Coro policy', and Jentic returns the matching operation with its input and response schemas so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **CrowdStrike Falcon API** — Cloud-native endpoint protection platform with broader threat intelligence and EDR depth than Coro. - **Sophos SIEM API** — Sophos endpoint and SIEM data feed, focused on event export rather than policy management. - **AbuseIPDB API** — IP reputation lookup that enriches Coro threat records with external abuse history. ## FAQ ### Why is there no official OpenAPI spec for Coro API? Coro does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Coro API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Coro API use? The Coro API uses HTTP bearer-token authentication: every request must include an Authorization header of the form Bearer . When called through Jentic, the token is held in your Jentic One instance and injected at execution time so it never enters the agent's prompt context. ### Can I update the status of a threat with the Coro API? Yes. The PATCH `/threats/{threatId}` endpoint updates the status of an individual threat, which lets you mark threats as resolved, acknowledged, or otherwise progressed once triage is complete. ### What are the rate limits for the Coro API? The OpenAPI spec does not declare explicit rate limits, so production callers should treat 429 responses as authoritative and back off using the Retry-After header where present. Coro's developer portal at developers.coro.net is the canonical place to confirm current limits before high-volume use. ### How do I list all managed devices through Jentic? Search Jentic for 'list Coro devices', load the GET /devices operation, then execute it. Jentic returns the operation schema so the agent knows exactly which query parameters and response fields are available without browsing Coro documentation. ### Can I manage protection policies programmatically? Yes. The /policies endpoints support POST to create, GET to list or read by ID, PUT to update, and DELETE to remove a policy, which together cover the full lifecycle for policy-as-code workflows. ### Can I limit what my agent is allowed to do with the Coro API? Yes. Because you run Jentic One yourself, your own rules decide which Coro operations the agent may call, and each of Coro's operations carries the target id in the request so you can scope access at the operation level. You can allow read-only calls such as GET /devices and GET /threats or GET /policies while leaving writes like PATCH `/threats/{threatId}`, POST /policies, PUT `/policies/{policyId}`, and DELETE `/policies/{policyId}` out of the agent's allowed set. Only the operations you explicitly grant become callable, and the bearer token is injected at execution time so it never reaches the agent's prompt.