Introduction

Welcome to the Tokenet External API documentation.

The Tokenet External API lets automated clients — trading bots, reporting
pipelines, and any system-to-system integration — interact with Tokenet
programmatically. Instead of the browser-based login flow, the API uses
long-lived Ed25519 API keys: every request is signed with your private
key and verified by the server, with no passwords, sessions, or token
refreshes involved.

Key properties of the API:

Stateless — each request is independently verifiable; no token refresh needed.

Replay-resistant — a monotonic timestamp nonce prevents request replay.

Scope-limited — each credential is bound to a role that limits which operations it can perform.

Auditable — every credential event and authenticated request is recorded in an audit log.

Getting Started

Obtain an API credential. Credentials are issued by your organisation
admin through the credential management endpoints. The creation response
contains your public_key, your private_key, and the credential id.

Save the private key immediately. It is shown exactly once and never
stored on the server. If you lose it, the credential must be rotated to
generate a new key pair. Keep it in a secrets manager or environment
variable — never in version control.

Sign your requests. Each request carries three headers —
X-API-Key, X-Timestamp-Ms, and X-Signature — where the signature is
computed over a canonical METHOD|PATH|VARIABLE|TIMESTAMP_MS payload with
your Ed25519 private key. See the Signing a Request section for the full
protocol and ready-to-use client examples in Go, Python, and TypeScript.

Discover available endpoints. The machine-readable list of all routes available to this documentation.

Base URL:

https://tokenet-ng-api.digitalprimetechnologies.co/

Authorization

Every API credential is bound to an account and a role (e.g.
execution, viewer). The role determines exactly which operations the
credential may perform — requests outside its scope are rejected with
403 insufficient permissions. Follow the principle of least privilege:
request a role with the minimum permissions your integration needs, and use
separate credentials for separate systems and environments.

A credential is accepted only while it is active. Requests are rejected
with 401 if the credential has been disabled or revoked, if its expiry
date has passed, or if the request signature or timestamp fails validation.
Credentials can be rotated at any time without changing their ID, role, or
permissions — this is the recommended response to a suspected key leak.

Note: if a request also carries an Authorization: Bearer <token> header,
JWT authentication takes precedence and the API key headers are ignored.

Support & Feedback

We'd love to hear from you. If you run into issues, have questions about
integration, or want to suggest improvements to the API or this
documentation:

Email: support@digitalprimetechnologies.com

When reporting an issue, please include the request path, the HTTP status
code, the detail field from the error response, and a timestamp — this
helps us trace the request in our logs quickly. Never include your private
key in a support request.

Getting Started#

Authorization#

Support & Feedback#

Getting Started

Authorization

Support & Feedback