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

Calling an undeclared operation fails fast with an unsupported_capability error before any network request. Applications should surface that as unsupported rather than an empty result, so users see the truth about a route instead of a silent gap.

Availability states

Every operation the SDK implements is declared available, even when the platform gates it behind a paid tier, an app review, or an enterprise product. The declaration’s requiredScopes and notes say what access you need. If your app has that access, the call goes through. If it does not, the platform rejects the request and the SDK surfaces that as a SocialError. Other availability values mark operations the SDK does not implement for that account, such as approval-dependent work that is not built yet, account-ineligible account types, or features the upstream API does not offer at all.

Evidence backs every claim

A declaration says what the code implements; evidence levels say how far it has been proven, from implemented through contract-tested to live-verified and released. 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.