SafeCart · GPSR Hub
Synced every ~15 minutes with the official European Commission Safety Gate.Verify at /api/v1/health →

How SafeCart matching works

Recall monitoring is only as trustworthy as its data source and its matching rules. This page explains both — including what we deliberately don't claim to do. If you are evaluating SafeCart as an EU Responsible Person, authorised representative, or merchant, this is the methodology behind every alert we send.

The data source: the official Safety Gate API

SafeCart ingests recall notifications directly from the Safety Gate Interoperability Gateway (SGIG) — the European Commission's official machine-to-machine API for the EU Safety Gate rapid alert system, operated by DG Justice and Consumers. We are a registered external stakeholder system with our own credentials. We do not scrape the public Safety Gate website.

Our ingestion runs every ~15 minutes and searches by modification date, not just publication date — so we pick up both newly published notifications and post-publication edits (a barcode added later, a risk reclassified). Every API response from SafeCart includes meta.last_synced_at, so you can verify data freshness yourself rather than take our word for it.

Historical coverage: every notification since 2021

The archive holds every Safety Gate notification published since 1 January 2021 — nearly 19,000 as of September 2026 — and grows with each sync. Matching runs against the whole archive, not just new alerts. When you connect a store or add a product, it is checked against five-plus years of notification history straight away, so you find out whether anything you already sell has been notified — and then monitoring continues with every new notification.

Withdrawn notifications

Authorities sometimes withdraw notifications. SafeCart consumes the SGIG withdrawn-notification feed on every sync: withdrawn notifications are excluded from all matching, and a product that was flagged solely on a now-withdrawn notification clears automatically on the next monitoring pass (every 15 minutes). Withdrawn notifications remain searchable in the API (with their withdrawn_date) for your records — they just stop generating alerts.

Matching tier 1: validated, canonical GTIN matching

The primary matching key is the barcode (GTIN/EAN/UPC), because it is the only identifier precise enough to flag a product without human review.

  • Validation. Every barcode — yours and the notification's — is normalised to digits and validated against the GS1 mod-10 check digit. Malformed identifiers never produce matches.
  • Canonical GTIN-14 equivalence. GS1 defines GTIN-8, GTIN-12 (UPC-A), GTIN-13 (EAN-13) and GTIN-14 as one zero-padded number space. SafeCart matches across all of these forms: a UPC-A 036000291452 in your catalog matches the EAN-13 0036000291452 on a notification, and vice versa. Many monitoring setups compare raw strings and silently miss these.
  • Where it runs. The same matching applies everywhere: the public API (POST /api/v1/safety/check), continuous portfolio monitoring (your products are rechecked against the full notification set every 15 minutes, right after each ingestion; alert emails go out on the same schedule, with a daily backstop), and the free store scanner.

An exact GTIN match flags the product immediately — no fuzzy logic involved, so an exact-tier alert is worth acting on.

Matching tier 2: brand-gated matching with human review (monitoring)

Almost half of Safety Gate notifications carry no usable barcode: roughly a third have none at all, and another sixth carry only values that fail their GS1 check digit and so can never match exactly. For those, continuous monitoring runs a second tier — deliberately conservative, and never auto-flagging:

  • Brand gate. The notification must carry a brand, and that brand must agree with your product: either the manufacturer linked to your product (directly, or through its compliance profile) has that exact name, or the brand appears in your product name. We measured the alternatives on real merchant data before choosing this rule — name-similarity alone drowns generic product names in false positives, because Safety Gate names are mostly category labels ("Perfume", "Sandals").
  • Name affinity. On top of the brand gate, the product and notification names must clear a trigram-similarity floor.
  • Human review, always. A tier-2 hit never flags your product by itself. It enters your review queue as a possible match with the evidence (brand agreement, similarity score, link to the official notification), and you confirm or dismiss it. Dismissals are remembered per product/notification pair — the same pairing never comes back. Every decision is recorded with who decided and when, which doubles as GPSR evidence of monitoring.

The free store scanner keeps its own fuzzy tier: trigram similarity with a conservative threshold, always labelled as possible matches and never mixed into the exact tier.

What we don't do (yet)

Honesty about limitations is part of the methodology:

  • Notifications with neither a barcode nor a brand are not matched. A minority of Safety Gate notifications carry only a generic product name; matching those without drowning you in false alarms needs the manufacturer registry and alias work on our roadmap.
  • Model numbers are not yet a matching key. Tier 2 matches on brand plus product name. Structured model/reference-number matching — normalised, brand-gated and review-only, like tier 2 — is our next matching tier.
  • No image or OCR matching. Notification photos are stored but not used for matching.
  • History starts in 2021. Notifications published before 1 January 2021 are not in the archive.

Evidence of monitoring

Detecting a recall is half the job; the other half is being able to show that your monitoring actually ran. SafeCart records it as it happens:

  • Every check. Each monitored product records when it was last checked against Safety Gate (last_safety_gate_check) and the full details of any matching notification.
  • Every decision. Each possible match you confirm or dismiss is stored with who decided and when.
  • Every corrective action. Recall campaign actions — sales blocks, customer notifications, banner publication — are written to an append-only action log, with detection and business-awareness timestamps.

The dashboard's Evidence Report turns this into a monthly surveillance report you can download as PDF or JSON, on every plan. For the month you choose it covers:

  • products monitored, how many have a validated GTIN, and how many rely on the brand tier;
  • how recently every product was checked, and any that were never checked;
  • possible matches raised, confirmed, dismissed and still pending;
  • recall campaigns opened, completed and still open;
  • Safety Gate feed health: ingestion runs, failures, and the longest gap.

It is evidence of documented market monitoring under the GPSR — not by itself a complete post-market surveillance system. Raw data exports are also available from the dashboard and the API.

Verify it yourself

  • API reference — check any GTIN against the live notification set with POST /safety/check, or search notifications with GET /recalls.
  • Response metadata carries last_synced_at on every recall search.
  • The free store scanner runs this exact pipeline against your public storefront, no account required.

Last updated: 28 September 2026 (the archive now holds every notification published since 1 January 2021; the evidence report is documented). This page is kept in lockstep with the shipped system — when the methodology changes, this page changes in the same release.