The product
What you are licensing
The licence covers the deterministic verification engine, its curated multilingual allergen taxonomy and dietary rules, and the method used to turn declared diner constraints into a consistent verdict. The same safety logic supports the hosted, embedded and OEM options.
Deterministic
The same declared inputs produce the same verdict.
Versioned
Engine and taxonomy versions accompany every response.
Minimal data
Hosted requests do not retain ingredient text or diner identity.
It is designed to complement your product's recipe generation, menu publishing or ordering flow. It does not replace accurate ingredient declarations, supplier controls, kitchen procedures or professional medical advice.
Commercial models
Three ways to licence it
Start with the hosted API when you want the quickest integration. Move to an embedded or OEM agreement when residency, internal operation or customer-facing white-labelling becomes important.
| Option | Best for | Operation | Commercial shape |
|---|---|---|---|
| Hosted API | Apps, marketplaces and meal platforms | SavorMood operates the verification service | Free sandbox, then metered or committed volume |
| Embedded source | Enterprises with strict residency or latency requirements | You run the engine inside one named product | Annual, per-product commercial licence |
| OEM / white-label | POS, kitchen and hospitality technology providers | You embed the engine and present the control to customers | Custom annual agreement and permitted claims |
An embedded source licence is for internal use within the product named in your agreement and does not permit redistribution of the taxonomy as a standalone data set. OEM terms add the right to represent the control to your customers, subject to agreed wording, a pinned taxonomy version and passing the evaluation bench.
Hosted API
How keys, quotas and billing work
Each environment or product should use its own licence key. The raw key is shown once when it is created; SavorMood stores a one-way hash, so the original value cannot be retrieved later. Keep it on your server, never in browser code or a public repository, and revoke it immediately if it may have been exposed.
- 1
Send declared ingredients
Include constraints, dietary labels and the relevant language codes.
- 2
Receive a pass or fail
The response identifies failed constraint names without exposing the proprietary matching data.
- 3
Use the request ID
Keep it with your own audit event for support and traceability.
- 4
Watch quota headers
Each successful response reports the monthly quota and the amount used.
Sandbox keys include 500 calls per month and 30 per day. Production plans use an agreed monthly allowance and per-call or committed-volume price. Calls rejected for invalid input, quota exhaustion or service failure are not billable. A quota breach returns HTTP 429 rather than silently allowing unplanned usage.
Data handling
Built to minimise exposure
Hosted verification processes ingredient text only long enough to evaluate the request. Usage records contain the licence-key identifier, status code, verdict counts, timing and engine versions—not recipe text, matched terms or an end user's identity. This keeps operational reporting useful without building a store of your customers' food or health-related inputs.
Your responsibilities
- Send only the information required for verification.
- Keep licence keys in protected server-side secrets and rotate them when needed.
- Maintain your own access controls, consent notices and retention policy.
- Do not treat a safe API verdict as evidence about undeclared ingredients or cross-contact.
Change control
Pin, test and audit every release
Every verdict includes both engine and taxonomy versions. Production agreements define an update cadence and how long an older taxonomy may remain pinned. This gives your team a controlled window to run acceptance tests before matching behaviour changes.
The evaluation bench is the shared acceptance test. The current published run executed 3,917 checks across 15 allergen or restriction groups, 22 languages and 7 dietary rules, with zero misses and zero needless blocks in that test set. These results describe the tested taxonomy and version; they are evidence of engineering performance, not a promise that every real-world ingredient declaration is complete.
Embedded and OEM customers can run the bench in their own release process. A public certification statement should use only the wording agreed in the licence, such as the exact version tested and whether its bench passed.
Responsible use
A strong control, not a medical guarantee
Keep the end-user disclaimer
The engine checks the ingredient text supplied to it. It cannot inspect an undeclared additive inside packaged food, detect cross-contamination in a shared kitchen or know whether a supplier's label is accurate.
Your product should fail closed when verification cannot complete, preserve an appropriate diner warning, and route uncertainty to human review. Contract terms should define permitted claims, warranty boundaries, liability, taxonomy updates and incident responsibilities before production use.
Next steps
From first request to production
- 01
Prove the integration
Create a sandbox key, send representative safe and unsafe recipes, and confirm your product blocks rather than merely labels failures.
- 02
Define the operating boundary
Document which ingredient source is authoritative, who reviews uncertainty and what diners are told.
- 03
Select the licence
Estimate monthly volume, residency needs, support level and whether your own customers will see the safety claim.
- 04
Complete production acceptance
Agree versions and commercial terms, rotate to a production key, run your tests and monitor quota headers.
Ready to evaluate it?
Start with the full verification engine in the free sandbox. No card is required.