capabilities
What a connector can do — the fourteen capabilities, the port each one binds, the group it is shelved under, which are official-only, and which a creator may switch off per installation.
capabilities is the list of things the connector can do. Each capability names a port: declaring the capability obliges the Connector class to bind that port, and binding a port obliges the manifest to declare a capability that needs it. The registry checks both directions at boot, so a mismatch fails on the developer's machine, and the marketplace renders the capability matrix from this list.
"capabilities": ["messaging", "broadcasts", "access_control", "early_admission_hold", "support_relay", "management_surface", "portal_login", "recovery_probes"]The fourteen capabilities
| Capability | Binds | Group | Means the connector can… | Creator can switch off |
|---|---|---|---|---|
messaging | Messenger | messaging | Deliver the core's messages to one person: confirmations, reminders, alerts, support replies. | ✅ |
broadcasts | Messenger | messaging | Carry bulk sends to a project's members, paced from the manifest. | ✅ |
access_control | AccessController | access | Grant and revoke access to the places its resource kinds name, report a member's standing, reconcile the platform with the ledger. | — |
early_admission_hold | AccessController | access | Pre-issue a dated grant and hold it at the door until its window opens (admit()). | — |
support_relay | SupportRelay | messaging | Carry a support conversation between a member and a creator over the platform, in the modes relay_modes lists. | ✅ |
native_payments | ProvidesPaymentMethods | payments | Offer a payment method that exists only on the platform (Telegram Stars). Official connectors only. | ✅ |
portal_login | PortalLoginMethod | access | Sign a member into the portal through the platform, completing the core's handshake. | — |
creator_registration | RegistersCreators | access | Create a creator account from inside the platform (a sign-up conversation on the shared installation). | — |
management_surface | ManagementSurface | access | Render the core's admin command catalogue in-chat, for the commands management_commands lists. | — |
recovery_probes | RecoverySupport | recovery | Answer the Disaster Recovery Program's health probes on installations, places and accounts. | ✅ |
recovery_standby_installations | RecoverySupport | recovery | Keep a second installation registered and ready to take over. | ✅ |
recovery_resource_standby | RecoverySupport | recovery | Move every holder from a lost place to its standby (failOver()). | ✅ |
recovery_mirror | RecoverySupport | recovery | Copy posts from a place into its standby so the standby is never empty. | ✅ |
recovery_identity_relink | RecoverySupport | recovery | Prove that a creator controls a new account after losing the old one (beginIdentityHandshake()). | ✅ |
Two capabilities bind the same port in three cases (messaging/broadcasts, access_control/early_admission_hold, the five recovery_*). Declaring the second adds an obligation on the same class, never a second class: a Messenger under broadcasts must tolerate bulk sends, an AccessController under early_admission_hold must implement admit() rather than throw, a RecoverySupport under recovery_mirror must implement mirror(). The recovery facets also have to be switched on in the recovery block; the capability binds the port, the block tells the core which facets are real.
The groups
The dashboard's Connectors tab, the marketplace's capability matrix and GET /connectors shelve capabilities under four groups (Capability::group()): messaging (messaging, broadcasts, support_relay), access (access_control, early_admission_hold, portal_login, creator_registration, management_surface), recovery (the five recovery_*) and payments (native_payments).
Per-installation switches
A creator may switch some capabilities off on one installation, from the Configuration tab, PATCH …/installation/settings with a capabilities map, or the MCP tool. The core reads the switch before it invokes your port, so a switched-off port is never called and a connector never reads the switch itself. The column above marks which: messaging, broadcasts, the support relay, native payments and every recovery facet can be switched off; access control, early admission, the management surface, portal sign-in and creator registration cannot, because a member who paid must still get in and a creator must still be able to reach the admin surface.
The port that needs no capability
One port is bound freely, because the core asks for it only when it is bound:
SpaceCatalog: how a creator picks a place to gate (Telegram's chat picker, a guild list). A connector withaccess_controlalmost always binds it; without it, the core offers no "Link a resource" for the connector and a resource can only exist through the connector's own surface.
What the registry refuses at boot
| Situation | Error |
|---|---|
| A capability is declared and its port is not bound. | declares support_relay but binds no …\Ports\SupportRelay |
| A capability-bound port is bound and no capability declares it. | binds …\Ports\Messenger without declaring a capability that needs it |
native_payments on a connector Subscriby has not configured as official. | native_payments is reserved for official connectors |
Each is an InvalidManifest exception naming the connector, and the connector is not registered. The checks are the SDK's own (Subscriby\Connector\Registry\PortAgreement), and the kit's TestRegistry runs them when your suite registers the connector, so the refusal reaches you in your own tests with the same words. The kit's ports.required_bound rule adds the seven ports every connector must bind whatever it declares: InstallationLifecycle, IdentityResolver, InboundGateway, FailureClassifier, TextRenderer, SettingsSchema and UiSlots.
The Telegram list
"capabilities": ["messaging", "broadcasts", "management_surface", "access_control", "early_admission_hold", "support_relay", "recovery_probes", "recovery_standby_installations", "recovery_resource_standby", "recovery_mirror", "recovery_identity_relink", "creator_registration", "portal_login", "native_payments"]Every capability the SDK has, because Telegram's feature set is the hundred-percent scope every other connector is measured against. The fake connector declares six: messaging, broadcasts, access_control, management_surface, portal_login, recovery_probes.
Capabilities are promises
The kit checks that the port is bound; review checks that it works. A connector that declares recovery_resource_standby and throws UnsupportedByConnector from failOver() passes the kit and fails review. Declare what the platform can actually do.
How is this guide?
resource_kinds
Each kind of place a connector can gate — its labels, its icon, how access to it is granted, which plan shapes it sells, and whether it supports early admission, mirroring and in-place upgrades.
messaging
The platform's message limits — length, buttons, callback data and formatting — and exactly where the core enforces each before a message reaches the connector.