A machine vision system that doesn't push its results into your MES is a better version of paper quality records. The data is there, it's just not connected to anything that generates a corrective action, a quality record, or a customer-facing PPAP document. This article covers the webhook architecture we use to get defect events from the edge unit into the MES in real time, without middleware.
What data needs to move from inspection to MES
The minimum viable event payload for MES integration contains: the production order number or job ID (so the defect can be attributed to the correct order), the part serial or barcode (if the line uses part-level serialization), a timestamp, the inspection decision (pass, fail, or review), the defect class or classes detected, confidence scores for each detected class, and the camera ID and line ID.
Optional but useful: bounding box coordinates for the defect location in the image, the image reference ID (so you can retrieve the image from the edge unit's local storage for review), and the defect severity class if your model distinguishes between critical and minor defects.
Do not send images over the webhook. Raw images are large, latency-sensitive payloads are not the right transport for them, and your MES doesn't know what to do with a JPEG. Send the image reference ID and retrieve images separately if needed.
Webhook versus polling
The alternative to webhooks is polling: your MES periodically queries the edge unit API for new inspection results. Polling is simpler to implement on the MES side if you have a vendor that supports outbound REST calls but not inbound webhook subscriptions. The tradeoff is latency: a 30-second poll interval means a defect event can be up to 30 seconds old when it reaches the MES. For most quality record purposes, that's acceptable. For real-time reject signaling (where the inspection result needs to trigger a PLC signal within 500ms), polling is not fast enough and you need a direct PLC output from the edge unit rather than a route through the MES.
Reliable delivery
Webhooks on a factory network are not reliable by default. Plant networks have packet loss, intermittent connectivity during shift changes, and MES instances that restart during maintenance windows. If you send a webhook event and don't receive a 200 response, you need to retry. Our edge unit implementation uses an exponential backoff with jitter, retrying at 5s, 15s, 60s, and 5m intervals before marking the event as delivery-failed and flagging it for manual review.
Delivery-failed events are not lost; they're held in a local queue on the edge unit and can be bulk-replayed when connectivity is restored. The MES needs to handle idempotent replay: if the same event is delivered twice (due to a retry after a timeout where the first delivery succeeded but the acknowledgement was lost), the MES should recognize the duplicate event ID and ignore the second delivery rather than creating two quality records.
SAP Quality Management integration
SAP QM's external quality notification API (transaction QM01 / BAPI_QUALNOT_CREATE) accepts structured defect records against a production order. The Gaugegrove webhook maps inspection event fields to the SAP QM notification fields: defect class maps to the SAP defect code, the confidence score maps to the defect characteristic value, and the production order number links the notification to the order.
The SAP integration requires an API user with QM_NOTIF_CREATE authorization, a destination-specific HTTPS endpoint, and a mapping table for Gaugegrove defect class codes to SAP defect catalog codes. The mapping table is part of the one-time SAP setup and does not change unless the defect catalog changes.
Plex integration
Plex's production API accepts inspection result records against a production order via its DataSource or Part operation check-in endpoints. Defect events map to Plex nonconformance records. The Plex integration is simpler to configure than SAP because the Plex REST API is more directly applicable to the inspection event data model.
Shift summary versus per-event posting
Some plants prefer shift-level quality summary records in their MES rather than per-event records. This is a configuration option in Gaugegrove: the edge unit can aggregate defect events and post a shift summary at configurable shift boundaries (end of each 8h shift, for example). The shift summary contains total parts inspected, parts passed, parts failed by defect class, and a timestamp for the shift boundary. Per-event records are still held in local storage for trend analysis and image retrieval.
Generic REST targets without native connector support
Not every plant runs SAP or Plex. Many mid-size tier-2 and tier-3 suppliers use custom-built shop floor systems, older on-premise MES platforms, or a combination of a SCADA historian (OSIsoft PI, for example) and a spreadsheet-based QA log. For these environments, the Gaugegrove edge unit exposes a generic outbound webhook that can POST to any REST endpoint you control.
The payload schema is configurable: you can remap field names, filter which defect classes trigger a notification, and set a minimum confidence threshold below which no webhook fires. A plant running a custom Python-based MES wrote a 40-line Flask endpoint that receives Gaugegrove webhooks and writes records directly into their quality database. That is the intended design -- no dedicated integration layer needed unless your MES vendor requires one.
If your shop floor system has no inbound REST capability at all, the edge unit can write defect events to a local CSV file at a configurable path, mounted as a network share. This is the lowest-tech integration option and is appropriate for plants where the quality engineer wants to pull a CSV report at end of shift and paste it into an existing quality record template. It is not real-time, but it is zero-configuration on the MES side.
Testing the integration before go-live
Before switching the edge unit to live inspection mode, run a full integration test using the edge unit's replay function. The replay function re-sends previously captured inspection results through the webhook pipeline as if they were live events, so you can verify that your MES is receiving, parsing, and storing them correctly without running actual production parts.
Verify three things during the integration test: that the production order association is correct (each defect record links to the right order, not a test order or a null), that duplicate event handling is working (replaying the same event twice should produce one quality record, not two), and that the MES is correctly classifying defect class codes against its own defect catalog. A mismatch in defect class mapping is the most common source of quality data errors after deployment, and it is far easier to find and fix during a replay test than during a post-deployment audit.