Name the purpose
Create the token in NSD with a name that identifies its owner and job. The plaintext token is displayed once, so custody starts at creation.
API & Automation
Automate control work through one documented connection surface.
Use scoped API Tokens for the NSD administration API, signed Webhooks for lifecycle events and the unified ns binary for repeatable connection operations.
Scoped credentialsSigned eventsOne ns command surface
Automation surfacesExplicit authority
ControlAPI Tokennamed · scoped · revocable
AdministrationNSD APIcurrent documented surface
EventsWebhookfiltered · HMAC-signed
ReceiverYour HTTPS endpointverify · deduplicate · process
Runtimensup · status · down
NetworkCurrent Profileone active runtime
NSD control automation
Give each integration only the authority it needs.
API Tokens are credentials for the NSD administration API. They do not replace a user's Space, create a connection runtime or bypass the access model.
Choose the available scope
Select the narrowest scope offered by the current NSD deployment and set an expiry when the integration lifecycle calls for one.
Follow current API documentation
Use the API documentation exposed by your NSD deployment. That keeps request paths and fields aligned with the version you actually operate.
End authority deliberately
Inspect token metadata and revoke a token from NSD when its owner, system or purpose changes. Automation using that credential must then handle the failure.
Unified ns commands
The same lifecycle works at a terminal or in a script.
ns is the supported command-line surface for starting the current connection context, reading status and stopping the local runtime. Use documented flags for the version you deploy.
ns up
Register or start against the selected NSD authority and current local Profile.
ns status
Read the runtime snapshot; use JSON output when another program needs to consume it.
ns down
Stop the current local runtime before changing owners or switching to another Core.
One runtime owner
The App and CLI are separate consumers of the same local network resources; do not run competing active Cores.
ns / supported lifecycle
# register or start with the hosted NSD authority
$ sudo ns up \
--server '<signed environment>'
# control trust and ordered endpoints are discovered from /api/v1/info
# read a machine-consumable snapshot
$ ns status --json
# stop the local runtime
$ sudo ns down
Use the command reference for every additional flag.
Event-driven workflows
Use Webhooks as notifications, not hidden authority.
NSD can POST selected lifecycle and audit actions to a configured HTTPS endpoint. The receiver verifies the HMAC signature, rejects stale messages, deduplicates deliveries and decides what to do next.
Filter
Subscribe to all supported actions or limit delivery with configured action prefixes.
Verify
Keep the write-only signing secret in the receiver and validate the timestamped raw payload.
Inspect
Use recent delivery attempts in NSD to understand accepted and failed sends.
Act explicitly
A receiver may trigger your own workflow, but a Webhook event does not grant access by itself.
Outbound WebhookHMAC signed
SourceNSD eventaction · resource · outcome
EnvelopeTimestamp + signaturedelivery ID
DestinationHTTPS receiververify before processing
Delivery history is observable in NSD; downstream behavior belongs to the receiver.
Build from documented surfaces
Automate only what your current NSD and ns versions expose.
Create the narrow credential in NSD, use the deployed API documentation and keep connection scripts on the supported ns lifecycle.