Falaah Falaah AI

How a New Integration Gets Built

What it takes to add an integration to Muin, who can request one, and why a new connector appears as not yet available before it ships.

If a system you rely on is not in Settings → Integrations, this page explains how one gets added, how long the steps take, and what you will see in the app while it is being built.

The live list is in the app, not here

This page describes the process, not the catalog. The systems you can connect, and the status of each, are whatever Settings → Integrations shows in your workspace right now. That screen is generated from the same source the platform uses to decide what is connectable, so it cannot drift from reality. Nothing on this page should be read as a claim that a particular system is available.

Request one

Use Feature Request or Contact and tell us:

  1. The system and the specific records you want moving (invoices, contacts, files, calendar events).
  2. Which direction, and whether you need it continuous or one time.
  3. Whether you are an administrator on that system, which decides how the connection is authorized.

Points 1 and 2 are the part that matters. “Integrate with X” is many different products depending on which records move and which way, and the answer changes what gets built.

How one is added

Every Muin integration is one declaration plus the code it points at. That declaration is the single place a connector is defined: the catalog entry a workspace sees, the authorization configuration, and the runtime that moves the data are all derived from it. There is no second list to keep in step, which is why adding an integration is a bounded piece of work rather than a change scattered across the platform.

The steps, in order:

  1. Declare it. Name, category, how it authorizes, which direction data moves.
  2. Write the two code surfaces. One checks that a connection is real and reports its health. The second, for systems we pull records from, lists and fetches those records.
  3. Test it against the real service. Not a stand-in.
  4. Mark it available. Only after step 3.

Steps 1 and 2 are stamped by a generator and start out deliberately unimplemented: every method raises until someone writes it. That is on purpose. A scaffold that returned a quiet success would report a connection it never made, and an automated check blocks the integration from being called finished while any of those placeholders survive.

Why a new integration shows as not yet available first

Every connector carries a status. An integration enters the catalog as not yet available and stays there until its implementation is finished and tested. That status is enforced, not cosmetic: while it is set, the platform refuses to create a connection, so the button cannot quietly do nothing. You will see the integration listed and labeled, which tells you it is real and coming, and you will not be able to half-connect it.

The reverse is enforced too. When an integration ships, the label comes off everywhere it is published, including this documentation, and an automated check compares what we publish against what the platform will actually let a workspace connect.

Writing one yourself

The authoring contract is a written specification, not a pointer at our source tree: the declaration fields, the two code interfaces, the authorization block, the settings-schema shape, and a worked example end to end. It is maintained as connector-sdk.md in the Muin platform repository.

We do not run a self-serve developer program today, and there is no public registry you can publish into. If you want to write one, or have your engineering team write one alongside ours, get in touch and we will share the contract and agree a review path. A connector written outside our team goes through the same review and the same status gate as one written inside it: it enters the catalog as not yet available, and it is marked available only once it has been reviewed and tested against the live service.