Feature
InBody scans, on the member record, automatically.
Most stores with a scanner have the same problem: the machine prints a sheet, the member takes it home, and the store keeps none of it. The one piece of data that proves your product works never reaches the CRM. Here scans arrive on their own, attach to the member, and go to work — feeding challenges, the leaderboard, the member's own history, and the screen on the wall.
01 — How it works
From the machine to the member record
- Scans arrive by webhookLookinBody posts each completed scan to us and it lands on the matching member record. No staff transcription, no CSV at the end of the month, no one remembering to do it.
- Each scanner is mapped to a storeA per-serial map attributes every scan to the location it was taken at, so a multi-location operator sees per-store scan volume instead of one pooled number. An unmapped scanner still ingests — the scan is unattributed, not lost.
- Scans feed the competitionEvery arriving scan updates the leaderboard and any challenge the member has joined. The scoring happens on ingest, so standings are current the moment someone steps off the machine.
- Members see their own historyResults and trend live in the branded member app and member site — which is the part that brings them back to scan again, because the graph only means something if it has more than one dot on it.
- Photos can be uploaded and parsedA result sheet can be photographed and parsed onto the record instead. This is the path that needs nothing from InBody at all — see the next section, because it matters more than it sounds like it should.
02 — The honest part
Four ways data gets off an InBody, and what each one costs you
Nobody selling you gym software explains this, and it is the thing that decides whether your integration happens in a week or never. Here is what actually exists on InBody's side.
| Path | What it requires | What you get |
|---|---|---|
| LookinBody Web API | An active LookinBody subscription, plus an API application approved by InBody. | The route most partners use, and the one we run. Scans post to us as they happen, no hardware in the middle. |
| Open Protocol | A direct connection to the scanner over serial, USB, or LAN, and something on-site to listen to it. | Raw results straight off the machine, no subscription. It is a wired integration, so it lives or dies on the box you leave plugged in next to the scanner. |
| LB120 / LBS middleware | InBody's own middleware installed on a local machine. | Bridges older units into a modern data flow. Another piece of software to keep running in your back room. |
| Photo upload and parse | A phone. That is the list. | The result sheet gets photographed and parsed onto the member record. Works with any scanner brand, needs no subscription and no approval from anyone. |
03 — In practice
Why the photo path is the one that unblocks stores
If you already pay for LookinBody and your API application is approved, use the webhook — it is better in every way, and it is what the founding operator runs. But most of the stores we talk to are not in that position. They bought the scanner years ago, they never subscribed, the approval process is not something they are going to chase, or the machine in the corner is not even an InBody. Under the usual rule those stores simply do not get a body-composition feature, and the software either lies about it or sells them a subscription they did not want.
The photo path means the answer is yes anyway. Snap the printout, it gets parsed onto the member record, and from there it is indistinguishable from a webhook scan as far as the rest of the platform is concerned: same history in the app, same leaderboard, same challenge scoring, same mirror screen if you hang a TV. The trade is the automation, not the data — someone has to take the picture. In a store where staff already hand the sheet over, that is a two-second habit; in a 24/7 gym with no one at the desk at 5am, it is a real limitation and you should plan for the webhook.
Either way, this is a member-record feature, not a fitness-app feature. A scan sitting on the same record as their purchase history and their points is what lets you text the twelve people whose body fat dropped this quarter, or the ones who scanned once in January and never came back. That is the segmentation side of it, and it is the reason to keep the data in the first place. The full connection list, with statuses, is on integrations.
04 — Questions
Straight answers.
Do I need a LookinBody subscription to connect my InBody scanner?
For the webhook path, yes. The LookinBody Web API is the route most partners use, and it requires an active LookinBody subscription plus an API application approved by InBody. That is InBody's gate, not ours. If you do not have it, use the photo-upload path — it needs no subscription and no approval.
What if my scanner is not an InBody?
Use photo upload. The result sheet gets photographed and parsed onto the member record, which works with any scanner brand that prints a sheet. You lose the automatic arrival, not the data.
I have two locations and two scanners. Do the scans get mixed up?
No. Each scanner's serial number is mapped to a store, so a scan is filed to the store it was taken at. A scanner nobody has mapped yet still ingests — its scans are simply unattributed rather than dropped, and you can map it later.
Can members see their own scan history?
Yes, in the branded member app and on the member site: their results, their trend over time, and where they stand in any challenge they have joined. Staff see the same history on the member record in the portal.
05 — Next step
Bring your scanner's model number to the call.
Book a 20-minute demo and we will tell you which of the four paths your unit can actually use, and what it takes to turn it on.
$200/mo platform · 5,000 texts included · no contracts