expose comment location data on the v2 REST API

Hi BugSmash team,

We use the v2 API to automate processing of website review feedback (list comments, action the changes in code, post replies). It works well and v2 is a big improvement over v1.

One gap is blocking us from fully automating website projects. The per-comment location data is not available on the REST API. Both GET /api/v2/comments?projectId=... and GET /api/v2/comment/{id} return the comment text, status, priority, screenshot URL and replies, but no information about which page or element the comment was pinned to. On website projects comment_by_name and any page reference come back null, so the API alone cannot tell us where a comment belongs.

That same data does exist. Your new JSON export (Project > Export > JSON) includes a full location object per comment:

"location": { "live_url": "https://example.com/for-professionals/#enquiry", "dom_selector": "main > section:nth-child(2) > ... > a:nth-child(1)", "dom_selector_fallback": "...", "closest_parent_selector": "...", "element_tag": "a", "element_text": "privacy policy", "pin": { "x": ..., "y": ... }, "element_bounding_box": { ... }, "viewport": { ... }, "device": { ... }, "browser": "Chrome", "platform": "Desktop" }

With live_url, dom_selector and element_text on the API we could locate the exact element in source directly, with no manual export step. The export is great for a one-off batch, but it is a manual download and is not reachable with our API key, so it cannot drive an automated or scheduled workflow.

What we would like:

1. Add the location object to each comment in GET /api/v2/comments and GET /api/v2/comment/{id}, or

2. Gate it behind a parameter such as ?include=location to avoid bloating the default response.

Note: we tried ?include=location, ?expand=location and ?with=location on the comments endpoint already. They are accepted but ignored (the response is byte-for-byte identical), so there does not appear to be an existing flag for this.

At minimum live_url, dom_selector and element_text would be enough for us, though the full object matching the export would be ideal.

Additional improvements

1. No way to mark a comment resolved via the API (the bigger one). PATCH /comment/{id} lists status as editable but only accepts an opaque internal UUID, so every value we can actually send gets rejected. Right now our reply is our own "done" marker, but the client still has to manually click Resolve in the dashboard to move it out of active. If they exposed a plain resolve/status endpoint, we could close the loop fully and stop depending on the client remembering to click. This is arguably more friction day-to-day than the location gap.

2. Tags aren't on the API either (optional). The export has a tags field but GET /comments doesn't. Only worth asking for if you plan to actually use tags to flag "on-hold vs action now" — otherwise it's a speculative ask. Your call.

Thank you. Chris