SDK Node
Embedded in the Node Gateway. Runs your operation against the protocol — dispatch, payments, and events, signed end to end.
retries + backoffidempotency
Developers · build on the network
Build on the network.
TechnoRides is, first of all, a protocol. If your product needs to move people or things — or coordinate who moves them — you talk to the whole network through one interface.
ProtocolSDKsAgent APIMerchant API
DOCProtocolOrders, events, routing, reputation, payments
SDKTyped clientsNode · agent · merchant, with retries
APIAgent APIRequest, offer, or orchestrate drivers
APIMerchant APIDispatch last-mile orders
Each entry point speaks the same protocol — one contract, four doors.
Build status. The network plane — registry, ledger, roaming, and the protocol (M06) — is on the roadmap and shown here as a target specification, not a live service. The SDKs, the simulated node, and the conformance suite are in build; package names and identifiers below are illustrative.
The portal · M06 · roadmap
One reference, one playground, one contract.
Read the protocol on the left, try a request in the playground on the right. Every SDK is a typed client over these same contracts — so what you read is what you call.
Protocol RouteOrderRequest
Route an order across the network
Submit one RouteOrderRequest and the network resolves the destination node by geography, service type, and node state — public, versioned, demonstrably neutral routing. The response is an Order you can track with TripStatusEvent.
Endpoints
POST/v1/routeResolve and dispatch an order
GET/v1/orders/{order_id}Fetch order & latest status
GET/v1/orders/{order_id}/eventsStream TripStatusEvent
Try it — playground
RESTsdk-nodesdk-agent
Request · idempotent by order_id
POST/v1/route
servicecar
pickup37.7790,-122.4170
dropoff37.7649,-122.4194
order_idord_9f3a-2c
Response
200 OK 142 ms · sandbox
{
"order_id": "ord_9f3a-2c",
"status": "routed",
"node": "sf-yellow",
"service": "car",
"dispatch": {
"driver_id": "drv_44a",
"eta_min": 3
},
"fare_estimate": "18.40",
"events_url": "/v1/orders/ord_9f3a-2c/events"
}// Playground runs against a simulated node, not production. Endpoints, fields, and the sandbox are part of the in-build protocol (M06) — illustrative, not a live API.
The protocol · M06 · roadmap
The common contract: orders, events, routing, payments.
A small set of typed resources, signed and versioned, that nodes, agents, and merchants all speak. Same shapes everywhere — that's what turns a set of apps into a network.
Resources
OrderTripStatusEventRouteOrderRequestReputationEventPaymentEventHeartbeatDispatchAuthorizationCredential
AuthmTLS between nodes and registry · per-message signatures for ledger events · API keys + OAuth with scopes for agents and merchants
VersioningSemantic · negotiated in the handshake · two active versions during major-change migration windows (≥ 90 days)
Routing rulesPublic & versioned · destination resolved by geography, service type, and node state · demonstrable neutrality
A typed contract for every interaction.
An Order carries who moves what, where. A TripStatusEvent reports progress. A RouteOrderRequest asks the network to resolve the right node, and signed ReputationEvent and PaymentEvent records keep the ledger trustworthy. Heartbeat and DispatchAuthorization govern the node lifecycle; a Credential proves a verified driver.
01
Sign every ledger event
Reputation and payment events carry per-message signatures, so the trail is auditable end to end.
02
Negotiate the version in the handshake
Two majors run side by side through a published window — no flag day, long migration runways.
03
Route on public, neutral rules
Destination is resolved by geography, service type, and node state — versioned in the open, demonstrably neutral.
In build. The protocol, its resources, authentication, and routing rules are on the roadmap and shown as a target specification, not a live service. Identifiers and version numbers are illustrative.
SDKs
Typed clients for node, agent, and merchant.
Three SDKs map to the three audiences that speak the protocol — typed clients over the same contracts, retries with backoff, idempotency by order_id, signed webhook handling, and an example per use case. At least two languages in the first release.
SDK Agent
For an AI agent to request, offer, or orchestrate drivers. Wraps the Agent API with scoped OAuth and signed webhooks.
scoped OAuthsigned webhooks
SDK Merchant
For a merchant to dispatch last-mile orders. Typed order creation, status events, and settlement, idempotent by order id.
last-mileidempotency
# install the typed client
npm i @technorides/sdk-node
# route an order against the simulated node
const order = await node.route({
service: "car",
pickup: [37.7790, -122.4170],
dropoff: [37.7649, -122.4194],
order_id: "ord_9f3a-2c" // idempotency key
});In build. The SDKs, the simulated node, and the conformance suite are not yet released. Package names and the code above are placeholders.
Principles
Open, but trustworthy.
Three commitments shape how you build on the network — openness with verification, serious versioning, and a sandbox that proves your integration before it touches production.
Open but trustworthy
The protocol is open. Driver admission always passes identity verification — the network stays open without becoming anonymous.
Serious versioning
Backward compatibility within the major version, and long migration windows. A breaking change never strands a node mid-flight.
Sandbox
A simulated node lets you certify your integration before production. Build and test against real contracts with zero live risk.
Status
What ships today, what's on the roadmap.
The operation plane ships now; the network plane — registry, ledger, roaming, and the protocol — is in build. Here's the honest state of each surface you'd integrate against.
Operation plane
Live
Shipping
Protocol · M06
v1 draft
Roadmap
SDKs
2 langs
In build
Conformance suite
Planned
Roadmap
Honest status. Versions and language counts above are illustrative targets for the in-build network plane (M06) — not a live status page. The operation plane (node, apps, dispatch, payments, tracking) is what ships today.
Get started
From credentials to certified, in four steps.
Request sandbox credentials, install the SDK, run the example against the simulated node, and certify with the conformance suite before you go to production.
01
Request sandbox credentials
Get scoped keys for the simulated node — no production access, no live risk while you build.
02
Install the SDK
Add the typed client for your audience — node, agent, or merchant — with retries and idempotency built in.
03
Run the example against the simulated node
Route an order end to end against real contracts in the sandbox, and watch the status events stream back.
04
Certify with the conformance suite
Pass the automated suite to prove your integration honors every contract — the gate to production.
In build. The sandbox, the simulated node, and the conformance suite are on the roadmap. This get-started flow describes the target onboarding, not a live process today.
Get started
Build on the network.
One interface to the whole network — read the protocol, install an SDK, and certify against the conformance suite. Talk to people, things, or the agents that coordinate them, through a single contract.