One protocol to replace all in‑app integrations
Intra is a platform for data contracts — client-defined APIs negotiated through Treaty protocol. Apps declare the APIs they need. Users bind those contracts to their tools. No integration catalog. No per-source code in your app.
Read: The case for client-defined server APIs →Treaty
Define the server you wish existed.
Treaty reverses the usual API relationship. The client defines the server interface it needs and declares it through a contract. The resource owner decides whether and how to provide it. Each contract names the standard used to describe that API — OpenAPI 3.1 to start. It says what the server must do, not which tools must sit behind it. A mediator supplies the implementation and exposes a conforming API.
Treaty is an open protocol — Apache 2.0. The spec lands here shortly.
How it works
An app submits a contract.
An envelope that says who's asking and why — and an API document specifying what the app needs. Standard formats, standard tooling, one new idea: the client defines the interface.
User binds it to their tools.
Intra runs on the user's side. Bindings map the contract onto the tools they actually use: written as code manually, generated by AI and reviewed, or configured in a UI. Outgrow the UI and you drop to code — same contract, nothing renegotiated.
Data flows both ways.
Reads, subscriptions, and writes all pass through the mediator — and writes come back with an answer: succeeded, rejected, conflicted, changed. The rules that never had a home live in the one place that sees every write before it lands.
Features
You could build all of this yourself.
That's the point — Treaty is an open protocol.
Intra is what makes it pleasant and reliable:
Hosting
Your bindings run on Intra — your machine, your team's server, or our cloud. Deploy integration logic; keep none of the infrastructure.
Routing
Every contract call reaches the handler implementing it, with the caller's identity attached. Your logic sees who's asking; the gateway does the rest.
Adapters
Every source has its own API. An adapter wraps it once — and serves every contract ever published.
CLI-first
Everything scriptable, everything inspectable. Agents operate Intra the same way you do.
Codegen
Typed clients and handler stubs generated from contracts. Starting with OpenAPI 3.1, your existing tooling already works.
Sync
Two-way, versioned. Every write carries its basis; stale writes become conflicts, not overwrites.
Event log
Every write recorded: who did it, what it was based on, what came back. Rejections are conflicts with context, not error strings.
Deduplication
Your logic sees each change exactly once — duplicates and echoes of your own writes never reach it.
Retries & rate limits
Backoff, retry budgets, and per-source rate limits handled beneath your code. You write the mapping, not the traffic control.
UI
For people who'd rather not see the code. It produces the same artifacts — and when you outgrow it, you drop to code.
Why
- Maintain an integrations catalog — build each connector, keep it alive forever
+ Submit one contract. Sources you've never heard of just work
- Ship source-shaped settings screens inside your app
+ Configuration lives on the user's side — their mediator, their bindings
- Webhooks, dedup, echoes, retries — rebuilt for every integration
+ Delivery machinery handled beneath your code, once
- Every user's workflow lands as a feature request in your queue
+ Every user gets their own bespoke integration — without you building it
- Integration code ages inside your app
+ No per-source code in your app. Ever
Status
July 2026
We're building Intra, starting with the integration that made us need it: ClickUp and our own calendar — two people, one workflow, completion meaning different things for each of us. We'll be showing more as it takes shape. The waitlist hears it first. The build happens in the open on X.