Skip to main content

Instatus Data Source

The Instatus connector enables you to ingest status page data — including incidents, components, maintenances, subscribers, metrics, and more — into Nexla for analysis, reporting, or integration with downstream systems. Follow the instructions below to create a new data flow that ingests data from an Instatus source in Nexla.
instatus_api.png

Instatus

Create a New Data Flow

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

  2. Select the Instatus connector tile from the list of available connectors. Then, select the credential that will be used to connect to the Instatus instance, and click Next; or, create a new Instatus credential for use in this flow.

  3. In Nexla, Instatus data sources can be created using pre-built endpoint templates, which expedite source setup for common Instatus endpoints. Each template is designed specifically for the corresponding Instatus endpoint, making data source setup easy and efficient.
    • To configure this source using a template, follow the instructions in Configure Using a Template.

    Instatus sources can also be configured manually, allowing you to ingest data from Instatus endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this source manually, follow the instructions in Configure Manually.

Configure Using a Template

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Instatus endpoints. Each template is designed specifically for the corresponding Instatus endpoint, making data source setup easy and efficient.

Endpoint Settings

  • Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

    List Page Components

    Returns all components for a specific status page. Use this endpoint to retrieve the individual service or system components displayed on an Instatus status page for monitoring or reporting.

    • Issues a GET request to https://api.instatus.com/v1/{'{page_id}'}/components. Returns a top-level JSON array of component objects.
    • Response data path: $[*] — each array element is one component record. Configure the Page ID parameter with the ID of your Instatus status page.

    You can find your status page ID by first calling the Get Your Status Pages endpoint (GET /v2/pages) and copying the id value from the response.

    List Incidents

    Returns all incidents for a specific status page. Use this endpoint to ingest incident history for SLA reporting, post-mortem analysis, or integration with alerting and ITSM systems.

    • Issues a GET request to https://api.instatus.com/v1/{'{page_id}'}/incidents. Returns a top-level JSON array of incident objects.
    • Response data path: $[*] — each array element is one incident record. Configure the Page ID parameter with your status page ID.

    This endpoint returns all incidents across all statuses (investigating, identified, monitoring, resolved). Use the Get Page Incidents endpoint if you need to filter by incident status.

    List Incident Updates

    Returns all status updates posted to a specific incident. Use this endpoint to ingest the full timeline of updates for an incident for detailed incident reporting or audit trails.

    To iterate over updates for multiple incidents, use a Nexla lookup-based macro to pass incident IDs from a previous source into this endpoint's URL dynamically.

    List Maintenances

    Returns all scheduled maintenance events for a specific status page. Use this endpoint to ingest maintenance windows for change management reporting or calendar integration.

    Maintenance events include both upcoming and completed windows. Use this endpoint to build a historical log of all maintenance activity on your status pages.

    List Maintenance Updates

    Returns all status updates posted to a specific maintenance event. Use this endpoint to retrieve the detailed update timeline for a maintenance window.

    Use a lookup-based macro to dynamically pass maintenance IDs from a List Maintenances source to iterate over updates for all maintenance events in a single data flow.

    List Templates

    Returns all incident and maintenance update templates for a status page. Use this endpoint to export your pre-defined communication templates for documentation or replication across pages.

    Templates define pre-written messages for common incident and maintenance update scenarios. Exporting them allows you to audit or replicate your communication standards across multiple status pages.

    List Team Members

    Returns all team members in the Instatus account. Use this endpoint to audit user access or export your team roster for HR and access management reporting.

    • Issues a GET request to https://api.instatus.com/v1/team. Returns a JSON object with a team array.
    • Response data path: $.team[*] — each element of the team array is one team member record.

    This endpoint returns account-level team members, not page-specific subscribers. The response is a JSON object rather than a top-level array, so the path to data must be set to $.team[*].

    List Subscribers

    Returns all subscribers to a specific status page. Use this endpoint to export subscriber lists for analysis, backup, or migration to other notification systems.

    Subscriber data may include email addresses and phone numbers. Ensure that any downstream handling of this data complies with applicable privacy regulations (e.g., GDPR, CAN-SPAM).

    List Metrics

    Returns all metrics tracked on a specific status page. Use this endpoint to ingest uptime and performance metric definitions for reporting or integration with monitoring dashboards.

    This endpoint returns metric definitions and metadata, not the raw datapoints. Use it to inventory which metrics are tracked on each page before ingesting historical metric data.

    Get Current User

    Retrieves the profile information for the currently authenticated Instatus user. Use this endpoint to verify authentication or capture account metadata for auditing purposes.

    • Issues a GET request to https://api.instatus.com/v1/user. Returns a single JSON object representing the authenticated user's profile.
    • Response data path: $ — the entire response is treated as a single record.

    This endpoint is useful as a connectivity test to verify that the configured Instatus credential is valid and active before running more complex data flows.

    Get Public Status Data

    Retrieves the public status summary for an Instatus status page in JSON format. Use this endpoint to ingest publicly available status page data without authentication for external monitoring integrations.

    • Issues a GET request to https://{subdomain}.instatus.com/summary.json. Returns a JSON object with the current page status, components, and active incidents.
    • Response data path: $ — the entire summary object is treated as a single record. Configure the Page Subdomain parameter with your status page subdomain.

    This endpoint does not require an API key — it accesses the public summary data that visitors to your status page can see. It is useful for monitoring your own page's public status or aggregating status data from multiple pages.

    Get Your Workspaces

    Retrieves all workspaces for the authenticated Instatus user. Use this endpoint to inventory your Instatus workspace configuration or to retrieve workspace IDs for use in downstream operations.

    Workspace IDs are used to scope certain Instatus API operations. Use this endpoint to retrieve workspace metadata before configuring workspace-scoped sources or destinations.

    Get Your Status Pages

    Retrieves all status pages in the Instatus account. Use this endpoint to inventory your status pages and retrieve page IDs needed to configure other page-scoped endpoints.

    • Issues a GET request to https://api.instatus.com/v2/pages. Returns a top-level JSON array of status page objects.
    • Response data path: $[*] — each array element is one status page record.

    This is typically the first endpoint to call when setting up Instatus integrations — it returns the page IDs required by all other page-scoped endpoints such as List Incidents, List Components, and List Subscribers.

    Get Page Incidents

    Returns a paginated list of incidents on a specific status page with optional filtering by incident status. Use this endpoint when you need to retrieve only incidents in a particular state, such as all active or resolved incidents.

    • Issues a GET request to https://api.instatus.com/v1/{'{page_id}'}/incidents. Returns a JSON object with an incidents array.
    • Response data path: $.incidents[*] — each element of the incidents array is one incident record. Configure the Id (page ID) and optionally the Incident Status filter parameters.

    Unlike the List Incidents endpoint, this endpoint wraps results in an incidents key and supports status filtering. Use the Incident Status parameter to filter by values such as INVESTIGATING, IDENTIFIED, MONITORING, or RESOLVED.

    Get an Incident

    Retrieves the full details of a single incident by its ID. Use this endpoint to fetch complete incident records including all update history and affected components.

    Use a lookup-based macro to dynamically pass incident IDs from a List Incidents source to fetch full detail records for each incident in a chained data flow.

    List Components

    Returns a paginated list of all components on a specific status page. Use this endpoint when you need component data with pagination support for large component lists.

    • Issues a GET request to https://api.instatus.com/v1/{'{id}'}/components. Returns a JSON object with a components array.
    • Response data path: $.components[*] — each element of the components array is one component record. Configure the Id (page ID) parameter.

    This endpoint uses the $.components[*] path, unlike the List Page Components endpoint which returns a top-level array. Confirm the correct path when configuring this source to ensure all component records are properly parsed.

