canonical: https://jentic.com/apis/panther.com/main # Panther REST API Jentic publishes the only available OpenAPI specification for Panther REST API, keeping it validated and agent-ready. The Panther REST API provides comprehensive interaction with Panther SIEM entities including alerts, API tokens, rules, users, and queries. It powers security operations workflows, threat detection rule management, and SIEM automation for cloud-native security teams using Panther's detection-as-code platform. ## For AI agents Manage SIEM alerts, rules, queries, users, and API tokens across 16 endpoints. ## Scope Does not handle log ingestion, detection pack deployment, or dashboard creation - use for alert triage, rule management, and query automation only. ## Capabilities - Retrieve and update security alerts with status, assignee, and quality metadata - Create, rotate, and manage API tokens with permission scopes and IP allowlists - Create and manage Python-based detection rules with testing capabilities - Create, update, and delete saved and scheduled queries - Manage user accounts with role-based access control ## Use cases ### Alert Triage and Management Retrieve and update security alerts during incident response workflows. GET /alerts/{id} fetches alert details including severity, status, and event count, while PATCH /alerts/{id} updates status, assignee, quality, or contextTags. Essential for security operations teams managing alert queues and incident escalation. Example prompt: GET /alerts/{id} to retrieve alert, then PATCH /alerts/{id} to update status to RESOLVED and assign to analyst ### Detection Rule Management Create and update Python-based detection rules with built-in testing. POST /rules creates a new rule with optional run-tests-first and run-tests-only parameters, enabling test-driven detection development. PUT /rules/{id} updates existing rules with the same testing capabilities. Example prompt: POST /rules with rule body and run-tests-first=true to validate before saving, or run-tests-only=true for testing without saving ### API Token Lifecycle Management Create, retrieve, rotate, and delete API tokens with granular permission scopes and IP allowlists. POST /api-tokens creates tokens with specified permissions array, POST /api-tokens/self/rotate rotates the current token, and DELETE /api-tokens/{id} revokes access. Critical for API security and credential rotation policies. Example prompt: POST /api-tokens with name, permissions, and allowedCIDRBlocks, then POST /api-tokens/self/rotate for token rotation ### Saved and Scheduled Queries Create, update, and delete saved or scheduled queries for recurring searches across log data. POST /queries creates a saved query with optional schedule and emailConfig for automated report delivery. Essential for security analytics and compliance reporting workflows. Example prompt: POST /queries with name, sql, schedule, and emailConfig to create scheduled query with email delivery ### Agent-Driven SIEM Automation via Jentic An AI agent managing security operations can triage alerts, create detection rules, and manage API tokens through Jentic without holding the X-API-Key in agent context. Jentic resolves intents like 'assign this alert' to the right Panther endpoint and supplies the request schema. Example prompt: Search Jentic for 'update alert status', load the PATCH /alerts/{id} schema, and execute ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /alerts/{id} | Get an alert by ID | | PATCH | /alerts/{id} | Update alert status, assignee, quality, or contextTags | | POST | /api-tokens | Create an API token | | GET | /api-tokens/{id} | Get an API token by ID | | DELETE | /api-tokens/{id} | Delete an API token | | POST | /api-tokens/self/rotate | Rotate the current API token | | POST | /rules | Create a Python detection rule | | GET | /rules/{id} | Get a rule by ID | | PUT | /rules/{id} | Update a rule | | DELETE | /rules/{id} | Delete a rule | | POST | /queries | Create a saved or scheduled query | | GET | /queries/{id} | Get a query by ID | | PUT | /queries/{id} | Update a query | | DELETE | /queries/{id} | Delete a query | | POST | /users | Create a user | | GET | /users/{id} | Get a user by ID | ## Key resources - **Alert** — Security alert retrieval and status management with assignee and quality metadata - **ApiToken** — API token creation, rotation, and lifecycle management with permissions and IP allowlists - **Rule** — Python detection rule creation, testing, and management - **Query** — Saved and scheduled query management with email delivery - **User** — User account creation and management with role-based access control ## Why Jentic - **Setup:** Wiring the Panther API by hand means handling its X-API-Key auth, pointing at your own Panther deployment host, and building your own retry and error handling. Through Jentic you install once, import the Panther REST API from the API Directory, store the key once, and your agent calls it. - **Permission scoping:** Panther puts the alert and rule ids in the URL path (/alerts/{id} and /rules/{id}), so a rule can pin your agent to a specific alert or detection rule and the operations you approve. You choose the operations it may call, so rotating API tokens or deleting rules is not included unless you add them. - **Credential handling:** Your Panther key is stored once, encrypted, by your own Jentic One instance and injected as the X-API-Key header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'update an alert status' or 'create a detection rule', and Jentic returns the matching Panther operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Splunk API** — Traditional SIEM platform with extensive search, alerting, and log management capabilities - **Elasticsearch API** — Search and analytics engine often used as a log storage backend for SIEM platforms ## FAQ ### Why is there no official OpenAPI spec for Panther REST API? Panther does not publish a complete OpenAPI specification for their REST API. Jentic generates and maintains this spec so that AI agents and developers can call Panther REST 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 Panther REST API use? The Panther REST API uses an API key passed in the X-API-Key header. Through Jentic, the key is stored in the encrypted vault and injected at execution time so it never enters the agent's prompt context. ### Can I test detection rules before saving them? Yes. POST /rules accepts run-tests-first (default true) to run tests before saving, or run-tests-only=true to test without saving. This enables test-driven detection development and prevents broken rules from being deployed. ### How do I rotate an API token? POST /api-tokens/self/rotate rotates the current API token used for authentication. The endpoint returns a new token with the same permissions, and the old token is immediately invalidated. ### Can I schedule queries to run automatically? Yes. POST /queries accepts a schedule object to configure recurring execution, and an emailConfig object to deliver results via email. This enables automated security reporting and compliance workflows. ### What alert statuses are supported? Panther alerts support OPEN, CLOSED, TRIAGED, and RESOLVED statuses. PATCH /alerts/{id} updates the status, and you can optionally set assignee, quality (NOISE or USEFUL), and contextTags to enrich alert metadata. ### Can I limit what my agent is allowed to do with the Panther API? Yes. Because you run Jentic One yourself, your own rules decide which Panther operations and credentials the agent may use. Panther puts alert and rule ids in the URL path (/alerts/{id} and /rules/{id}), so a rule can pin the agent to a specific alert or detection rule and only the operations you approve, such as reading an alert with GET /alerts/{id} or updating its status with PATCH /alerts/{id}. Sensitive operations like rotating a token via POST /api-tokens/self/rotate or deleting a rule with DELETE /rules/{id} stay off limits unless you explicitly allow them.