Sign in

ProductConnect

Connectionsin part

Link GitHub and other tools by API key or sign-in

Your tools, connected once, feeding the same evidence.

Connect an account's incident, chat, code, enterprise and AI tools once, with a key or by signing in, and see and reconnect them in one place. Every product of the platform acts on them only through a person's grant. A new connection needs no change to the platform itself; each saying what kind of evidence it gives is planned. Some run today; most are still coming.

Partly live; each line below says which part. A 30-minute call is the way in.

01The problem

Every tool gets its own integration, its own credentials and its own idea of permissions. Nobody can see in one place what is connected and what it may do.

02How it works

You connect a tool once and every product can use it, but only as far as a person has allowed.

How it works

01

Where it runs

On the platform. You connect from the console with a key or by signing in with the provider, and see and reconnect everything in one place.
02

What it reads

Only what the granted actions need. What a connected tool answers is treated as data, never as instructions.
03

What you approve

Each grant, by name: a person grants the named actions a product may take through a connection.
01ConnectA key, or sign in with the provider.preview
02GrantA person grants named actions.preview
03Products actVerify, incidents, Atlas, your keys.in part
04EvidenceEach declares what it can prove.in development
From your tool to evidence the platform can use
03What you getin part

Each line says how far it is built today. Live means anyone with an account uses it; preview means it runs in early access or as a pre-release; coming means it is written down and not built yet.

What you get

  • A catalogue, connected from the console

    Each app is listed in a catalogue and connected with a key or by signing in, with one place to see its state and reconnect. Sign-ins renew themselves; if one is refused, you are asked to reconnect.

    preview
  • GitHub

    The GitHub App posts verdicts on pull requests and records which pull requests implement a document, on InOrbit's own repository today. Connecting your own GitHub is coming.

    in part
  • Kubernetes, Envoy and incident.io

    Kubernetes and Envoy read by your agent for Atlas; one incident kept in both InOrbit and incident.io. In development.

    in development
  • Observability, paging and your docs

    Grafana, Loki, Datadog, PagerDuty, the cloud providers, and Notion, Confluence, Google Docs, GitBook and your docs sites read by your agent. Coming.

    coming
04In the consoleExample data

The console's Connections page for an account: one connection that needs you, two connected with the actions a person granted, and more from the catalogue.

In the console

Connections

Needs you

Jira

Jira refused the stored API token

ReconnectTest
  • Slackconnected

    post_message, list_channels · granted by Jane Doe

  • Linearconnected

    create_issue, add_comment · granted by Jane Doe

From the catalogue

  • PagerDuty

    with a key

  • incident.io

    with a key

  • Datadog

    with a key

  • GitHub

    coming soon

Example data

Drawn from the console's layout, which runs for early-access teams. The account, the person and the states are made up.

05Proof and links

Every claim on this page has its evidence: the documents that define it, the docs that say how to use it, and the API it runs on.

Proof and links

API

  • RESTpreviewList, connect, read and remove connections.
  • MCPpreviewA caller's granted actions as tools named conn_<connection>_<action>; without a grant, none are listed.

The evidence rule: a model saying it succeeded is never evidence. What counts is what was measured, by what, and when.

Your data, your call

A credential is kept by reference and used only for the actions a person granted. What a connected tool answers is treated as data, never as instructions.

Logs record who did what and the outcome, never content. The platform's own models are self-hosted; a third-party model provider is one you connect with your own key, and it bills you directly, with no line or markup from InOrbit. Separately, our own DPAs with model providers are in progress, none signed yet. InOrbit is not certified: no auditor has attested its controls yet, and the known gaps are listed.

The company's facts, controls and gaps →

06Questions

Questions, answered plainly

Which tools work today?

GitHub verdicts run on InOrbit's own repository; connecting yours is coming. The catalogue and the console's page run for early-access teams. Kubernetes, Envoy and incident.io are in development; the rest are coming.

Can an assistant use our connections?

Only the actions a person allowed, under that person's rights. Without that permission it sees nothing.

Can we add our own tool?

A new connector is added to the catalogue without changing the platform. Adding your own is not open yet.

Next step

See it on your own system

Book 30 minutes with an engineer. We look at your system together and, where it fits, open early access for your team.