Submitting a connector
Submitting a connector starts in the app dashboard, where you create a draft version, fill in its listing and runtime details, test it in the sandbox, then submit it for review. The current flow is for remote cloud runtimes only: Remote runtimes support form or discover; Local connectors cannot be submitted; Create an app before creating credentials; Approval and publication are separate; Both a slug and a name are required; Approval unlocks production credentials; Confirm release after deployment; Test homes.
Create the draft
Section titled “Create the draft”Create an app first, then create credentials later. Each app has one stable App ID and can have more than one connector version. When you create the draft, you provide the connector identifier, display name, short description, SVG logo, publisher name, website, support URL, privacy URL, semantic version, connector specification, runtime URL, guide, release notes and AI declaration.
The connector logo must be SVG content, self-contained, roughly square and under 20 KB. The listing must not contain credentials. The descriptor’s kind must match the connector identifier in upper case. Use recognized categories and controls, and describe what stops working when the connector is disconnected.
You can save an incomplete draft. Before requesting DEV credentials, complete the metadata, specification, runtime address, guide and release notes. The runtime does not need to be running when you create credentials. DEV credentials reach the developer sandbox, and all applications share that private sandbox. The stable App ID is the application definition ID.
Test before review
Section titled “Test before review”Before you submit for review, fill in private test values for every required provider connection field and run the connector server. Those test values are stored, but version reads do not return them. Use an isolated test account, because the probe can send a real control. The runtime must also refuse missing and incorrect bearer credentials.
Submitting queues two things: persistent metadata and specification checks, plus a runtime probe. The probe checks health, connect, discover, one state read, and one representative control if one is available. The request returns immediately. submitted:true means the job is queued, not passed. You can close the browser page and wait for email results. Failed checks return the version for correction.
The runtime address checks reject unsafe or private targets on the hosted service and refuse redirects. Discovery must return usable kinds and capability sets; HTTP success alone is not enough if the state or control response is error-shaped. The probe does not sign anyone in.
Review and version states
Section titled “Review and version states”The version stores the checklist, probe transcript and reviewer notes. Editing clears prior test results, so the version must be checked again. Passing checks send the evidence and a local AI advisory to ALYT staff. AI never approves the connector. Human review checks behavior, access, vendor relationship and support. Declared AI use is visible before household installation.
Version states are:
- DRAFT: editable; test with DEV credentials in the sandbox.
- IN_REVIEW: frozen while automated checks run, then waiting for a human decision.
- CHANGES_REQUESTED: editable again, with automated findings or reviewer notes.
- APPROVED: approval unlocks production credentials; deploy and confirm release before publication.
- PUBLISHED: listed in the catalogue and available for households to install.
- DEPRECATED: unavailable for new installations; existing installations keep working.
- REJECTED: retained with its review reason; correct this version and submit again.
Deploy and publish
Section titled “Deploy and publish”Approval and publication are separate. Staff approve the version; the developer deploys and confirms release. Publication exposes the listing, including name, description, logo and developer or publisher details. Households install the published connector, and that installation grants access only to that connector in that home. A new draft can coexist with an older production version, and existing installations keep the version they installed.
Approval unlocks production credentials. After approval, open Credentials on the app dashboard tile and choose LIVE. Production credentials are created for the application, and a LIVE credential is limited to the owned connector’s installations. It carries things:read, things:control, integrations:read, events:read, and webhooks:write. It cannot manage the developer account or unrelated household devices.
Confirm release after deployment. In Versions and review, describe the deployment and explicitly confirm that the approved version and its production credentials are deployed. Final checks run before the public tile appears. If release fails, approval remains in place and the page explains how to retry. If you need to change the saved specification or runtime URL, ask the reviewer to return the approved version for changes.
Private home tests
Section titled “Private home tests”Open Test homes from the dashboard after testing in the sandbox. Request confirmation using the email address used by the ALYT home owner, even if it matches the developer address. The recipient selects one owned home and confirms within 30 minutes. Then select a connector version and enable the private test. Sign in to the ordinary ALYT app as that owner, select the home and install its Development tile.
Only that confirmed owner sees the private tile in that home. The public catalogue and other homes cannot see it. DEV credentials still reach only the sandbox; linking does not share a household login or membership. Test code can receive data and control devices installed through the connector, so use accounts and devices you are authorized to test.
The owner receives an independent removal link. Unlinking, disabling a test or losing current home ownership stops further private runtime calls, even if the tested version is later published. Other production integrations remain. Private tests support the same cloud form/discover runtime; local connectors and OAuth or external app linking are not supported by this private test flow.