Feature requests
What OmniSocials cannot do, why, and what to do instead (GET /limits), and feature requests for the person who owns the key. Built for AI agents: read the limits before you tell a person something is not possible, and send a request only after they agree. No scope needed.
List what OmniSocials cannot do
The things OmniSocials cannot do, why, and what to do instead: platform rules, features not built yet, features that work in the OmniSocials app only. Read it before you tell a person that something is not possible, so you can give the reason. When the person still wants a requestable entry, send a feature request with its limit_id. Works with every key; no scope needed.
query Parameters
platformOnly the entries for this platform (entries for every channel stay in).
areaList what OmniSocials cannot do › Responses
The entries
List your feature requests
Send a feature request
Sends a feature request to the OmniSocials team for the person who owns the key (their name and email are stored with it so the team can answer). Send it only when the person asked for it. Write summary yourself: what the person wants to do and why, in one or two sentences; never a conversation. When the request matches an entry of GET /limits, pass its limit_id: a second person of the same organisation then adds a vote to the open request instead of a new one. The person sees the request in OmniSocials (Settings, Request a feature) and gets an email when its status changes. At most 10 requests an hour per person.
Send a feature request › Request Body
summaryWhat the person wants to do and why, in one or two sentences.
titleA short name for the request. Made from the summary when left out.
platformThe platform it is about, when it is about one.
arealimit_idThe id of the GET /limits entry the request is about.
sourceWhere the request comes from. The MCP servers and the CLI set it; default api.
Send a feature request › Responses
outcome: already_requested: this person already has an open request for it; data is that request.