Car Image API
Documentation

Feedback

Feature requests, issue reports, upvotes, comments and reviews, from any surface.

Ask for what the API should do next, report what is broken with the exact request attached, vote for what others asked for, and say what you think of Car Image. All of it is free, the same on REST, MCP and the CLI, and the people who follow an item hear about every change: a thank-you when it is filed, an email when it is planned, started, answered by the team and done. The board is at /requests; the reviews at /reviews.

Every action, every surface

Feedback actions
ParameterTypeDescription
List the board
GET /api/v1/feedback
list_feedback · car-image feedback list. Filter by kind (feature, issue, vehicle), status, q; sort top, new or recent_activity.
One item
GET /api/v1/feedback/{id}
get_feedback · car-image feedback show. Comments (official responses marked) and the status timeline.
Mine
GET /api/v1/feedback?mine=true
list_my_feedback · car-image feedback mine. What you filed, voted on, commented on or follow.
Request a feature
POST /api/v1/feedback/features
request_feature · car-image feedback request.
Report an issue
POST /api/v1/feedback/issues
report_issue · car-image feedback report --last. Private to you and the team.
Upvote
POST / DELETE /api/v1/feedback/{id}/votes
upvote_feedback, remove_feedback_vote · car-image feedback upvote [--remove].
Comment
POST /api/v1/feedback/{id}/comments
comment_on_feedback · car-image feedback comment.
Review
PUT /api/v1/reviews/me
submit_review · car-image review.
Read reviews
GET /api/v1/reviews
list_reviews · car-image reviews. Average, distribution and the team's answers.

The SDK has the same methods: listFeedback, getFeedback, listMyFeedback, requestFeature, reportIssue, upvoteFeedback, removeFeedbackVote, commentOnFeedback, submitReview, getMyReview and listReviews.

Request a feature

POST/api/v1/feedback/features
account:readfree
bash
curl -X POST https://carimage.dev/api/v1/feedback/features \
  -H "Authorization: Bearer $CAR_IMAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Interior views", "body": "Dashboard and front seats for our listing pages"}'

Similar items come first. When the board already has something like it, nothing is filed: the answer is 200 with created: false and the matches in similar. Upvote the one that fits (votes are what move an item up), or send the request again with "force": true. A new item is 201 with created: true. Ten new items a day per account.

200 OK: a similar item exists
{
  "created": false,
  "data": null,
  "similar": [
    {
      "id": "6c1f…",
      "kind": "feature",
      "title": "Interior and dashboard views",
      "status": "planned",
      "votes": 14,
      "url": "https://carimage.dev/requests/6c1f…"
    }
  ],
  "request_id": "req_01ja0…"
}

Report an issue

POST/api/v1/feedback/issues
account:readfree
bash
curl -X POST https://carimage.dev/api/v1/feedback/issues \
  -H "Authorization: Bearer $CAR_IMAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Side view of the 2024 Camry returns 502", "request_id": "req_01j9x…",
       "context": {"endpoint": "/api/v1/images/car", "vehicle": "veh_395yw8tn73ff8", "view": "side"}}'

Attach the X-Request-Id of the call that went wrong as request_id: the team sees what the server logged about it (route, status, error code, vehicle). context takes the other identifiers you have: endpoint, error_code, asset_id, vehicle, view, color, model_3d_id, client, client_version and a free-form details object, 128 KB in all. Ids are checked against your own requests, and the context is never shown publicly.

Reports are private to you and the Car Image team. When others are likely to hit the same problem, the team publishes it under a cleaned-up title so they can upvote it instead of filing it again. The SDK attaches the last failed call by itself (client.reportIssue({ title })), the CLI with --last, and an MCP tool error names the request_id to pass.

Statuses and emails

Items move open → planned → in_progress → done, or end declined, or duplicate with duplicate_of naming the item its votes and followers moved to (a vote on a duplicate lands there). Voting follows an item; removing the vote unfollows it unless you commented. A comment from the team marked as the official response is shown first-class on the page.

Every email names the item, links to it and carries a one-click unsubscribe for feedback email alone:

  • a thank-you when you file a request or report (with the context it captured);
  • a thank-you for upvoting, at most one a day (later votes fold into the next one);
  • a daily digest of new comments on what you posted;
  • the team's official responses, and every status change, with the team's note;
  • a thank-you for your review, and the team's reply to it.

Reviews

PUT/api/v1/reviews/me
account:readfree

One review per account: rating 1–5 and, optionally, title, body, likes, dislikes, use_case, display_name (defaults to your first name), display_company and marketing_consent (whether we may quote it elsewhere; off unless you say so). Edit it once an hour; earlier versions are kept. A review is published as written after automated checks (language, links, an account under a day old without paid usage are held for a person) and is never gated on its rating. GET /api/v1/reviews lists the published ones with our answers.

From the CLI

bash
car-image feedback list --kind feature --sort top
car-image feedback request "Interior views" --details "dashboard and seats"
car-image feedback report "Side view returns 502" --last      # attaches the last failed request
car-image feedback upvote <id>          # --remove takes the vote back
car-image feedback comment <id> "We need the hybrid trim too"
car-image feedback mine                 # what you filed and follow, with status
car-image review --rating 5 --body "Fast renders, great catalog"
car-image reviews

Rate an image

POST/api/v1/feedback
images:readfree
Request body
ParameterTypeDescription
request_id
string
The X-Request-Id of the image response you are rating. The most precise way to identify the asset.
vehicle
object
Alternative to request_id: make, model, year, view and color identifying the rendered variant.
rating
integer 1–5
Star rating; 1–2 counts as negative.
verdict
"good" | "bad"
Simpler thumbs up/down when a rating is overkill.
reason
string ≤ 500
What is wrong (or right): "shows a sedan, should be a wagon".

Provide request_id or vehicle, and rating or verdict.

bash
curl -X POST https://carimage.dev/api/v1/feedback \
  -H "Authorization: Bearer $CAR_IMAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"request_id": "req_01j9x…", "verdict": "bad", "reason": "Rear spoiler belongs to the GT3, not the Carrera"}'
201 Created
{
  "data": {
    "asset_id": "3f0c2a7e-…",
    "negative": true,
    "flagged": false,
    "feedback_count": 1
  },
  "request_id": "req_01ja0…"
}

Rating from the CLI and MCP

  • car-image feedback --request-id req_… --bad --reason "…"
  • MCP tool rate_image — agents can rate what they just fetched.
  • The dashboard shows your recent images with one-click ratings.

Rating errors

  • 400 — neither request_id nor vehicle given, or neither rating nor verdict; reason too long.
  • 404 — no rendered asset matches the identifier (feedback must target an image that exists).