Quickstart

One request for a key, one request for an answer. Nothing waits for a person.

1. Get a key

Onboarding is self-service. You can use the form on the Beta page, or the same call directly — it is the same endpoint and the same handler.

# Choose your networks and products. Both are refused if empty:
# an empty selection means none rather than all.
curl -X POST https://api.stonereason.com/v1/onboard \
  -H 'content-type: application/json' \
  -d '{
    "email": "[email protected]",
    "project_name": "My project",
    "environment": "TEST",
    "networks": ["base"],
    "products": ["XRPC_NODE", "XRPC_WALLET"],
    "key_name": "default"
  }'

A 201 comes back with the key:

{
  "project_id":   "prj_000001",
  "key_id":       "xck_0000_000000",
  "key_secret":   "<shown once>",
  "secret_note":  "shown once. There is no way to see it again, by design",
  "capabilities": ["balance.get", "network.capabilities", "network.status"],
  "networks":     ["base"]
}

If you are refused

Asking for a product the catalogue cannot serve on the networks you chose is refused at signup:

{
  "code": "INVALID_REQUEST",
  "message": "none of the products you chose is available on the networks
              you chose. The product catalogue says which are"
}

That is the fail-closed catalogue working. In Free Beta, XRPC_NODE and XRPC_WALLET are available on six EVM networks; the other products have no commercially available methods yet. See Networks.

2. Make a request

Every Access call is a POST to /v1/rpc with a method, a network, and the method's arguments at the top level.

curl -X POST https://api.stonereason.com/v1/rpc \
  -H "authorization: Bearer $XRPC_KEY" \
  -H 'content-type: application/json' \
  -d '{ "method": "network.status", "network": "base" }'

3. Read the answer

The envelope is always the same shape: an outcome, the answer, and what the answer is worth.

{
  "outcome": "ANSWERED",
  "network": "base",
  "method":  "network.status",
  "product": "XRPC_NODE",
  "answer": {
    "engine":    "base-micronano",
    "lifecycle": "UNINITIALIZED",
    "finality":  "PENDING"
  },
  "trust": {
    "trust_class":    "UNVERIFIED_RAW",
    "evidence_basis": "SERVICE_LOCAL",
    "coverage":       "SINGLE_POINT",
    "read_context":   "SINGLE",
    "floor_met":      true
  },
  "latency_ms": 3
}

What each part is telling you

• outcome — ANSWERED (200), PARTIAL_COVERAGE (206, real but incomplete), or NO_SAFE_ROUTE (422, nothing met the floor so nothing is returned).
• trust_class — how strongly this is established. UNVERIFIED_RAW means a source said so and XRPC did not check it.
• evidence_basis — what supports it. SERVICE_LOCAL means XRPC's own state, read without contacting any source. It is a real answer about the engine, not an observation of the chain.
• coverage — how much of the question was looked at, independently of how well it is trusted.
• read_context — which view of the chain. There is no latest_block.
• floor_met — whether your requested floor was satisfied. If you asked for none, this is true.

Read the trust model before you act on any of these values.

4. Stay inside your scope

A key reaches the networks and capabilities it was issued for. Anything else is refused, and the refusal points at the key rather than at your project:

{
  "code": "OUT_OF_SCOPE",
  "message": "the key is valid and does not reach this network, capability,
              transport or environment. Look at the key's scope rather than
              at your project"
}

5. Next

• Authentication — scopes, environments and rotation.
• Payments — open a session and reconcile it.
• Errors — every refusal shape you can get.