Skip to content

Feedback & reviews

Feature requests, issue reports, votes, comments and reviews work the same from the board, REST, MCP and the CLI. Everything is free; filing needs a key so each vote is one account.

How it works

  • Feature requests are public on the board; authors show as a first name, never an email.
  • Issues are private to the reporter and our team. Attach the failing call's request_id (the X-Request-Id header or the error body's request_id) and we can find the exact request. We may publish a cleaned-up title so others can add a “me too”; the context is never public.
  • Filing first looks for similar items. If there are any, nothing is filed and you get them in similar: upvote the right one, or send force: true.
  • Statuses: open → planned → in_progress → done, or declined, or duplicate (votes move to the original). Every change is on the item's timeline and emailed to everyone following it.
  • Limits per account: 10 new items and 50 comments a day, one review edit an hour.

Every surface

ActionMCP toolCLIREST
List or search the boardlist_feedbackgeocode feedback list [--kind feature|issue] [--q "<words>"]GET /v1/feedback
One item with comments and timelineget_feedbackgeocode feedback show <id>GET /v1/feedback/{id}
What I filed and follow, my reviewlist_my_feedbackgeocode feedback mineGET /v1/feedback/mine
Request a featurerequest_featuregeocode feedback request "<title>" [--details "…"]POST /v1/feedback/features
Report an issuereport_issuegeocode feedback report "<title>" [--request-id …] [--last]POST /v1/feedback/issues
Upvote / remove a voteupvote_feedbackgeocode feedback upvote <id> [--remove]POST /v1/feedback/{id}/votes
Commentcomment_on_feedbackgeocode feedback comment <id> "<text>"POST /v1/feedback/{id}/comments
Post or edit a reviewsubmit_reviewgeocode review --rating 5 --likes "…" --dislikes "…"PUT /v1/reviews/me
Read reviewslist_reviewsgeocode reviewsGET /v1/reviews

Every REST route also answers under /api/v1, and every op as POST /v1/ops/{name}.

Report a failed call

Every response carries X-Request-Id, and every error body a request_id. MCP tool errors name it and tell the agent to call report_issue with it. The CLI remembers the last failed call, so --last attaches it for you:

geocode get r62422 --detail high      # failsgeocode feedback report "get_boundary 404 for Berlin" --last
curl -X POST https://geocodeai.dev/v1/feedback/issues \  -H "Authorization: Bearer $GEOCODE_API_KEY" -H "Content-Type: application/json" \  -d '{"title":"get_boundary 404 for Berlin","request_id":"<X-Request-Id>","op":"get_boundary","context":{"boundary_id":"r62422","error":{"code":"not_found","status":404}}}'

context takes request_id, op, query, boundary_id, error, status, client, version and input (up to 128 KB). A request id must be one of your own calls.

Reviews

One review per account, editable; earlier versions are kept. It is published at once unless it has links or the account is under a day old (then it waits for a check). Publishing never depends on the rating, and we only quote reviews whose author ticked marketing_consent. Read them at /reviews or with list_reviews.

geocode review --rating 5 --title "Boundaries without the GIS work" --likes "One call per county" --dislikes "No Shapefile yet"geocode reviews --sort helpful

Emails

From the founder's inbox, replies welcome. Feedback emails are their own category: the unsubscribe link in them stops only these, and “Feedback updates” in email settings turns them on or off.

WhenYou get
You request a featureThanks, with the link to share
You report an issueYour reference number and the context we captured
You upvoteThanks (at most one a day; more votes fold into the next)
Someone comments on your itemA digest, at most one a day
The team responds officiallyThe response, to everyone following
Status → planned, in progress, done, declined, mergedWhat changed and the note, to everyone following
You post a review / we reply to itThanks / our reply