# The App Contract: what a Cordango app offers > The App Contract describes what an app can do and expose: its purpose, the events it announces, the actions that can be invoked, the questions it can answer and what it depends on. Derived from the definition, read by workflows, other apps, external systems and agents. Source: https://www.cordango.com/app-contract/ Language: en HOW IT WORKS · 03 # Every Cordango app is designed around a contract. The contract is the capability layer we are currently introducing across the platform. It describes what an app offers to everything outside it: the events it announces, the actions that can be invoked, the questions it can answer and what it depends on. The Definition describes how the app works. The Contract describes how everything else can work with it. [What is true today →](https://www.cordango.com/app-contract/#today) [What it states →](https://www.cordango.com/app-contract/#states) 1. [01 Idea / Prompt](https://www.cordango.com/generate/) 2. [02 App Definition](https://www.cordango.com/app-definition/) 3. 03 App Contract 4. [04 Live Business App](https://www.cordango.com/run-on-cordango/) 1. [Workflows Subscribe to an event by name](https://www.cordango.com/app-contract/#readers) 2. [Other apps Ask what the app offers and needs](https://www.cordango.com/app-contract/#readers) 3. [External systems Webhooks, exports, automation platforms](https://www.cordango.com/app-contract/#readers) 4. [Agents Discover what the app can do](https://www.cordango.com/app-contract/#readers) 5. [API / MCP The queries and actions it names](https://www.cordango.com/app-contract/#readers) FIG.00 — STAGE 03 OF 04 · APP CONTRACT ## What the contract states. Everything in it is computed from the definition when the app is compiled. The one exception is the purpose, which the generator writes once when the app is created and which you can edit. PURPOSE #### What the app is for A summary and the duties the app owns. Written once by the generator from your description, editable afterwards, and the only part a person maintains. CAPABILITIES #### What it can do The interaction surfaces the app supports, derived from what the definition actually contains. No flag that says webhooks: yes. Facts, not promises. EVENTS #### What it announces Named events like deal.won or pto.approved, plus the record and state changes that come with every entity. The announcement is the contract. ACTIONS #### What can be invoked The commands the definition declares. Create a deal, move a stage, approve a request. Each one runs under the caller's permissions. QUERIES #### What can be asked The entities, views, KPIs and rollups the app makes readable. The forecast is a query, and so is the list of open deals. DEPENDENCIES #### What it expects to find The Organizations, People and other apps it points at instead of inventing its own. A CRM that depends on Organizations never keeps a second customer list. ## Who reads it, and why that matters. The app's own screens never need the contract. Everything outside the app does. A workflow subscribes to an event by its name. Another app declares what it depends on. An agent asks what it can do. The App Library shows what an app announces before anybody installs it. The contract also has a stability promise the app's internals do not. The definition can change shape every week. The contract is versioned, so a dropped event or a renamed action is visible before an update lands, and an app that only changed on the inside does not disturb anything wired to it. - NAME Events and actions are addressed by name, never by table or screen - STABLE Versioned, so a breaking change is visible before it breaks anything - LISTING What an app offers is shown in the library before it is installed - RIGHTS Every reader acts under its own permissions, the contract grants none [Agents and the API across the company →](https://www.cordango.com/ai/) App update Contract diff \# planned: the contract diff before an update installs > sales-crm v1.2 → v1.3 + event invoice.posted + query deals by owner 0 removed events · 0 removed actions · 0 renamed fields ✔ compatible every workflow and connection keeps working ## What is true today, and what comes next. We would rather say this here than let a diagram imply it. The parts of the contract that exist today: every definition names the events it announces, every app is reachable over REST, OpenAPI and MCP under the caller's permissions, and apps already point at the same Organizations and People instead of keeping copies. What we are introducing now: the contract as its own compiled file next to every app, apps reacting to each other's events without middleware, and agents discovering an app's capabilities from the contract instead of from its interface. The roadmap says where each of those stands. - TODAY Named events, REST and MCP per app, shared records across apps - NEXT The contract file, cross-app reactions, agent discovery [Where we are today →](https://www.cordango.com/roadmap/) Where we are Honest version \# today ✔ events named in every definition deal.won · pto.approved ✔ REST · OpenAPI · MCP per app under your permissions ✔ cross-app references a deal points at the real Organization \# next → the contract as a file beside every app → apps reacting to each other's events → agents discovering what an app can do ## Born Connected. — why the contract exists A Cordango app is created with a known interaction surface. It does not have to be integrated later, because from the first day it says what it offers and what it depends on, and it points at the company's own records rather than keeping a copy of them. That is the difference between connected and integrated. Integrated means two separate things were wired together afterwards. Connected means the app was built to participate: the same people, the same organizations, the same permission model, and a contract that tells everything else how to work with it. - SHARED Apps point at one Organization and one Person record, never at copies - ONE One gateway behind REST, OpenAPI and MCP for every app - RIGHTS A cross-app answer is built after permissions are applied, not before - NEXT Reactions between apps follow the same contract, without middleware [Apps on one set of records →](https://www.cordango.com/dashboard/) Connected by design Globex SE \# one record, three apps Globex SE Organization · owner Tomas R. ✔ crm deal 42.000 € stage: negotiation ✔ helpdesk ticket #2841 priority: high ✔ projects onboarding project 3 open tasks \# the same record, asked over rest or mcp ✔ one answer your permissions applied before it is built MORE ## Further reading - [**App Definition** How the app works: domain, data, experience, logic and access](https://www.cordango.com/app-definition/) - [**Run on Cordango** The live app: personal views, governance, shared context and connected work](https://www.cordango.com/run-on-cordango/) - [**Agents & APIs** Agents, MCP and APIs across your whole company](https://www.cordango.com/ai/) - [**Connected by default** Apps work together from day one](https://www.cordango.com/dashboard/) - [**Capabilities** CRM, projects, PTO, support and more](https://www.cordango.com/capabilities/) - [**Sample apps** Explore real apps you can install and make yours](https://www.cordango.com/templates/) - [**Use cases** See where Cordango fits best, with a real app behind each one](https://www.cordango.com/use-cases/) - [**Platform foundation** The company foundation underneath every app](https://www.cordango.com/platform/) NEXT ## See what an app offers before it is installed. Bring a process that touches more than one tool today. We build the app live and show what it announces, what it can be asked, and how the rest of your company works with it. [Book a demo →](https://www.cordango.com/contact/) [What the live app gains →](https://www.cordango.com/run-on-cordango/)