Mosaic CP API Guide
Loading documentation…
logo

Mosaic CP API Guide

Introduction

This guide describes the process of Operations Support System (OSS) provisioning of the ADTRAN® Mosaic Cloud Platform (Mosaic CP). An OSS consists of application(s) software that operates within a carrier’s management network and allows their systems to perform network management functions for a variety of operational support systems. This guide provides a dictionary of supported Application Programming Interface (API) commands used to complete Mosaic CP provisioning.

The Mosaic CP RESTCONF Northbound Interface (NBI) provides a programmable interface between the OSS and the associated network elements. Integration with the Mosaic CP API provides operators with a consistent and repeatable command structure across a multitude of deployment architectures.

The figure below illustrates the interactions between the OSS and Mosaic CP. The network elements will vary according to the deployment.

The main sections that make up this guide are as follows:

  • Administration: covers tasks expected to be performed by an administrator, such as how to get an API token, add/remove users, reset passwords, add device credentials, setup policies and more.
  • Events: covers APIs to retrieve events from the system and forward events to external systems such as a Kafka listener.
  • Jobs: using Mosaic CP to create, run, and check the status of jobs.
  • Platform Details: get the status of Mosaic CP as well as information about software versions and enabled features.
  • Orchestration Objects: this section covers using Mosaic CP as an SDN orchestrator.
  • Search and Filter: how to search for objects on the system and filter those searches based on various attributes of those objects.

Note on OpenAPI Extension Fields

This specification uses two custom OpenAPI extension fields:

x-hierarchy

Present on every operation. Each entry is the slug of an example that appears
in BOTH requestBody.content..examples AND responses..content.*.examples under
the same key, so the HTML generator can display the matched request+response pair.

Structure
x-hierarchy:
: # unique short tag name
- # slug present in requestBody + response examples
- # different example under same folder
- request-name: # for requests with no saved responses
response-name: NA
: # only present in merged ops spanning multiple folders
- ...

The folder name is the unique short tag — full hierarchy is recoverable via the
tags[].parent chain in the top-level tags list.

x-merged

Present (value: true) only on operations where multiple Postman requests sharing
the same URL and HTTP method were merged into a single OpenAPI operation.

← Select an endpoint from the sidebar to view its details.