Build a custom GPT that answers food questions with live Dietly data
A Custom GPT can use Dietly as a live food lookup instead of guessing nutrition values, by importing Dietly's OpenAPI schema as an Action. The whole job is to give the GPT one narrow retrieval task: when a user asks about a specific food, search Dietly, then report the returned product name with its per-100 g values and say when a field is missing. This page covers the setup, the instruction that keeps answers grounded, and the tests to run before you share it.
How the pieces fit
A Custom GPT with an Action is a thin layer over an HTTP API. You import an OpenAPI schema, the editor turns each described operation into a callable action, and the model decides when to call it. For Dietly the useful operation is GET /search, which returns a JSON array of foods. Nothing about the model changes; you are giving it a reliable way to fetch real numbers.
1. Create an Action from the schema
In the GPT editor, open Configure, then Actions, choose to create a new action, and import Dietly's OpenAPI specification. The official setup flow requires an OpenAPI schema and an authentication choice; a GPT can use either Apps or Actions, not both. See OpenAI's Actions configuration guide for current editor rules and any workspace restrictions.
2. Pick the least-privileged authentication
Dietly's public read endpoints can be tested with no key at all, which is the simplest starting point. If you do attach a key, configure bearer authentication and use a read-only key with a rate cap from the dashboard. Never paste a personal credential into the GPT instructions, a knowledge file or an example prompt, because those can be surfaced to users. Public GPTs that use actions also need a valid privacy policy URL in the action configuration.
3. Write instructions that ground the answer
This is what separates a grounded assistant from a confident guesser. Without it, the model will often answer a nutrition question fluently without calling the action at all, and the reply sounds like it read a label when it did not. The instruction forces the retrieval and forbids filling gaps with invented numbers. Keep it short and imperative; a long, hedged instruction gives the model room to decide the search was optional, which is exactly the behaviour you are trying to prevent.
4. Map user questions to a single call
Most requests reduce to one search. Keep the mental model simple for the GPT.
| User asks | Action behaviour |
|---|---|
| "Calories in Fage 0% yogurt?" | Search the product name, report per-100 g values and the serving if present |
| "Protein in an unknown store brand?" | Search; if empty, say no close match rather than estimate |
| "Is this good for keto?" | Report the carbs, but do not judge medical suitability |
5. Test real prompts before sharing
In Preview, try an exact product query, a spelling error, a generic food, an unknown item, and a question asking for a nutrient the response lacks. Confirm two things: the GPT calls the action when it should, and it can explain an empty result instead of inventing one. OpenAI recommends Preview testing before publishing or sharing a GPT.
6. Publish, then keep it honest
Once Preview behaves, you can keep the GPT private, share a link, or list it publicly. A public listing needs the privacy policy URL mentioned above and a clear description of what the action does. Set expectations in the GPT's own description: it looks up packaged foods in an open catalog, it does not give medical advice, and coverage is broad but not complete. Users forgive a missing product; they do not forgive an invented number presented as a label reading.
Maintenance is light because Dietly hosts the schema. If the API adds a field, re-importing the specification refreshes the action. Watch for two failure modes over time: the model quietly stops calling the action for questions it thinks it already knows, and it over-reports precision on a low-confidence record. The grounding instruction addresses both, but re-run the five test prompts whenever you change the instructions, since a small wording change can shift when the model decides to search. Treat the instruction block as the real product here; the action is plumbing, and the instruction is what keeps answers tied to real data.
When an Action is not the right tool
Use a normal Custom GPT with curated knowledge when the information should be static and reviewed by you. Use an Action when freshness matters, as it does for a catalog of hundreds of thousands of products. For a real application that needs user accounts, saved logs or multi-step tool flows, build a server-side integration instead of asking a GPT Action to carry application logic. The MCP server guide and Python quickstart cover those paths.