Hi everyone,
I’m using Bubble to generate a barcode in a backend API workflow, and I have an issue where the barcode image cannot be detected by barcode scanners.
and here’s the example barcode result in email:
Here is my setup:
The barcode image looks fine on screen, but when I try to scan it, the scanner often says there is no barcode / cannot read it.
Below is also a screenshot of my scanner page in Bubble.
The scanner is supposed to read the barcode and then update a field (for example: set a status to “attended”), using the value from BarcodeScanner A's Barcode Content.
My questions:
-
Is there anything in these barcode settings that could cause the image to be unreadable by scanners?
-
Is it better to use the SVG directly instead of converting it to PNG?
-
Are there recommended width/height/margin or image size settings to make the barcode easier to scan?
-
Is my scanner setup (using BarcodeScanner A's Barcode Content to update a record) correct, or is there something I should change?
Thanks in advance.
Yes, you should use an .svg.
Also, your workflow is way confusing… so many redundant things.
Do you need to use a barcode?
I use QR codes and don’t need a plugin…
but maybe your use requires one? Are you using a handheld laser scanner?
Are you sure it’s including the start code at the beginning and the check sum at the end for you automatically already or do you need to explicitly include that in the data you’re converting to a barcode? I suggest researching the Code 128 protocol to make sure.
I use Code 39 in my app for printed receipts and I have to manually include the asterisk * start and stop characters for that. So maybe it’s something like that which you’re running into, not including the right start and stop info.
Hi @senecadatabase, thanks for the reply.
Yes, we do need to use barcodes. We’re using them for event check‑in: each attendee gets a barcode in their confirmation email, and we scan it on‑site to automatically update the attendance status in Bubble (it turns the row to a green “attended” state like in the screenshot).
We’ve actually been using this flow in our SAIA app for a while and it used to work. The barcodes are already stored in the database and we can scan them from a phone screen. The strange thing is that now some scanners can’t detect the barcode image anymore, even though the workflow and data structure haven’t really changed.
Right now our backend workflow is:
-
HitPay → update Application
-
Create a barcode (CODE128, output as SVG)
-
Convert SVG to PNG
-
Save the PNG and send it by email, then use the Bubble barcode scanner on the “Open Scanner” page to mark attendance.
From your comment, I’m trying to understand which part you see as redundant:
Also, to confirm: we’re scanning with both phone cameras (Bubble barcode scanner element) and handheld scanners connected to laptops. Previously both worked, but now it just cannot read for the barcodes.
If you have any suggestions on which steps we can safely remove, or best practices for displaying the SVG so both phone and handheld scanners can read it reliably, that would be super helpful. Happy to share more screenshots of the workflow if needed.
Just to add some context on why I’m keeping this setup for now:
We’ve already been using this exact barcode flow in production for our events. The barcodes are generated when people register, stored in the database, and have already been sent out to attendees by email. The event itself is already running — on‑site we just open the scanner page, scan the barcode, and it automatically updates the attendance in the table (turns the row green).
Because of that, I can’t easily change the format or regenerate everything without breaking existing tickets that people already have. From my point of view it should just be a matter of scanning what’s already there, which is why this recent “cannot read / no barcode detected” behaviour is confusing.
So right now I’m mainly trying to:
-
keep the same data and workflow (since it was working before and is already live), and
-
figure out what changed or what detail I’m missing (encoding, image format, size, etc.) that makes some scanners suddenly fail to read these barcodes.
If there are adjustments I can make that don’t force us to invalidate all existing barcodes, I’m definitely open to that.
Any chance you’d be willing to share a couple of example barcodes that your app is generating? It would be helpful for us to assist you with troubleshooting. Best to make sure it’s consistently generating proper barcodes first, maybe there’s something simple that’s missing.
Yes, can. Here are some example barcodes generated by the app.
I’m using Bubble’s built‑in barcode scanner element on the check‑in page.
It would also be helpful to tell us what data you think you’re transforming into these barcodes. What are the literal characters you’re trying to encode for each one of these?
In the examples you gave, it appears the messages are very short (1-3 characters, assuming I’m decoding these barcodes correctly. Like, that last one was just the letter “t”. Am I right?). Some barcode scanners will struggle to scan such short messages due to minimal bar density.
Are these example barcodes identical to the real ones you’re using for your app? The solution could literally be as simple as making the barcode message longer, but we need more info to know for sure.
I ran into the same thing with my point-of-sale system app. We print the order number as a barcode on the bottom of every receipt for quick recall with a scanner, but for a new store starting from order #1 the scanner just wouldn’t pick it up. I realized that there were too few characters to scan, so we changed it to display the barcode for “001”, for example. Technically the same information but with some extra leading characters to make the scanner happy. Perhaps there are some extra characters you can add to your barcodes that your app can simply ignore when submitted.
Hi Brian, thanks for your help and for looking into this.
For the barcodes in my examples, I’m using a backend workflow action called “create a barcode” with the following settings:
-
Format: CODE128
-
Data (value to encode): Result of step 1 (Make changes to Application...)’s Slug
-
Width: 2
-
Height: 100
-
Display value: no
Hi Brian, thanks again for digging into this.
To clarify the workflow details:
-
In Step 1 (“Make changes to Application…”), I update the relevant Application (Search for Applications:first item) when the Hitpay API callback returns status = completed. In that step I set the Paid field to “yes” and store the Hitpay paymentid.
-
The barcode step (“create a barcode”) runs only when Result of step 1’s Paid is Paid. For the barcode data I use Result of step 1’s Slug, with:
Because that Slug can be very short (often only 1–3 characters), the generated barcodes are also encoding very short messages, which matches what you saw when decoding (e.g. just “t”).
Based on your explanation, I’m planning to switch the encoded value to something longer, like a prefixed or padded version of the slug (e.g. "EVT-" + Slug or Slug with leading zeros), then strip those extra characters after scanning.
Does that sound like the right approach for improving scan reliability with CODE128, and is there a minimum length/pattern you’d recommend?
and here’s the complete workflow
if you need more detail just please let me know
Yes, that’s what I recommend. At least 5 characters total. I suspect this is the issue.
If not, then the only other thing I can think of to try would be to inspect the programming of the barcode reader itself. If you can find a user manual for it, the manual will have programming barcodes to scan that change settings on the device.
Fun fact: Barcode scanners are typically programmed by scanning special barcodes. I’ve always loved that. Something so simple and poetic about it. I mean, why not? The thing is literally an input device so why use any other method to input codes?
