API reference
API reference
Every route a token may call, with its parameters, its answer and an example in several languages.
Each page shows the request, the scope it needs, the parameters, the answer with its
schema, and a sample in several languages, next to a playground that sends the call
from your browser. The pages are generated when the docs are built, from the same
OpenAPI document the API serves at https://api.inorbit.hr/openapi.json, so what you
read is what the gateway answers. How every list pages, how to retry a write and the
headers every answer carries are on Paging, retries and errors.
Trying a call
Above every playground is the token bar. Signed in, Create a test token makes a
seven-day token with every read scope and selects it, for your personal account or a
team you own or administer; signed out, sign in first or paste a token you have, from
the console or from a key's exchange (Authentication). The
selected token goes into the playground's bearer field and into every code sample, and
Send calls https://api.inorbit.hr with it, as your code would. Tokens made or
pasted here stay in this browser.
Signed in, the parameters you would otherwise look up are filled in, and each can be picked from a list or typed:
| Parameter | Filled with |
|---|---|
org_id | the account the selected token belongs to; the list holds all your accounts |
from, to | this month so far; the list offers last month and the last 30 days |
id of a digest | the latest digest; the list holds the twenty latest, asked with your token |
language, lang, before_week | left empty; the list offers the languages, the reader languages and recent weeks |
A call for an account other than the token's answers 403 forbidden; the field says so
before you send it.
Your document
GET https://api.inorbit.hr/v1/openapi.json with a bearer token answers the document
for that credential: the routes its plan has, narrowed to the scopes it holds, with only
the schemas those routes use. A signed-in person gets every route of the plan; a token
or key gets the routes its scopes name. A route a plan adds without a scope naming it is
listed for a person and left out for a token, which is what the gateway admits.
info.x-iohr-cut says what the document was cut to:
| Field | Value |
|---|---|
plan | the plan the routes come from; public on the open /openapi.json |
account | the account the document is for |
scopes | the scopes it was narrowed to, sorted; empty for a person |
hash | sha256:… over the operations and schemas with descriptions, summaries and examples left out, so a documentation edit or a version bump never moves it |
Two documents with the same hash are the same API. A person in several accounts adds
?account=<id> for a team's document, cut to that team's plan; the accounts service
decides membership, and an account the person is not in, or one a token does not belong
to, answers 403 forbidden either way. A malformed id answers 400.
The command line saves the document with iohr openapi pull and
generates a client from it: Generate an SDK for your account.
What is here
| Area | What it answers |
|---|---|
| Identity | who the caller is |
| Accounts | the account, its units this month, usage by day, and the price list |
| Radar | the weekly digests of what changed in Go, Rust and Solidity, and the items behind them |
The events that webhooks and MQTT deliver
are listed on the Webhooks page, and GET /v1/events/types answers the catalogue with a
schema per type.
A product opens to tokens and keys with scopes of its own, and the changelog names each new route.