Send Feedback API | Bug, Idea or Missing Capability

POST feedback files a bug, idea or missing_capability report against the calling account and answers 201 with the new report's id, its status (always new on creation) and created_at. The JSON body carries type, a title of up to 120 characters and details of up to 8000, plus optional area, evidence and client. It costs nothing and is limited to 10 calls per minute per API key.

curl -X POST "https://example.com/feedback" \  -H "Content-Type: application/json" \  -d '{    "type": "bug",    "title": "tweet/thread returns 500 on a quoted reply",    "details": "what happened: tweet/thread?id=1899999999999999999 answered 500 server_error, expected the 4-post thread. what the user said: \\"it worked yesterday\\". repro: GET tweet/thread with that id. evidence: status 500, request id req_01J9K2, twitter_tweet_thread via claude-code/2.1.259."  }'

{  "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",  "status": "new",  "created_at": "2026-09-04T10:15:00.000Z"}

{  "error": "invalid_request",  "field": "title",  "message": "title must be 120 characters or fewer (got 131)."}

{  "error": "Invalid API key"}

{  "error": "Too many requests. Limit: 10 per minute."}

{  "error": "upstream_unavailable",  "message": "The feedback service is temporarily unavailable. Retry shortly."}

{  "error": "Internal server error"}

Pricing

When to use

Use it when an agent has just hit a failure it could not work around, found that something the user wanted is exposed by no endpoint, or the user explicitly asked to send feedback. Do not use it for questions that need an answer within minutes, or for balance questions, which account/me answers directly. Read feedback/{id} afterwards to learn whether the report was triaged, shipped or declined.

Notes

• Served from the API root: https://api.twitterapis.com/feedback. It is NOT under /twitter, and /twitter/feedback returns 404.
• Free. Never metered: filing a report does not touch credits_used or total_requests.
• Rate limited to 10 requests per minute per API key, shared with GET feedback/{id}. The 11th call in a minute gets 429 with a Retry-After header (seconds until the window resets) and the body {"error": "Too many requests. Limit: 10 per minute."}.
• Both Authorization: Bearer <key> and x-api-key: <key> are accepted. A missing or unknown key is 401.
• Every 400 names the field: {"error": "invalid_request", "field": "title", "message": "title must be 120 characters or fewer (got 131)."}. An agent should repair that one field and resend, not retry the same body.
• A body that is not a JSON object (an array, a bare string, malformed JSON) is rejected with 400 and field "body" before it reaches validation.
• The official MCP server (@twitterapis/mcp) drafts a report locally and sends it here only after the user has reviewed it. Call this route directly when you are building that review step yourself; never send on the user's behalf without showing them the draft.

Related endpoints

• Feedback Status: Read one feedback report you filed: its current status and the team's response, if any.
• Account Info: Your credit balance, lifetime usage, and account details for the API key making the call.

FAQ

Who is this for, a person or an agent?

Either can call it, but it is shaped for the agent case: Claude Code, Cursor or any MCP client that just watched a call fail or found a gap while doing what the user asked. The four-bullet details shape exists so a report written by a model at the moment of failure still carries what a human needs to reproduce it: what happened, what the user said, how to repro, and the identifiers.

What belongs in evidence, and what does not?

Identifiers only: the tool name, the endpoint, the HTTP status, the request id, the client and the MCP version. Never a tweet payload, a response body or a credential. The 4096-byte cap on its serialized size is there to make a payload dump fail loudly rather than land in a Slack channel.

Does filing feedback cost credits or count as a request?

No. The route is zero-rated: it does not touch credits_used or total_requests. The only brake is the limiter, 10 calls per minute per key, which is far above what any honest agent sends and far below what would make the team's channel unusable.

How do I find out what happened to a report?

Keep the id from the 201 and call GET feedback/{id}. It returns the status (new, triaged, shipped, declined) and the team's response text once one is written, and its updated_at moves only when either of those changes, so an agent can tell looked-at from not-yet without re-reading the whole body.