[Bug]: Asset check-in accepts location_id, returns success, and silently ignores it

[shanehughes-ui]

Snipe-IT Version

v8.6.3 - build 23252-gfffcfd2a3a

PHP Version

8.3.6

Composer Version

n/a (official Docker image)

MySQL/MariaDB version

MySQL 8.0 (Google Cloud SQL)

How did you install Snipe-IT?

Docker

Is this a fresh install or an upgrade?

Upgrade

What happened?

POST /api/v1/hardware/{id}/checkin accepts a location_id parameter, returns "status": "success", and silently ignores it. The asset's location is never changed and nothing in the response indicates the parameter was dropped.

The same request's status_id is applied, which makes the failure particularly easy to miss: you send two fields, get one success message, and only one of them took effect.

Reproduction

Against a live v8.6.3 instance, on an asset checked out to a user and whose rtd_location is Chermside (id 1):

POST /api/v1/hardware/2535/checkin
Content-Type: application/json

{
  "note": "testing check-in parameters",
  "status_id": 20,          // "To be Cleaned Up"
  "location_id": 46         // "Perth"
}

Response:

{ "status": "success", "messages": "Asset checked in successfully." }

Reading the asset back immediately afterwards:

field	before	after	expected
status_label	Emergency Spare	To be Cleaned Up	To be Cleaned Up ✅
rtd_location	Chermside	Chermside	Perth ❌
assigned_to	(a user)	null	null ✅

So status_id is honoured and location_id is not, with no error, no warning, and a success response.

Why this is worth fixing rather than documenting

The parameter name is the natural guess for "where did this come back to", and the API confirms success. Any integration that sets it will believe assets are being relocated on check-in when they are not — and because the response is a success, nothing surfaces the problem. It is only visible by reading the asset back and diffing, which most integrations reasonably do not do.

We found it exactly that way: our return-tracking integration marks a device received, checks it in, and records which office it arrived at. It reported devices as relocated for as long as we trusted the parameter name. We now do a separate PATCH /api/v1/hardware/{id} with rtd_location_id, which works — so the workaround is easy once you know, and impossible to guess before.

Suggested resolutions, in order of preference

1. Honour location_id on check-in, setting rtd_location_id (for an unassigned asset Snipe derives location from rtd_location, and an unassigned asset is exactly what a just-checked-in one is). This matches what the parameter name promises.
2. If check-in is deliberately not meant to relocate an asset, reject the request (422) or return a warning, rather than accepting it silently. A silent ignore is the worst of the three options.

Either is a clear improvement on the current behaviour. I am happy to open a PR for whichever the maintainers prefer — I did not want to guess at intent first.

Possibly related

• [Feature]: Allow API integrators to specify an override location during checkout like you can with GUI checkout #18187 — Allow API integrators to specify an override location during checkout. That asks for a checkout feature that does not exist; this report is about a check-in parameter that is accepted and then discarded. Different endpoints, and this one is arguably a bug rather than a missing feature, but they clearly sit next to each other.

What browsers are you seeing the problem on?

No response (API only)

Can you reproduce this on the public demo?

I have not tried — the reproduction mutates an asset (check out, check in, restore), and I did not want to leave test state on the public demo. It reproduces reliably on our own instance, and the steps above are complete.

Do you have full multiple company support enabled?

No

If you have full multiple company support enabled, do you have location scoping to company enabled?

No response

Browser console output

No response