Custom GPTs vs OpenAPI path parameters

Seems that the AI can't do idiomatic API calls for a RESTful interface after all - or their HTTP client has some bug.

TLDR: Don't use path parameters, at all, they don't work properly. Either do POST with params in the body or else use query parameters and declare them as required.

I spent a whole evening banging my head against a brick wall yesterday. The initial problem looked simple:

1. I have an api for cooking recipes/ingredients, bog-standard RESTful interface.
2. I have a custom GPT that is specialized on giving inspiration about what to cook.
3. Connect them!

Easier said than done. Let me explain.

The initial API spec:

I basically had the following actions defined in my openapi.json spec:

• POST /search that takes a query string as the body and returns a list of IDs and recipe names
• GET /recipes/{id} that takes the ID as the path param (yes, correctly specified in detail) and returns the informations about a recipe

only these two are the relevant ones to showcase the problem.

What GPT does

1. I added the openapi.json file as an action to my custom GPT, and the editor says its all correct. Cool!
2. Now I try using it by asking a question about some food
3. It uses the POST /search action just fine
4. It asks me which of the recipes I'd like
5. It uses the GET /recipes/{id} action
6. ERROR.
7. It uses the GET /recipes/{id} action
8. ERROR
9. It uses the GET /recipes/{id} action
10. ERROR
11. ...

and so on.

In the debugging output on the GPT test playground I could inspect the request/response debug information, and it looked good. It literally says that it is calling /recipes with the parameter id of some correct value. My server answered with an error though.

I used curl to directly test the same request against the same server, and it worked flawlessly.

The actual problem

Now this is kind of nasty to spot from their debugging hints in the online editor.

GPT actually made the request to /recipes (the /{id} part is stripped out!) and adds the parameter as a query parameter instead!

And after hours of trying various syntaxes and looking through the openai forums, it seems that path parameters just don't work in general.

The Solution(s)

That means for me: I have two options to get the same functionality somehow:

1. POST request with a body (this works just fine)
2. GET request with query parameters (this is what GPT does already)

It felt just wrong to use POST for getting some data by ID, it also can create trouble if you want to add some caching layers in front of your API. Therefore: query parameters it is! The new action shall be GET /get_recipe_details with ?id=something. Smells like very old PHP somehow, but I am fine with it, this API is not for humans/developers but solely for the machine to begin with.

Some small code refactorings later, and I got it running, and now it works flawlessly.

What saved my day quite a bit here: Thanks to Rust and actix-web, moving around these definitions and having the compiler telling you every mistake or missing/wrong configuration is extremely liberating. Also codegen from actix-web to openapi specification at runtime just works, no need to fiddle with these complex JSON/YAML files.

• Number of words: 540
• Reading time: 3 minutes
• Posted: 7 months ago

Technology

Stay ahead of the tech curve! Discover cutting-edge tools, trends, and insights tailored for solopreneurs and indie hackers driving innovation.

Indie Hacking

Dive into the world of solo entrepreneurship. Get insights and strategies for building successful, self-reliant tech businesses.

Backend Development

Uncover the power behind the scenes of web services and applications, focusing on creating robust, scalable backend systems that support frontend experiences.

Rust

A language empowering everyone to build reliable and efficient software. Futuristic swiss army knife and probably the most powerful mainstream technology today

fresh bites bot

Custom GPT as an alternative frontend to my website https://fresh-bites.online to allow for interactive recipe search and tweaking.

API

Traditional backend services with an API. Gets data from somewhere, processes it to extract valuable information, returns it on demand.