Limits and feature requests: what OmniSocials cannot do
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).
Terminal
JSON
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.
Terminal
| 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 samelimit_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 samelimit_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 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 has limits, feature:request, feature:list and feature:get.
For platform behaviour that makes a post fail, see Known issues.