Incident Management

The incident management section is a vital component of the system, designed to effectively oversee all aspects of incident-related operations.

This section includes three key categories that work together to streamline incident management:

  • Ruleset Management and Event Handling

    This category facilitates the automation of incident responses through rulesets and webhook integrations, allowing for timely and efficient handling of incidents based on predefined criteria.
    See full Ruleset Management and Event Handling API →


  • Incident Tracking

    Focused on monitoring incidents throughout their lifecycle, this category provides tools for tracking incident statuses, actions taken, and overall performance, ensuring effective resolution and accountability.
    See full Incident Tracking API →


  • Incident Schedule Management

    This category enables the organization and management of on-call schedules for incident response teams, ensuring that appropriate personnel are available to respond to incidents at all times.
    See full Incident Schedule Management API →

Ruleset Management and Event Handling
Ruleset Management and Event Handling enables automated incident creation by defining custom rules that respond to specific event conditions. When a rule is triggered, it can execute predefined actions — such as sending an HTTP request to a Pinghome webhook — which then initiates an incident.

This feature allows seamless integration with third-party platforms like AWS, GCP, Azure, or any service capable of sending outbound webhooks. As a result, your system can respond automatically to threshold breaches, service failures, or alert events without manual intervention.

Key capabilities:
  • Create dynamic rulesets — Define rules based on tags, payload contents, or event metadata.
  • Trigger incident workflows — Automatically generate and track incidents based on incoming events.
  • Integrate with external tools — Connect monitoring, logging, or cloud platforms directly to Pinghome's incident system using webhook endpoints.
ENDPOINTS
Expand all
  • Ruleset configuration and management
    GET/rulesets
    POST/ruleset
    PUT/ruleset/{id}
    DELETE/ruleset/{id}
    GET/ruleset/{id}/actions
    PUT/ruleset/{id}/actions
  • Webhook handling
Get Rulesets
Retrieve all rulesets configured for your team and organization by calling this endpoint. Each ruleset contains information such as the rule type, name, description, urgency level, and assigned responders (e.g., teams).

The response is grouped into two scopes: team and organisation, showing rules defined at different levels of your environment.

Use cases:
  • Ruleset overview — View all active rules that determine how incidents are created from incoming events.
  • Responsibility auditing — Check which teams are assigned to respond when a specific rule is triggered.
  • Urgency validation — Review urgency settings to ensure incidents are prioritized appropriately based on rule definitions.


Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return ruleset data for both team and organization.
  • If the request is unauthorized, the system will return an authentication error message.
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/rulesets";

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Create Ruleset
Create a new ruleset in the incident management system by submitting a configuration payload in the request body. The ruleset defines the logic for automatically generating incidents when specific conditions are met.

Required fields typically include the type of rule (e.g., state-change), an array of conditions, the target team_id or assignees, urgency level, and a descriptive name and description for context.

Once created, this ruleset becomes active and will automatically evaluate incoming events according to the defined logic.

Use cases:
  • Proactive alerting — Define custom logic to convert alert data into actionable incidents automatically.
  • Team-based triage — Assign rules to specific teams to ensure incidents are routed to the right responders based on the rule's criteria.
  • Flexible escalation logic — Configure different urgency levels and descriptions depending on the nature of the matched condition.

