Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Apstra Rest API Explorer

Juniper Apstra REST API Explorer provides a GUI for testing REST API endpoints, eliminating the need for coding expertise. While Apstra IBA probes collect fabric signals, some users might not have GUI access. Developers can retrieve probe results programmatically and integrate these results into:

  • Dashboards

  • Ticketing systems

  • Configuration management databases (CMDBs)

  • Chat platforms

  • Reports

REST API Explorer helps discover and test endpoints live within a blueprint without disrupting the network. This tool acts as a live playbook for executing requests and receiving responses.

To launch Apstra REST API Explorer:

  1. From the Apstra GUI, navigate to Platform > Developers and click the REST API Explorer Page link.
  2. Enter the keyword query to filter the API endpoints.
    The query API is a POST endpoint that retrieves the status of any probe stage. The query API functions as a POST endpoint that retrieves the status of any probe stage. Entering "query" displays multiple API endpoints in across folders, which makes it unclear to users which one to select. The "query" API supports audit events, probes, and metricdb. Because endpoints span multiple folders, we need to apply a filter to retrieve the results for the analytic processors we created in the Probe section for BFD running on our blueprint. See: Create an IBA Probe and Processor.
  3. Enter the keyword probe in the search field.
    The "probe" keyword filter generates results across multiple API endpoints. We are focusing on "query" endpoints under the blueprint level to locate an endpoint. This specific endpoint functions as the "query" API for all probes. Use this hierarchy to find the endpoint: blueprints > {blueprint_id} > probes {probe_id} > query (POST)

    The "query" API POST endpoint retrieves a probe stage's status. This endpoint includes two parameters: Request Parameters and Response Parameters. The Request Parameter defines the request schema and consists of the URI (URL path) and body. Note that not all endpoints have a body, but this POST endpoint does.

    The following table describes the Request Parameters.

    Table 1: Request Parameters Descriptions
    Request Parameter Description
    URI Contains the path and query. The path specifies the host URL and identifies the resource, using blueprint_ID and probe_id.
    blueprint_ID Automatically resolves the blueprint_id label to an ID. This field is mandatory.
    probe_ID Automatically resolves the probe_id label to an ID. This field is mandatory.
    offset, page, per-page (Optional) Query parameters included in the URI text.
    body Second part of the request parameter in the POST API. Includes the "stage" (mandatory) and optional fields. The "stage" field specifies the status of a stage in a probe.
  4. Specify the Request Parameters
    1. Select your blueprint name from the drop-down menu in the Request Parameters section and select the probe. We'll use the probe BFD Monitoring.
    2. Set the mandatory field, "stage" to Down_BFD_Sessionsunder Values in the body section.
      Include the optional field anomalous_only and set its value to true. This parameter explicitly retrieves data for BFD sessions that are down and have a Boolean anomaly value of true.
  5. Run the query.
    Click Try It to get the response.
  6. Navigate back to Blueprints > Analytics > Probes and select your probe. From the output stage Down_BFD_Sessions, check the Anomalies Only box to generate the output for Down_BFD_Sessions.
    The image below shows six entries. The Value column indicates that the Anomaly value is set to true. In REST API explorer, we entered the same query by setting the body value to Anomalous_only: true.

    The API query response includes a code 200, confirming that the system accepted the request and provided a response. The image below summarizes the response, structuring it as a dictionary containing seven items, including description and type.

    This dictionary contains a list of six items and details six neighbors that are down. Each item includes another dictionary with four items that describe the timestamp, value, and ID. The anomaly status is set to true, matching with the filter applied in the API query (anomalous_only: true). These four items contain a nested dictionary with six properties: system_id, Remote_IP, Link,Local_address, Local_Interface, and Remote_Interface, along with their respective values.

    The response provides details about the six BFD sessions where the anomaly value is true, confirming that these six neighbors are down.

The API query response lists the "value" key. The "value" key holds the Boolean value "true" in six occurrences. The properties provide details on all six BFD sessions that are down.

With this example, we showed how to use the Apstra REST API to retrieve probe output, interpret the response payload, and translate it into an actionable summary. This summary identifies six BFD sessions with a Down ("true") status and their associated properties. The pattern enables teams to automate scheduled reports, integrate the data into ticketing or observability tools, and adopt a repeatable, UI-independent approach to present fabric status to stakeholders.