Stop building native integrations. Let your users do it instead.
Intra is a software integration platform powered by data contracts. Your app defines the integration interface it needs. Users provide implementations connected to their tools and tailored to their workflows. No integration catalog. No per-source code in your app.
Read: The case for client-defined server APIs →Treaty
Define the integration server you wish existed.
Intra is built on Treaty, an open protocol for negotiating contracts. Each contract specifies a client-defined server API: the interface its client expects every implementation to expose. The resource owner provides or selects an implementation, while a mediator operates it as a conforming server. Implementations can differ completely behind that interface. One client, written once, can use them all. A contract can use any API standard supported by both client and mediator.
Treaty is an open protocol — Apache 2.0. The spec lands here shortly.
How it works
Your app submits a contract.
The contract includes the complete server API your app expects and the standard used to describe it. Once a compatible implementation is ready, Intra returns a server URL your app can use.
The user provides an implementation.
The user connects the contract to their tools and defines the relationship: what data to use, how it maps, and what each action means. Intra exposes the resulting implementation through the server API your app defined.
Your app stays in control.
Your app calls the server whenever it needs to synchronize or act. It interprets the results and applies its own product logic, just as it would with a native integration. Only the source- and workflow-specific implementation lives outside the app.
Features
Treaty makes independently provided implementations compatible. Intra makes them practical to build and operate:
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
Package source-specific mechanics once and reuse them across implementations. Bindings keep each workflow small.
CLI-first
Everything scriptable, everything inspectable. Agents operate Intra the same way you do.
Codegen
Typed clients and handler stubs generated from contracts. The Intra OpenAPI Profile builds on OpenAPI 3.1, so existing tooling still applies.
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
Deduplication and echo suppression keep retries and your own writes from running the same work twice.
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
August 2026
We're building Intra starting with the integration that made us need it: connecting ClickUp to Nodify Calendar without putting ClickUp-specific code or our workflow inside Calendar. We'll share each layer as it takes shape. The waitlist hears it first; the build happens in the open on X.