Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the PagerTree API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fpagertreecom%2Fpagertree" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fpagertreecom%2Fpagertree" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with PagerTree API.
Create, read, update, and delete alerts with urgency levels and metadata
Transition alert states via acknowledge, reject, and resolve actions
Comment on alerts to add context and collaboration
Manage teams with members, admins, and escalation policy bindings
Query current on-call users for teams and schedules
GET STARTED
Create and manage on-call schedules with event time windows
Flush schedules to remove all events
Configure integrations for alert ingestion from external systems
Manage users with notification preferences (push, email, SMS, voice)
Paginate and filter alerts, teams, integrations, and users
Patterns agents use PagerTree API for, with concrete tasks.
★ Incident Response Workflow
SRE teams can automate incident response by creating alerts via POST /alerts with urgency and destination teams, then transitioning alert states through acknowledge, resolve, or reject actions. GET /alerts lists paginated alerts, and POST /alerts/{id}/comments adds collaboration notes. Combined with /teams/{id}/current_oncall, responders can route alerts to the on-call engineer and track resolution progress, building an automated incident management pipeline.
POST /alerts with title, urgency, and destination_team_ids to create an alert, then POST /alerts/{id}/acknowledge to accept it, add comments via POST /alerts/{id}/comments, and POST /alerts/{id}/resolve when fixed.
On-Call Schedule Management
Operations teams can programmatically manage on-call rotations by creating schedules via POST /schedules and querying on-call attendees via GET /schedules/{id}/current_oncall or GET /schedules/{id}/window_events with start/end times. GET /teams/{id}/current_oncall returns the current on-call team members. This enables automated on-call dashboards, shift notifications, or integration with calendar systems for visibility into who is responsible at any given time.
POST /schedules with a name to create a schedule, then GET /schedules/{id}/current_oncall to see who is on-call now, or GET /schedules/{id}/window_events with start and end query parameters to list on-call periods.
Monitoring Tool Integration
DevOps platforms can integrate alert sources like Datadog, Prometheus, or custom monitors by creating integrations via POST /integrations with urgency, integration_type_id, and destination team_ids. Each integration generates a webhook URL for the external tool to post alerts. GET /integrations lists configured integrations, and PUT /integrations/{id} updates routing or urgency. This centralizes alert ingestion from multiple monitoring tools into a unified incident workflow.
POST /integrations with name, urgency, integration_type_id, and team_ids to create an integration, then configure the external monitoring tool to send alerts to the generated webhook URL.
35 endpoints — the pagertree api is organized around rest for managing alerts, teams, schedules, escalation policies, integrations, and users.
METHOD
PATH
DESCRIPTION
/alerts
Create an alert
/alerts/{id}/acknowledge
Acknowledge an alert
/alerts/{id}/resolve
Resolve an alert
/alerts/{id}/comments
Comment on an alert
/teams/{id}/current_oncall
Get team's current on-call users
/schedules
Create a schedule
/schedules/{id}/current_oncall
Get schedule's current on-call
/schedules/{id}/window_events
List on-call events in a time window
/integrations
Create an integration
/alerts
Create an alert
/alerts/{id}/acknowledge
Acknowledge an alert
/alerts/{id}/resolve
Resolve an alert
/alerts/{id}/comments
Comment on an alert
/teams/{id}/current_oncall
Get team's current on-call users
/schedules
Create a schedule
/schedules/{id}/current_oncall
Get schedule's current on-call
/schedules/{id}/window_events
List on-call events in a time window
What agents get from Jentic-routed access to this vendor.
Setup
Wiring PagerTree by hand means handling its bearer-token auth against api.pagertree.com/api/v4, shaping alert and schedule payloads, and building your own retry and error handling. Through Jentic you install once, import the PagerTree API from the API Directory, store the token once, and your agent calls it.
Permission scoping
PagerTree puts the alert id in the URL path (/alerts/{id}/acknowledge), so a rule can pin your agent to one alert: it can acknowledge or comment on that alert and nothing else. You choose the operations it may call, so resolving alerts or creating integrations is not included unless you add them.
Credential isolation
Your PagerTree key is stored once, encrypted, by your own Jentic One instance and injected as the Authorization bearer header at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'create a PagerTree alert' or 'get current on-call users', and Jentic returns the matching PagerTree operation with its input schema so the agent calls the right endpoint without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using PagerTree API through Jentic.
What authentication does the PagerTree API use?
The PagerTree API uses bearer token authentication. Obtain an API key from your User Settings page and pass it in the Authorization header as 'Bearer <api_key>'. Through Jentic, keys are stored encrypted and injected automatically at execution time.
Can I query who is currently on-call?
Yes. GET /teams/{id}/current_oncall returns the current on-call users for a team, and GET /schedules/{id}/current_oncall returns the on-call attendees for a schedule at the current time.
How do I transition alert states?
Use POST /alerts/{id}/acknowledge to acknowledge an alert, POST /alerts/{id}/resolve to resolve it, or POST /alerts/{id}/reject to reject it. Each action requires the alert to be in a valid state (e.g., resolve requires open, dropped, or acknowledged state).
Does the API support bulk updates?
No. The PagerTree API does not support bulk updates. You must make individual requests for each alert, team, schedule, integration, or user operation.
Can I retrieve on-call schedules for a specific time range?
Yes. GET /schedules/{id}/window_events with start and end query parameters returns on-call attendees for the specified time window.
How do I integrate monitoring tools like Datadog?
Create an integration via POST /integrations with the appropriate integration_type_id and destination team_ids. The response includes a webhook URL that you configure in your monitoring tool to send alerts to PagerTree.
Can I limit what my agent is allowed to do with the PagerTree API?
Yes. Because you run Jentic One yourself, your own rules decide which PagerTree operations and credentials your agent may use. Since PagerTree puts the alert id in the URL path, such as POST /alerts/{id}/acknowledge and POST /alerts/{id}/comments, you can scope the agent to a single alert and let it acknowledge or comment on that alert and nothing else. Operations like POST /alerts/{id}/resolve or POST /integrations stay off limits unless you explicitly grant them.
For Agents
Manage PagerTree alerts, teams, schedules, escalation policies, integrations, and users with state transitions and on-call workflows.
Use for: Create a critical alert routed to a specific team, Acknowledge an open alert, Resolve an acknowledged alert, Comment on an alert with troubleshooting notes
Not supported: Manages alerts, teams, schedules, integrations, and users. Does not expose escalation policy configuration, webhook delivery logs, or billing management - use the PagerTree UI for those settings. Does not support bulk updates.
The PagerTree API is organized around REST for managing alerts, teams, schedules, escalation policies, integrations, and users. It supports creating, reading, updating, and deleting alerts with state transitions (acknowledge, reject, resolve), managing on-call schedules with time-window events, configuring team memberships and escalation policies, setting up integrations for alert ingestion, and managing user notification preferences. Returns JSON-encoded responses and uses standard HTTP verbs and status codes. Does not support bulk updates.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
/integrations
Create an integration
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>