Capabilities

Understand how declared capabilities, content formats, availability states, and evidence levels describe what each Social SDK integration can do.

A capability is a declared, operation-specific claim: this backend, for this platform, supports this operation with these content formats. Social SDK ships the declarations as typed manifests and generates the capability matrix from them.

Declarations are specific

Support is never a platform-level checkmark. Each declaration names the backend, platform, operation, and formats, so “Zernio publishes carousels on Instagram” and “the direct X adapter uploads images” are separate facts. A dash in a matrix means the operation is not exposed on that route.

Unavailable is an answer

The client dispatches an operation only when the adapter’s manifest declares it available for that platform. How it says no depends on the call:

posts.publish and posts.prepare record a preparation issue with code capability.unavailable for the target. publish then throws invalid_input with those issues, and no target is dispatched.
Every other facade call throws unsupported_capability before any network request.

Applications should surface either as unsupported rather than an empty result, so users see the truth about a route instead of a silent gap.

Availability states

Each declaration has one CapabilityAvailability value. Only available dispatches. Every other value is a reason the client will not dispatch on this route:

Value	Meaning
`available`	The adapter implements the operation; the client dispatches it.
`unsupported-by-platform`	The upstream API this adapter uses does not offer the operation.
`not-implemented-by-adapter`	The upstream API offers it, but this adapter has no code path.
`permission-required`	The route lacks a permission the operation needs.
`reconnect-required`	The backend reports that the account must reconnect first.
`account-ineligible`	The configured account type cannot use the operation.
`runtime-unavailable`	The operation cannot run in this runtime.
`approval-dependent`	The route depends on a platform approval the adapter does not assume.
`unknown-until-request`	Support cannot be known before a request; the client still does not dispatch it.

Some declarations depend on configuration. An adapter can declare an operation available for one account flavor or author type and something else for another, so read the manifest from the adapter you configured.

available means the code exists, not that your app or account may use it. When the platform gates an operation behind a paid tier, app review, or enterprise product, the declaration’s requiredScopes and notes say so. If your app lacks that access, the platform rejects the request and the SDK surfaces it as a SocialError.

Evidence is a separate scale

Availability describes the manifest. Evidence levels describe how far a claim has been proven, from implemented through contract-tested to live-verified and released. The two use different vocabularies: approval-dependent as an availability value means the client will not dispatch, while the approval-dependent evidence level records that code exists and public use awaits review. Do not infer one from the other. A provider’s upstream feature is not treated as supported until Social SDK has matching code and evidence. Conformance checks keep the manifests, runtime methods, and generated docs in agreement.

Search is bounded by the provider

search.posts is a normalized operation where an adapter can express provider search as a page of post objects. It does not promise a shared query language, a complete archive, stable ordering, or the same retention window on every platform. Query syntax, fields, permissions, rate limits, and historical access remain provider-specific. Use the platform guide and capability declaration for the selected route, and keep native access for search products that need provider features outside this contract.