To review existing rules, see Get Rulesets.
To delete an existing rule, use Delete Ruleset.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will create a new ruleset and return the ruleset ID.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Request Body Parameters
  • rule_type string
    The type of rule being created. Accepted values: 'state-change' or 'webhook'.
  • conditions array of objects
  • level string
  • team_id string
  • name string
  • description string
  • urgency string
  • assignees (optional) array of objects
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/ruleset';
const data = {
  rule_type: 'state-change',
  conditions: [{ values: ['10'], operator: 'equal', type: 'json-check', key: 'products[0].count' }],
  level: 'team',
  team_id: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8',
  name: 'Name',
  description: 'Description',
  urgency: 'medium',
  assignees: [{ type: 'team', id: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed' }]
};

axios.post(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Update Ruleset
Update an existing ruleset in the incident management system by providing the ruleset_id in the path and submitting the updated rule configuration in the request body. You can modify fields such as the type of the rule (e.g., state-change), the list of conditions, urgency, description, name, and assigned assignees (e.g., team IDs).

This endpoint is useful for refining how and when incidents are triggered, adjusting team responsibilities, or evolving your alert routing logic as infrastructure or workflows change.

Use cases:
  • Policy adjustments — Modify existing rules to reflect updated monitoring logic or operational policies.
  • Team ownership changes — Reassign incident ownership by updating team IDs or assignee lists.
  • Priority tuning — Adjust urgency levels and descriptions to better align with your response process.

To view current rules, see Get Rulesets.
To create new rules, use Create Ruleset.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will update the ruleset and return a success message.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The ID of the ruleset to be updated. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
Request Body Parameters
  • rule_type string
    The type of rule being created. Accepted values: 'state-change' or 'webhook'.
  • conditions array of objects
  • level string
  • team_id string
  • name string
  • description string
  • urgency string
  • assignees (optional) array of objects
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/ruleset/c03b02ec-244f-4d2c-8f68-3910071ed5c8';
const data = {
  rule_type: 'state-change',
  conditions: [{ values: ['10'], operator: 'equal', type: 'json-check', key: 'products[0].count' }],
  level: 'team',
  team_id: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8',
  name: 'Name',
  description: 'Description',
  urgency: 'medium',
  assignees: [{ type: 'team', id: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed' }]
};

axios.put(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Delete Ruleset
Delete an existing ruleset from the incident management system by providing its ruleset_id in the path. Once removed, the ruleset will no longer trigger incidents based on its defined conditions.

This is useful for cleaning up deprecated logic, test rules, or automation paths no longer needed in your incident workflows.

Use cases:
  • Legacy rules cleanup — Remove rulesets that no longer match your current infrastructure or alerting needs.
  • Test configuration removal — Delete temporary rules created during integration or staging setups.

To review or identify rules before deletion, see Get Rulesets.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will delete the specified ruleset and return a confirmation message.
  • If the request is unauthorized or the ruleset is not found, the system will return an error message.
Path Parameters
  • id string
    The ID of the ruleset to be deleted. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/ruleset/c03b02ec-244f-4d2c-8f68-3910071ed5c8';

axios.delete(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Get Ruleset Actions
Retrieve all actions associated with a specific ruleset by providing its ruleset_id in the path. Each action defines what automated task should be executed when the ruleset conditions are met — such as updating a status page component or triggering a downstream system.

The response includes the action type (e.g., trigger-statuspage-update) and nested settings that specify the source (e.g., a resource ID being monitored), the target (such as a status page component), and the parent entity (e.g., the linked status page).

Use cases:
  • Status page automation — Automatically reflect service impact by linking monitored resources to status page components.
  • Rule-action mapping review — Confirm how each ruleset is wired to act when conditions are triggered.
  • Integration debugging — Inspect exact settings to verify IDs and types used in external updates or webhooks.


Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return the actions tied to the ruleset, including action type and settings.
  • If the request is unauthorized, the system will return an authentication error message.
Path Parameters
  • id string
    The unique ID of the ruleset for which actions are being retrieved. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/ruleset/c03b02ec-244f-4d2c-8f68-3910071ed5c8/actions";

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Update Ruleset Actions
Update the list of actions associated with a specific ruleset by providing the ruleset_id in the path and submitting the updated actions array in the request body. Each action includes a type (such as trigger-statuspage-update) and corresponding settings.

This endpoint is essential for refining or replacing automation behavior tied to incident rules. For example, you might update which status page components are affected when a rule triggers.

Use cases:
  • Automation updates — Modify how triggered incidents affect external tools like status pages or third-party integrations.
  • Integration corrections — Update resource, component, or parent references when IDs or structure change.
  • Rule-action realignment — Reassign an action to new targets as incident response strategies evolve.

To review the current actions tied to a ruleset before making updates, use the Get Ruleset Actions endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will update the actions for the specified ruleset.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The ID of the ruleset to be updated. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Request Body Parameters
  • actions array of objects
    An array of actions to be updated, each containing an ID, type, and settings.
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/ruleset/445a5c1f-c0eb-403a-96d7-3976e5dc74ed/actions';
const data = {
  actions: [
    {
      type: 'trigger-alerts',
      settings: [
        {
          status_page_id: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed',
          component_id: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
        }
      ]
    }
  ]
};

axios.put(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Get Webhooks
Retrieve a list of all webhook endpoints configured for the incident management service. Each webhook acts as an entry point for receiving external event data (e.g., from cloud alerts, logging tools, or custom systems) that can trigger automated incident creation based on predefined rules.

The response includes details for each webhook, such as name, description, enabled status, the URL to which events should be sent, and the created_at timestamp.

Use cases:
  • Integration inventory — View all active webhook endpoints used for event ingestion.
  • Debugging setup — Confirm webhook URLs, statuses, and metadata when testing third-party integrations.
  • Maintenance review — Identify old or disabled webhooks that may no longer be in use.

To add new webhook receivers for external events, use the Create Webhook endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return a list of webhooks with details such as webhook name, description, and URL.
  • If the request is unauthorized, the system will return an authentication error message.
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/webhooks";

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Get Webhook Events
Retrieve a list of events received by a specific webhook by providing its webhook_id in the path. Each event represents a payload submitted to the webhook endpoint — typically from an external system or alerting service.

The response includes metadata such as the content_type of the payload, the raw body of the received request, the sender’s IP address, and the received_at timestamp.

You can use query parameters like last_received_at and limit to paginate results and retrieve only the most recent entries.

Use cases:
  • Integration troubleshooting — View the actual payloads and metadata received to debug malformed requests or failures.
  • Webhook activity audit — Track which external systems have submitted events and when.
  • Payload inspection — Validate the structure and content of incoming webhook data before mapping it to rulesets.

To view all available webhook endpoints in your system, see Get Webhooks.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return webhook event details such as content type, body, IP, and received time.
  • If the request is unauthorized, the system will return an authentication error message.
Path Parameters
  • id string
    The unique ID of the webhook for which events are being retrieved. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
Query Parameters
  • limit (optional) positive integer
    Specifies the maximum number of webhook events to return, such as '10'. You can choose to include this parameter as needed.
  • last_received_at (optional) string
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/webhook/c03b02ec-244f-4d2c-8f68-3910071ed5c8/events?limit=10&last_received_at=2024-03-15T19:09:39Z";

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Create Webhook
Create a new webhook endpoint for the incident service by submitting the required configuration in the request body. A webhook acts as a custom entry point for external systems (e.g., cloud providers, CI/CD tools, alerting platforms) to send events that may trigger incidents based on ruleset evaluation.

You can define properties such as the name, description. After creation, the webhook’s unique id will be returned in the response. This ID can be used to programmatically submit event payloads to the webhook via the Submit Webhook Event endpoint

Use cases:
  • Third-party alert ingestion — Accept alert data from platforms like AWS, GCP, or GitHub Actions into your incident workflow.
  • Custom monitoring integration — Create webhook endpoints for internal tools to trigger incidents in real time.
  • Event-driven automation — Streamline operational response by forwarding external events to your ruleset system.

To inspect or manage existing webhooks, use Get Webhooks.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will create a new webhook and return the webhook ID.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Request Body Parameters
  • name (optional) string
    The name of the webhook. This parameter can be provided at your discretion.
  • description (optional) string
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/webhook';
const data = {
  name: "Webhook name",
  description: "Webhook description"
};

axios.post(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Submit Webhook Event Data
Submit event data to a specific webhook by providing the webhook_id in the path. This ID is returned when a webhook is created via the Create Webhook endpoint.

The request body accepts a flexible JSON payload consisting of arbitrary key-value data. Once submitted, the event will be processed by the webhook engine and evaluated against any matching rulesets to determine whether an incident should be triggered.

Use cases:
  • Trigger incidents from external systems — Submit alerts or event payloads from cloud providers, log systems, or internal tools.
  • Custom monitoring workflows — Report failures, anomalies, or health checks via automation scripts using a valid webhook ID.
  • Payload-driven automation — Drive incident creation logic based on dynamic field values submitted with each event.


Expected Behavior:


  • On success, the webhook will process the data and return a confirmation message along with additional meta information such as the IP address and content type.
  • If the webhook ID is invalid, an error message will be returned.
Path Parameters
  • id string
    The unique ID of the webhook created earlier.
Request Body Parameters
  • body object
    Key-value data to be submitted to the webhook.
JavaScript
Response codes
const axios = require('axios');

const url = 'https://data-gateway.api.pinghome.io/v1/incident/webhook/{id}';
const data = {
  example_key: 'example_value'
};

axios.post(url, data, {
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Incident Tracking
Incident Tracking provides the core functionality for creating, retrieving, and managing incidents across your organization. It enables teams to maintain operational visibility, respond quickly to disruptions, and log resolution activity within a structured incident lifecycle.

Through this system, you can:
  • Verify system status — Use a dedicated endpoint to check whether incidents are currently active or resolved.
  • Retrieve incident history — Fetch incidents by team or ID to audit past events or understand ongoing issues.
  • Create new incidents — Manually trigger incidents for internal reporting or unmonitored events.
  • Update incident details — Modify descriptions, status, and resolution notes to reflect progress and final outcomes.
  • Track incident actions — Review automated or manual actions associated with each incident to understand how it was handled.

This comprehensive structure supports centralized incident tracking, whether events are triggered automatically through rulesets or manually by your team.
ENDPOINTS
Expand all
  • Health check
    GET/health-check
  • Incident management
Check Service Health Status
Check the real-time operational status of the incident management service. This endpoint provides a lightweight health check to verify that the system is responsive and functioning as expected.

It can be used in automated monitoring tools, uptime dashboards, or CI/CD pipelines to ensure that incident-related functionality (such as rule execution and webhook processing) is available.

Use cases:
  • System monitoring — Include this endpoint in health checks to validate the availability of the incident engine.
  • Pre-deployment checks — Ensure the service is live before creating or submitting incidents from automation tools.
  • Status API integrations — Use as a base-level readiness indicator for incident-related integrations.
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/health-check";

axios.get(url)
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Retrieve Incident Data
Retrieve a list of incidents associated with a specific team by providing the team_id in the path. The response includes incidents created manually or triggered through automated rulesets, allowing teams to track their current and historical incident activity.

Each incident record contains essential metadata such as id, status, urgency, created_at, and description, providing full visibility into the lifecycle and context of reported issues.

Use cases:
  • Team-level incident tracking — View all incidents assigned to or created by a specific team for monitoring and reporting.
  • Post-incident reviews — Access resolved and ongoing incidents for audit or retrospective analysis.
  • Dashboard integration — Populate custom dashboards or analytics tools with incident data filtered by team.



Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return a list of incidents associated with the specified team.
  • If the request is unauthorized, the system will return an error message.
  • If the incident is not found, a 404 error will be returned.
Path Parameters
  • id string
    The ID of the team for which incidents are being retrieved. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-query.api.pinghome.io/v1/team/c03b02ec-244f-4d2c-8f68-3910071ed5c8/incidents';

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Retrieve Incident Actions
Retrieve a list of actions associated with a specific incident by providing the incident_id in the path. These actions reflect both manual and automated responses triggered during the incident’s lifecycle — such as notifications, escalations, or status page updates.

Each action entry typically includes the type of action, the target (e.g., service or component), and timestamps indicating when the action was executed. This gives teams clear visibility into how incidents were handled in real time.

Use cases:
  • Response tracking — Understand which actions were performed during an incident and when.
  • Postmortem analysis — Review the sequence of actions to evaluate response effectiveness and timelines.
  • Audit readiness — Provide a transparent log of incident-related automation and interventions.

To view the incident this data belongs to, use the Get Incidents endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return the actions data associated with the specified incident.
  • If the request is unauthorized, the system will return an error message.
  • If the incident is not found, a 404 error will be returned.
Path Parameters
  • id string
    The ID of the incident for which actions are being retrieved. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-query.api.pinghome.io/v1/incident/c03b02ec-244f-4d2c-8f68-3910071ed5c8/actions';

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Create New Incident
Create a new incident under a specific team by providing the team_id in the path and submitting incident details in the request body. Required fields include the name of the incident, a brief description, and its urgency level (e.g., low, medium, high).

This endpoint is used for manually creating incidents that are not triggered by automated rulesets — such as those reported by users, detected through manual testing, or raised in response to unmonitored issues.

Use cases:
  • Manual incident reporting — Log issues discovered by team members or reported externally that require structured follow-up.
  • Internal escalation — Create incidents as part of internal workflows when external events do not automatically trigger them.
  • Incident simulation or testing — Manually trigger test scenarios to verify response automation, notifications, and rule behavior.

To track actions taken on this incident, use the Retrieve Incident Actions endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will create a new incident and return the incident ID.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The ID of the team for which the incident is being created. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Request Body Parameters
  • name string
    The name of the incident.
  • description string
  • urgency string
  • assignees (optional) array of objects
  • actions (optional) array of objects
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/team/445a5c1f-c0eb-403a-96d7-3976e5dc74ed/incident';
const data = {
  name: "Incident name",
  description: "Incident description",
  urgency: "medium",
  assignees: [
    {
      type: "team",
      id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed"
    }
  ],
  actions: [
    {
      type: "trigger-alerts",
      settings: [
        {
          status_page_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed",
          component_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed"
        }
      ]
    }
  ]
};

axios.post(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Update Incident
Update the details of an existing incident by providing the incident_id in the path and submitting the updated values in the request body. You can modify fields such as the name, description, and urgency to reflect changes in incident context, severity, or resolution progress.

This endpoint is useful for refining manually reported incidents, escalating their urgency, or updating information during active investigations.

Use cases:
  • Urgency escalation — Adjust an incident’s priority based on real-time impact or new insights.
  • Progress tracking — Update the description to reflect resolution steps, root causes, or status notes.
  • Incident enrichment — Add additional context such as component names or affected services as more information becomes available.

To retrieve current incident data before updating, use the Get Incidents endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will update the incident and return a success message.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The unique ID of the incident to be updated. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Request Body Parameters
  • name string
    The updated name of the incident.
  • description string
  • urgency string
  • assignees (optional) array of objects
  • actions (optional) array of objects
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/incident/445a5c1f-c0eb-403a-96d7-3976e5dc74ed';
const data = {
  name: "Incident name",
  description: "Incident description",
  urgency: "medium",
  assignees: [
    {
      type: "team",
      id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed"
    }
  ],
  actions: [
    {
      id: "",
      type: "trigger-alerts",
      settings: [
        {
          id: "",
          status_page_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed",
          component_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed"
        }
      ]
    }
  ]
};

axios.put(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Incident Schedule Management
Incident Schedule Management enables teams to organize, assign, and maintain on-call rotations to ensure timely response to incidents. It provides the ability to retrieve schedules for specific customers, create new team-based on-call schedules, update existing schedules, and remove outdated ones.

This system ensures that there is always designated coverage, reducing response delays and improving operational resilience during both business hours and off-hours.

Key capabilities:
  • Customer-specific scheduling — Retrieve on-call schedules assigned to specific customers or organizational units.
  • Team shift planning — Set up recurring or custom schedules to ensure 24/7 availability across teams.
  • Flexible updates — Adjust existing schedules to accommodate team changes, holidays, or escalations.
  • Schedule cleanup — Remove outdated or inactive shifts to keep on-call rosters current and reliable.
ENDPOINTS
Collapse all
  • On-call schedule management
    GET/customer/{id}/schedule
    POST/team/{id}/schedule
    PUT/team/{id}/schedule
    DELETE/team/{id}/schedule
Get Customer Schedules
Retrieve all on-call schedule data associated with a specific customer by providing the customer_id in the path. The response includes schedule entries that define which team members are responsible for incident response during specific time intervals.

This endpoint helps ensure visibility into who is currently on duty or scheduled for upcoming shifts, enabling seamless coordination and faster incident triage.

Use cases:
  • On-call visibility — View active and upcoming shifts for a customer to understand who is responsible during incidents.
  • Audit and reporting — Analyze historical scheduling data to verify coverage and response availability.
  • Manual coordination — Help team leads or incident managers plan shift handovers or update escalation contacts based on predefined schedules.


Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will return the schedule data, including start and end dates, months, weeks, and days of the schedule.
  • If the request is unauthorized, the system will return an authentication error message.
Path Parameters
  • id string
    The unique ID of the customer whose schedule is being retrieved. Example: 'c03b02ec-244f-4d2c-8f68-3910071ed5c8'
JavaScript
Response codes
const axios = require('axios');

const url = "https://incident-query.api.pinghome.io/v1/customer/c03b02ec-244f-4d2c-8f68-3910071ed5c8/schedule";

axios.get(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Create On-Call Schedule
Create a new on-call schedule for a team by submitting schedule configuration details in the request body. This allows you to assign specific team members to recurring or time-bound shifts based on custom rules.

The request body should include fields such as the team_member_id, start_date, end_date, and the time recurrence parameters including months_of_year, weeks_of_month, week_days, and time_range. These options provide flexible scheduling across daily, weekly, or monthly cycles.

Use cases:
  • 24/7 incident coverage — Build reliable on-call rotations to ensure someone is always available to respond.
  • Custom shift planning — Create unique patterns such as weekday-only coverage, weekend rotation, or split-shift assignments.
  • Automated scheduling infrastructure — Power internal systems with rule-based, structured on-call assignments for each team.

To retrieve existing schedules for a customer, use the Get Customer Schedules endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will create a new schedule and return a confirmation message.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The unique ID of the team for which the schedule is being created. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Request Body Parameters
  • team_member_id string
    The unique ID of the team member assigned to the schedule.
  • start_date (advanced) string
  • end_date (advanced) string
  • months_of_year (advanced) array of positive integers
  • weeks_of_month (advanced) array of integers
  • week_days array of positive integers and zero
  • start_time string
  • end_time string
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/team/445a5c1f-c0eb-403a-96d7-3976e5dc74ed/schedule';
const data = {
  team_member_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed",
  start_date: "2024-01-01T00:00:00Z",
  end_date: "2024-01-31T23:59:59Z",
  months_of_year: [1],
  weeks_of_month: [1],
  week_days: [1],
  start_time: "00:00:00",
  end_time: "23:59:59"
};

axios.post(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Update On-Call Schedule
Update an existing on-call schedule for a team by providing the team_id in the path and submitting the updated configuration in the request body. This allows you to modify both the timing and recurrence rules that define when a team member is expected to be on-call.

The request body should include fields such as team_member_id, start_date, end_date, and recurrence settings including months_of_year, weeks_of_month, week_days, and the time_range.

Use cases:
  • Schedule correction — Fix time or date ranges for an existing schedule due to entry errors or changes in availability.
  • Role reassignment — Update the assigned team_member_id to reflect staffing or rotation changes.
  • Recurrence adjustments — Modify which months, weeks, or weekdays a schedule applies to as coverage needs evolve.

To view the current schedule for reference before updating, use the Get Customer Schedules endpoint.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will update the existing schedule and return a confirmation message.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The unique ID of the team for which the schedule is being updated. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Request Body Parameters
  • team_member_id string
    The unique ID of the team member assigned to the schedule.
  • start_date (advanced) string
  • created_at string
  • end_date (advanced) string
  • months_of_year (advanced) array of positive integers
  • weeks_of_month (advanced) array of integers
  • week_days array of positive integers and zero
  • start_time string
  • end_time string
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/team/445a5c1f-c0eb-403a-96d7-3976e5dc74ed/schedule';
const data = {
  team_member_id: "445a5c1f-c0eb-403a-96d7-3976e5dc74ed",
  created_at: "2024-01-01T00:00:00Z",
  start_date: "2024-01-01T00:00:00Z",
  end_date: "2024-01-31T23:59:59Z",
  months_of_year: [1],
  weeks_of_month: [1],
  week_days: [1],
  start_time: "00:00:00",
  end_time: "23:59:59"
};

axios.put(url, data, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).
Delete On-Call Schedule
Delete an existing on-call schedule for a team member by providing the team_member_id and the created_at timestamp as query parameters. These two values uniquely identify the schedule entry that should be removed.

This endpoint is useful for cleaning up outdated shift assignments, correcting scheduling errors, or removing temporary coverage entries.

Use cases:
  • Coverage cleanup — Remove outdated or duplicate schedule entries from a team member’s on-call calendar.
  • Incorrect assignment fix — Delete a schedule entry created with the wrong timing or person assigned.
  • Temporary shift removal — Cancel a one-time or ad hoc on-call period that is no longer needed.

To modify a schedule instead of deleting it, use Update On-Call Schedule.

Authorization: Bearer YOUR_TOKEN


Expected Behavior:


  • On success, the system will delete the specified on-call schedule and return a confirmation message.
  • If the request is invalid, the system will return an error message with details of the invalid fields.
Path Parameters
  • id string
    The unique ID of the team for which the schedule is being deleted. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
Query Parameters
  • team_member_id string
    The unique ID of the team member whose schedule is being deleted. Example: '445a5c1f-c0eb-403a-96d7-3976e5dc74ed'
  • created_at string
JavaScript
Response codes
const axios = require('axios');

const url = 'https://incident-cmd.api.pinghome.io/v1/team/445a5c1f-c0eb-403a-96d7-3976e5dc74ed/schedule';

axios.delete(url, {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN'
  },
  params: {
    'team_member_id': '445a5c1f-c0eb-403a-96d7-3976e5dc74ed',
    'created_at': '2024-01-01T00:00:00Z'
  }
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error(error);
});
ResponseThis section is used to view the possible HTTP response codes returned by the API. These codes indicate the status of a request, such as 201 (Created), 401 (Unauthorized), 409 (Conflict), or 422 (Unprocessable Entity).