Device & policy tools.
Local status and diagnostics, device registration, gateway inspection and policy retrieval exist in the checked development CLI.
Fibmesh Networks / CLI & API
Inspect devices.
Plan automation.
Understand the development CLI, the private-network API contract and the steps still needed for a complete network-management workflow.
Explore command scope Developer guide · Confirm platform and deployment support during assisted setup.01 / Understand what exists
Three layers.
Different levels of readiness.
Local tools, administrative API operations and a released management CLI are distinct deliverables.
Networks, members & routes.
The contract defines private-network creation, inspection, member addition and subnet-route addition as user-authenticated operations.
Authentication & lifecycle gaps.
A dedicated Networks command group is not implemented. The CLI login command is also a pending implementation.
These examples explain development scope. They are not a production installation or authenticated signup guide. Confirm the public endpoint, authentication, permissions and supported deployment before integrating.
02 / Start with local inspection
Read the state.
Then test the connection.
fibmesh status
fibmesh diagnosticsCommands only · no live output shown.
These commands read local identity and policy-cache state. Enrollment or cached policy does not prove a live tunnel, the latest applied policy or a reachable application.
Command reference
Expand a command to see its scope.fibmesh statusLocal inspection+
- What it does
- Reads local enrollment and cached policy details.
- What to verify separately
- Does not test a live end-to-end connection.
fibmesh diagnosticsLocal inspection+
- What it does
- Summarises local device, policy and configuration state.
- What to verify separately
- Does not establish production health or application availability.
fibmesh device registerAPI operation+
- What it does
- Submits a device registration with a public key.
- What to verify separately
- Does not provide a complete signed-in enrollment flow or prove traffic delivery.
fibmesh policy fetchAPI operation+
- What it does
- Retrieves endpoint policy, with optional local caching.
- What to verify separately
- Does not prove that the native service applied the policy successfully.
fibmesh gateway listAPI operation+
- What it does
- Requests gateway records.
- What to verify separately
- Does not install a gateway or configure site routing automatically.
fibmesh device apply-resultsfibmesh gateway apply-resultsAPI operation+
- What it does
- Inspects reported execution results.
- What to verify separately
- Does not replace a separate test of the application.
API-calling commands need an authorised environment. The checked development CLI defaults to a local API and has no finished production login flow. Keep endpoint private keys local; never include them in an API request or support ticket.
03 / Work with the contract
A network.
Its members. Its routes.
The listed operations use authenticated user access. The contract does not establish a service-account or machine-token workflow for unattended automation.
Private-network API contractAuthenticated user operations
- GET
/v1/private-networksList networks
Inspect networks within the authorised organisation.
- POST
/v1/private-networksCreate a network
Create the named private-network record.
- GET
/v1/private-networks/{id}Inspect a network
Retrieve the selected network record.
- POST
/v1/private-networks/{id}/membersAdd a member
Submit an identity or device membership.
- POST
/v1/private-networks/{id}/routesAdd a subnet route
Record a destination range and its advertising device.
Membership response
membership_acceptedConfirms the submitted administrative operation. It does not prove a complete connection.
Route record
approval_statusInspect approval, then verify policy execution and an actual resource connection.
04 / Make the result observable
A response is a step.
Verify the whole path.
Automation needs a clear scope, an observed result and a way to test the application.
Identify the intended scope.
Check the organisation, network, member and destination. Validate address ranges and existing routes before submitting a change.
Inspect the applied result.
Read returned records and endpoint or gateway reports. Check timestamps and policy versions so an older result is not mistaken for the new change.
Test allowed and denied access.
Use an approved device and a denied control. Application authentication and data permissions remain separate from network reachability.
05 / Before depending on automation
Plan the change.
And the way back.
- Current contract gaps
- The checked network API does not expose a complete edit, member-removal, route-removal or network-deletion lifecycle. An archived field does not make an archive operation available.
- Assisted withdrawal
- Agree the supported operator procedure for withdrawing access, retiring devices and removing routes. Verify applied state and application sessions after removal.
- Future CLI requirements
- A complete network CLI needs verified authentication, explicit create, inspect, join, leave, route-change and removal operations, readable output and structured results. These are proposed capabilities, not runnable commands or promised release dates.
General diagnostics, an API contract and a released network-management CLI remain distinct. Confirm the supported lifecycle before relying on a production automation workflow.
Prepare a deployment & verification plan →Put the reference to work
Plan the integration.
Verify the connection.
Start with the supported deployment and authentication flow. Confirm how changes are applied, tested and withdrawn before expanding the workflow.