---
title: Capabilities
description: 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](/reference/capabilities) 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](/testing/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.