Submitting a connector

Submitting a connector is the developer lifecycle from a new integration idea to a connector other people can install. A developer starts with a draft, validates it with a DEV key in a sandbox, submits it for review, and, if approved, publishes it so it appears in the public catalogue and can receive a LIVE key. The house keeps working when the cloud is down, so publishing and review do not change whether an existing installation keeps running. A DEV key acts only in a sandbox, and a LIVE key works only for its own published connector.

What you submit

The submission is the connector descriptor. ALYT does not use a second format for third parties. The same descriptor contract applies to first-party and third-party connectors.

A submission includes:

• the slug
• the descriptor
• prose
• the runtime
• the AI declaration
• test values for the connect fields

The descriptor is validated against the integration descriptor contract. Its kind must be the slug in upper case. The descriptor is also checked against the closed set of connect methods, the catalogue of capabilities, and the requirement to state what stops working when disconnected. No credentials belong in the submission text, and any config is write-only.

A submission is a definition version. A published connector is versioned, and a developer publishing a new version does not silently change an existing household installation.

Lifecycle

State	Meaning	Who moves it
DRAFT	being built, editable, testable with a DEV key against the developer’s own sandbox	developer
IN_REVIEW	submitted and frozen	developer submits
CHANGES_REQUESTED	reviewer asked for changes with a reason the developer can read	reviewer
APPROVED	judged fit, but not yet installable	reviewer
PUBLISHED	in the catalogue and installable by tenants; a LIVE key is issued	reviewer publishes
DEPRECATED	no new installs; existing ones keep working and are told	reviewer
REJECTED	refused, with a reason	reviewer

APPROVED and PUBLISHED are separate on purpose. Review decides whether the connector is fit; publishing decides whether it is available to customers. DEPRECATED is not delete, because existing houses depend on published connectors continuing to work.

Public or private

A connector is either PUBLIC or PRIVATE.

Scope	PUBLIC	PRIVATE
Installable in	every ALYT installation, hosted and self-hosted	only the installation that wrote it
Updates	distributed centrally to everyone	the operator ships their own
In the central catalogue	yes	no
Answerable	ALYT vetted it, the developer supports it	the operator, entirely

PRIVATE must be incapable of reaching the central catalogue. It is for in-house systems, regional vendors, or NDA-bound connectors that should run on the operator’s own platform without becoming public.

Review checks

Some checks are mechanical and should fail before a person reviews the submission:

• the descriptor validates
• its capabilities exist in the catalogue
• the connect method is one of the closed set
• it declares what stops working when disconnected
• no credentials appear in the submission
• the configuration is write-only
• a probe can run against a sandbox instance
• the AI declaration is set when the connector uses a model

The human review checks the claims that need judgement:

• does it do what it says
• what does it reach
• is the vendor relationship sound
• who supports it when it breaks

Keys and installation

A DEV key exists from DRAFT and reaches only the developer’s sandbox and virtual devices. It is for testing before review.

A LIVE key is issued only at PUBLISHED, and never before. It is scoped to the published definition, so it can act only through that connector’s own surface. It is not a general-purpose credential for the platform.

Installation is per tenant and consented. A published definition does not grant access to any house on its own. A tenant installing it creates the Integration row, and that is what grants access. Revoking an install is one action a household can take.

What developers see

A developer works on /dashboard/submissions. The public catalogue is /community. The review page is for ALYT staff only.

When a submission passes checks, the machine-run probe tests the runtime the way tenant service will: health, connect, discover, one state read, and one control. The probe stores its transcripts on the version, and the developer and reviewer can read them. If the submission is edited, those transcripts clear.

A connector that uses AI must say so. The descriptor declares it, and the portal and install screen show it before anyone installs the connector.

What publishing means

Publishing makes the definition PUBLIC, sets the current version, and deprecates the previous current version for new installs only. Existing installations keep working. A household that installed a connector can continue using it even if later versions are published or the connector is deprecated.

A published connector can receive a LIVE key only after publish. That key is limited to the developer’s own published definition and the tenant installations that installed that definition.

Notes for developers

• Build one descriptor contract for all connectors.
• Use DRAFT for testing with a DEV key.
• Expect human review after mechanical checks pass.
• Treat APPROVED as “fit” and PUBLISHED as “available.”
• Use PRIVATE when the connector should stay in one installation.
• Declare AI use in the descriptor when the connector calls a model.
• Keep in mind that published connectors must not break already installed houses when they are deprecated.