Feature Request: Multi-Asset Support in Audit API

[blown5]

Description:
Currently, the Snipe-IT Audit API only allows submitting audit records for a single asset at a time. In RFID-based auditing projects, however, hundreds of assets can be scanned simultaneously in the field, and it is essential to record their audit information in bulk with a single request.

Suggested Enhancement:
Extend the Audit API to accept an array of asset IDs, allowing the same audit details to be recorded for multiple assets in a single API call.

Use Case:

In warehouse, archive, or office environments, RFID readers can detect 200+ assets at once.

Making individual API calls for each asset decreases mobile performance and puts unnecessary load on the server.

This slows down the audit workflow and negatively impacts the user experience.

Why is this important?

Bulk inventory audits have become standard for many organizations.

This feature will significantly streamline real-time audits, especially when using mobile RFID solutions.

It will also provide great flexibility and efficiency for developers integrating with the API.

Conclusion:
This improvement will align Snipe-IT more closely with modern inventory technologies like RFID and make it suitable for a broader range of enterprise workflows.

[snipe]

We actually almost have something that could work here - the "legacy" audit API, which we use for the Bulk Audit, which does take a post request (versus the newer version, where the asset ID is in the URL.) It just doesn't check for an array, and assumes you are only passing one asset_tag, but that's something we can change.

I think this is definitely worth working on, but I was hoping you could do us a favor in return: We don't currently have any solid documentation on real-world implementations of NFC/RFID usage, and we'd love to highlight some specific ways folks are using us in that way. If you'd be willing to write up more info about your setup and use-case so we can add it to the docs, it would be a huge help, either here on GH or in the #bardcodes-nfc-and-rfid channel in our Discord.

[snipe]

A few quick questions though - do you actually do anything with the payload in the API response? Right now the payload shape is a single asset (as expected, since we only take a single asset_tag in the POST payload.) What would you expect the payload shape to be with multiple assets, some of which might not be successful in the audit (if they are missing a required audit field or what have you.)

I'd also be interested in hearing what @uberbrady things about this re: API response shape.

[blown5]

Thank you for considering this enhancement request. Extending the Audit API to support bulk audits with multiple asset IDs, especially for RFID-based asset management scenarios, is truly an important improvement.

Regarding this, I will share all of my RFID experiences, including the barcode printers, mobile terminals, and methods used in my Android project, on Discord as soon as possible.

[snipe]

Great, thanks! Can you confirm the API endpoint you're hitting? I have a PR almost ready to go, but I want to make sure I'm looking at the same thing :)

[blown5]

I am using the /api/v1/hardware/audit endpoint URL for the API.

[snipe]

Okay, good - that's the one I've been working on :)

The way I currently have it working in my WIP, the shape of the API response won't change if you only send one asset_tag. I'm trying to decide what it should look like if you send an array though.

It's possible that some audits could fail, and we want to be able to deliver a payload that is consistent with the way we normally handle things, but that also makes it clear which ones were successful and which ones weren't, in the event you need to do something else with that information. (When I say failed I mean they didn't validate, either the asset tag doesn't exist, a required field isn't valid on the asset itself, etc.)

The current response looks like this:

{
    "status": "success",
    "messages": "Asset audit successfully logged.",
    "payload": {
        "id": 1,
        "asset_tag": "685823750",
        "note": "Test via API",
        "next_audit_date": {
            "datetime": "2025-05-08 00:00:00",
            "formatted": "Thu May 08, 2025 12:00AM"
        },
        "custom_fields": []
    }
}

But obviously, with 100+ assets being audited at once, this doesn't leave room for the possibility of splitting out the ones that were successful vs the ones that were not.

[hatunoglu]

Currently, we call this service multiple times, each time getting an individual response body. Since many of your other endpoints return a response with a "total" and "rows" structure, how about adopting the same format for the bulk audit response?
Just a suggestion—this could help speed up development :)

{
"successes": {
"total": 1,
"rows": [
{ /* single audit response body /}
]
},
"failures": {
"total": 1,
"rows": [
{ / single audit response body */}
]
}
}

P.S.: Since the backend always returns HTTP 200, you can stick with 200 and no need to use 207

[snipe]

So, oddly, we're speaking internally about this not just for auditing, but for other endpoints where we do (or will) accept multiple things, and each thing could have different success/failures and accompanying validation messages. (I'm specifically looking at file uploads for assets and models right now, which both return completely stupid responses - oops!) In addressing the bulk audit, we can also address the bulk file uploads responses.

Strictly speaking, we don't need the rows for this - at least not right now. That's used by the bootstrap tables package we use, so we strictly speaking might have a bit more flexibility if we wanted to omit that.

As always, API "shapes" are always the hardest part, since we can't easily change them once they become canon.

Your proposed structure is very similar to the one I've been playing with though, so good to know we're thinking the same way :)

[snipe]

Good news is, once we standardize it and commit, we'll have the transformers and presenters handy to apply those down the line to the additional bulk stuff we're adding.