Endpoint Testing

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually

Instatus sources can also be configured manually, allowing you to ingest data from Instatus endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.

First, select the method that will be used for calls to the Instatus API from the Method pulldown menu. The most common methods are:

  • GET: For retrieving data from the API (most common for data ingestion)
  • POST: For sending data to the API or triggering actions
  • PUT: For updating existing data
  • PATCH: For partial updates to existing data
  • DELETE: For removing data

API Endpoint URL

  1. Enter the URL of the Instatus API endpoint from which this source will fetch data in the Set API URL field. This should be the complete URL including the protocol (https://) and any required path parameters.

    The Instatus API base URL is https://api.instatus.com. Common endpoints for data ingestion include:

    • Status Pages: https://api.instatus.com/v2/pages — Retrieve all status pages in your account
    • Components: https://api.instatus.com/v1/{page_id}/components — List all components for a status page
    • Incidents: https://api.instatus.com/v1/{page_id}/incidents — List all incidents for a status page
    • Maintenances: https://api.instatus.com/v1/{page_id}/maintenances — List all scheduled maintenances
    • Subscribers: https://api.instatus.com/v2/{page_id}/subscribers — List all subscribers
    • Metrics: https://api.instatus.com/v1/{page_id}/metrics — List all metrics
    • Templates: https://api.instatus.com/v1/{page_id}/templates — List incident/maintenance templates
    • Team Members: https://api.instatus.com/v1/{page_id}/team — List teammates on the status page
    • User Profile: https://api.instatus.com/v1/user — Retrieve the authenticated user's profile

    Replace {page_id} in the above URLs with the ID of your Instatus status page. You can find your page ID by first calling https://api.instatus.com/v2/pages and copying the id value from the response.

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL. All Instatus API requests require a valid API key — confirm that your Instatus credential is correctly configured before testing.

Date/Time Macros (API URL)

Optional

Optionally, the API URL can be customized using macros — all macros added to the API URL will be converted into values when Nexla executes the API call. Macros are dynamic placeholders that allow you to create flexible API endpoints that can adapt to different time periods or data requirements.

Macros are particularly useful for Instatus endpoints that accept date range parameters, such as filtering incidents or maintenance windows by time period.

  1. To add a macro, type { at the appropriate position in the API URL (within the Set API URL field), and select the desired macro from the dropdown list.

    • {now} – The current datetime
    • {now-1} – The datetime one time unit before the current datetime
    • {now+1} – The datetime one time unit after the current datetime
    • custom – Datetime macros can reference any number of time units before or after the current datetime — for example, enter (now-4) to indicate the datetime four time units before the current datetime
  2. Select the format that will be applied to datetime macros from the Date Format for Date/Time Macro pulldown menu. This format will be applied to the base datetime value of the macro — i.e., the value of {now} in {now-1}.

  3. Select the datetime unit that will be used to perform mathematical operations in the included macro(s) from the Time Unit for Operations pulldown menu — for example, for the macro {now-1}, when Day is selected, {now-1} will be converted to the datetime one day before the current datetime.

Lookup-Based Macros (API URL)

Optional

Column values from existing lookups can also be included as macros in the API URL. Lookup-based macros allow you to reference data from previously configured data sources or lookups, enabling dynamic API endpoints that can adapt based on existing data.

Lookup-based macros are useful for Instatus workflows where you need to iterate over multiple status pages or incidents — for example, using a page ID retrieved from one Nexla source to drive requests to a downstream Instatus endpoint.

  1. To include a lookup column value macro, select the relevant lookup from the Add Lookups to Supported Macros pulldown menu.

  2. Type { at the appropriate position in the API URL, and select the lookup column-based macro from the dropdown list. Lookup-based macros are automatically populated into the macro list when a lookup is selected in the Add Lookups to Supported Macros pulldown menu.

Path to Data

Optional

If only a subset of the data that will be returned by the API endpoint is needed, you can designate the part(s) of the response that should be included in the Nexset(s) produced from this source by specifying the path to the relevant data within the response. This is particularly useful when Instatus API responses contain metadata, pagination information, or other data that you don't need for your analysis.

For example, when calling the Instatus incidents endpoint, the API typically returns a top-level array of incident objects. By specifying the correct JSON path, you can configure Nexla to treat each incident object as an individual record.

Path to Data is essential when Instatus API responses have nested structures. Without specifying the correct path, Nexla might not be able to properly parse and organize your data into usable records.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format, enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (e.g., $.data.items[*] to access an array of items within a data object).

    • For responses in XML format, enter the XPath that points to the object/array containing relevant data. XPath uses slash notation (e.g., /response/data/item to access item elements within a data element).

    Path to Data Example:

    Most Instatus API list endpoints return a top-level JSON array. For example, calling GET /v1/{page_id}/incidents returns an array of incident objects. If the response is structured as a JSON array at the root, no path may be needed — or enter $[*] to reference all items in the array.

Autogenerate Path Suggestions

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve important contextual information — such as the status page ID or total record count — that applies to all records but isn't part of the main data array.

Metadata paths are particularly useful for preserving Instatus API response context like request IDs, pagination cursors, or summary statistics that apply to all records in the response.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata, and for responses in XML format, enter the XPath.

Request Headers

Optional
  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2). The Instatus API requires all requests to use Content-Type: application/json — this header is typically handled automatically by Nexla based on the credential configuration.

    You do not need to include the Authorization header or Content-Type: application/json header here — these are automatically included by Nexla based on your Instatus credential configuration.

Endpoint Testing

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new Instatus data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.