Feature Request: Add support for custom fields and request body templates for webhook pushes

[xzlabs]

Hi Markus, thank you for developing and maintaining BinaryEye, this excellent barcode scanner app!
My use case is using my phone as a portable barcode scanner. After scanning product barcodes/QR codes, I need to attach custom business fields (such as scan time, item type, storage location, etc.) to the scan result and send it via webhook to an online spreadsheet for automated inventory tracking and data entry.
Currently, BinaryEye's webhook push only seems to send the raw scan result itself, with no way to include additional context or custom information needed for my workflow.
I would love to see the following features added:

• Support for user-configurable custom fields (e.g., scanner device ID, scan timestamp, item category, location) that can be included alongside the scan result in the webhook payload.
• A request body template editor, allowing users to freely build custom HTTP request bodies using placeholders for scan data and custom fields.

Thank you for your time and consideration!

[markusfisch]

Thanks for the detailed request, and sorry for the late response.

Some of this is already possible: when using GET with full query string, POST application/x-www-form-urlencoded, or POST application/json, Binary Eye already sends more than just the raw content, including content, raw, format, barcode metadata, and a scan timestamp.

The last commit c325713 adds a configurable scanner/device ID. That will be available in the next version.

I’m not sure a fully custom HTTP request body template would improve much here, because the arguments Binary Eye can provide are already well-defined. The receiving webhook/spreadsheet endpoint is usually the better place to map those fields into whatever final shape is needed.

Custom fields like item category or storage location are a different matter because Binary Eye would need UI for entering/selecting them during scanning. Not impossible, and I can see real value here. The only consideration is that the forwarding happens directly after the scan, and before the user had a chance to enter anything. So this would have to go into an optional dialog.

Location is also special: adding the device location would require requesting additional Android location permissions, which I’d rather avoid unless there is a strong need for it.