# Limits and feature requests: what OmniSocials cannot do

> Index of all OmniSocials docs pages: https://docs.omnisocials.com/llms.txt

Some things OmniSocials cannot do. A platform does not allow it (TikTok's API cannot delete a video), OmniSocials has not built it yet (bold text on Telegram), or it works only in the OmniSocials app (connecting an account). The API lists these gaps with the reason and what to do instead, so an agent can answer a person at once instead of guessing. When the person still wants the feature, the agent can send a feature request for them.

Both work with every API key. No scope is needed.

## List the limits

`GET /limits` returns every entry. Filter with `platform` (an entry for every channel stays in) or `area` (`posts`, `media`, `inbox`, `analytics`, `automations`, `accounts`, `ads`, `team`, `other`).

```bash
curl "https://api.omnisocials.com/v1/limits?platform=tiktok" \
  -H "Authorization: Bearer omsk_live_..."
```

```json
{
  "data": [
    {
      "id": "tiktok.delete",
      "kind": "platform",
      "kind_label": "The platform does not allow it",
      "area": "posts",
      "platforms": ["tiktok"],
      "title": "Delete a TikTok video",
      "says": "TikTok's API cannot delete a video. delete_post removes it from OmniSocials only.",
      "instead": "Delete the video in the TikTok app.",
      "requestable": false
    }
  ],
  "kinds": { "platform": "The platform does not allow it", "...": "..." }
}
```

| `kind` | Meaning | Can be requested |
|--------|---------|------------------|
| `platform` | The platform does not allow it | No |
| `by_design` | OmniSocials does not do this on purpose (for example, reading other people's profiles) | No |
| `not_built` | OmniSocials has not built it yet | Yes |
| `beta` | Built, open to some accounts only | Yes |
| `dashboard_only` | Works in the OmniSocials app, not through the API or MCP | Yes |
| `needs_setup` | Works after a setup step the person takes | Yes |

Tell the person `says` and `instead` in your own words. The list changes as features ship, so read it at the time of the question rather than storing it.

## Send a feature request

`POST /feature-requests` stores a request for the person who owns the key. The OmniSocials team reads every request. Send one only when the person asked for it.

```bash
curl -X POST "https://api.omnisocials.com/v1/feature-requests" \
  -H "Authorization: Bearer omsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "summary": "Post our daily update to the Announcements topic of our Telegram group, not to the whole group.",
    "limit_id": "telegram.forum_topics"
  }'
```

| Field | Rule |
|-------|------|
| `summary` | Required, 10 to 1,000 characters: what the person wants to do and why, in one or two sentences. Never a conversation or other people's personal data. |
| `title` | Optional, up to 120 characters. Made from the summary when left out. |
| `platform`, `area` | Optional. Taken from the limit when `limit_id` is given. |
| `limit_id` | Optional: the `id` of the `GET /limits` entry the request is about. |

The answer has an `outcome`:

- `created` (201): a new request.
- `voted` (201): the person's organisation already has an open request with the same `limit_id`. Their vote and their summary are added to it, so requests for one gap add up.
- `already_requested` (200): this person already asked for it (the same `limit_id`, or the same text within a day). Nothing new is stored.

Errors: `400 invalid_summary`, `invalid_title`, `invalid_platform`, `invalid_area`, `unknown_limit`; `409 not_requestable` when `limit_id` is a `platform` or `by_design` entry (the entry is in `error.limit`, nothing is stored); `429 too_many_requests` after 10 requests in an hour.

The request is stored with the person's name and email, so the team can answer. The person sees it in OmniSocials under **Settings → Request a feature**, with requests sent from the app. When the team changes the status (In progress, Done, Declined) or replies, the person gets an email and a notice in the app. People who voted hear it when the request is done.

## Read requests back

`GET /feature-requests` returns the person's own requests (newest first, at most 50), and `GET /feature-requests/{id}` one request. Each carries `status`, `team_answer`, `team_replies`, `votes_count`, `limit_id` and `source` (`app`, `mcp`, `api` or `cli`).

## From an AI assistant

The [MCP server](https://docs.omnisocials.com/mcp-server.md) has the same three calls as tools: `get_limits`, `request_feature` and `list_feature_requests`. Its server instructions tell the assistant to read `get_limits` before it says that something is not possible, to give the reason, and to offer `request_feature` only after the person agrees. An `unsupported_platform`, `unsupported_reply_type` or `not_supported` error from a tool ends with a line that points to `request_feature`.

The [CLI](https://docs.omnisocials.com/cli.md) has `limits`, `feature:request`, `feature:list` and `feature:get`.

For platform behaviour that makes a post fail, see [Known issues](https://docs.omnisocials.com/known-issues.md).