REST API¶

Everything the UI manages is available under:

/api/plugins/peering-manager/

The endpoints are standard NetBox model endpoints. Authentication, pagination, ?brief=true, bulk create / update / delete, tag and custom field handling, and object permissions all work as described in the NetBox REST API documentation. This page lists only what is specific to the plugin.

Endpoints¶

Field meanings are on the Models page.

Filters¶

Every list endpoint accepts q for free-text search plus the standard NetBox filters (id, tag, created, last_updated, ...). The plugin-specific filters are:

status takes active, planned, or decommissioned and can be repeated to match several values.

# Sessions on one peering network
curl -H "Authorization: Token $NETBOX_TOKEN" \
  "https://netbox.example.com/api/plugins/peering-manager/peering-session/?peering_network_id=7"

# Your routers' attachments on a device
curl -H "Authorization: Token $NETBOX_TOKEN" \
  "https://netbox.example.com/api/plugins/peering-manager/peering-connection/?device_id=42"

Things that differ from the UI¶

• irr-source/ names the fastbgpq4 URL api_endpoint. In API responses url is, as everywhere in NetBox, the link to the object itself. Read and write the fastbgpq4 base URL through api_endpoint.
• peering-fabric/ exposes PeeringDB data read-only. The peeringdb field returns the fabric's cached IX record, or null for an unlinked fabric. The link cannot be created or changed through the API; use the fabric edit form or the shell.
• Sync operations are not exposed. Neither PeeringDB sync nor IRR sync has an API action. Use the UI, the management command, or the shell snippets in IRR prefix lists.
• The PeeringDB peer cache has no endpoint.

Creating a peering session¶

Related objects are passed by ID. The BGP peer must already exist in netbox-routing and must not already have a peering session.

curl -X POST https://netbox.example.com/api/plugins/peering-manager/peering-session/ \
  -H "Authorization: Token $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "bgp_peer": 118,
        "relationship": 3,
        "peering_network": 7,
        "service_reference": "NOC-12345"
      }'

relationship and peering_network are optional and accept null.

render-config¶

POST /api/plugins/peering-manager/render-config/

Renders a NetBox Config Template against the peering context of a device or of specific sessions. The context is described in Configuration templating.

Request body¶

How the two combine is described under which sessions are rendered.

Query parameters¶

Response¶

The format follows the Accept header.

Accept: application/json (default):

{
  "configtemplate": {"id": 7, "url": "...", "display": "junos-bgp", "name": "junos-bgp"},
  "content": "protocols {\n    bgp {\n ...",
  "device": {"id": 42, "name": "rt1.mtl"},
  "session_count": 12
}

device is present only when a device was given. The nested configtemplate object is NetBox's brief representation and may carry additional fields depending on the NetBox version.

Accept: text/plain: the rendered configuration as the raw response body, with no metadata.

Errors¶

Access control¶

The endpoint requires an authenticated request and nothing more: it does not evaluate NetBox object permissions on the template, the device, or the sessions. Rendered output and the include_context dump contain BGP passwords. Issue API tokens accordingly.

GraphQL¶

Each model also has a single-object and a list query on the NetBox GraphQL endpoint, named netbox_peering_manager_<model> and netbox_peering_manager_<model>_list:

{
  netbox_peering_manager_peering_session_list {
    id
    service_reference
    relationship { name }
    peering_network { name fabric { name } }
  }
}

Available model names: relationship, peer_asn, peering_session, peering_fabric_type, peering_fabric, peering_network, peering_connection, irr_source, irr_prefix_list_config. See the NetBox GraphQL documentation for querying and filtering conventions.