I’m trying to support a new query parameter to a GET endpoint for my plugin. This parameter is a non-nested object, therefore I’m using the ‘deepObject’ style from the openapi spec in my openapi.yaml file.
E.g. Here’s an example query param object I’m looking to support:
{
"created_at": {
"lt": "2023-07-21T00:00:00Z"
}
}
Unfortunately, any request I try to make using this fails with the message ‘There was an error generating a response’.

Looking at the chrome dev tools, and my server logs, no request is made to my server, however there is this error in the console.

My openapi.yaml is valid, and I’ve sanity checked this all using GPT4.
My main questions:
- I’m aware that some parts of the openapi spec (e.g. allOf) are not currently supported for plugins, does anyone know if the deepObject style is supported?
- Has anyone successfully implemented an object query param for a GET request with ChatGPT plugins?
Thanks in advance.
ps. If anyone is aware of any documentation around which parts of the openapi specification are currently supported, that would be amazing.
I don’t know the answer, but a quick Q, (2 actually) 1) can you post the error in text format (people like to copy paste it for searches) and 2) if you take that part out, does it work ok?
Hi @Foxabilo,
The console error is:
_app-1fb29c81a8f25dfc.js:28 FatalServerError: Error in message stream
at onmessage (_app-1fb29c81a8f25dfc.js:33:231736)
at _app-1fb29c81a8f25dfc.js:33:215761
at _app-1fb29c81a8f25dfc.js:33:215591
at tt (_app-1fb29c81a8f25dfc.js:33:215318)
at async tb (_app-1fb29c81a8f25dfc.js:33:217336)
The app also sends a few messages to sentry.io (I assume to report the error, although they are getting a 429 response, so it’s likely that the error is not being properly reported).
if you take that part out, does it work ok?
Not 100% sure which part you’re referring to.
More info: My plugin works fine for all other requests, and it also works with this GET endpoint if the nested object param is not used. If I amend my openapi.yaml to switch the deep object to a regular string parameter, it also works.
Hence why I think the deepObject is the issue, and ChatGPT may not be handling this correctly.
Sorry, I should of been more clear. If you remove the deepObject
does it function without error. What I’m attempting to ascertain is the state of the codebase without any use of possibly unimplemented options.
Does anyone have any ideas on this? The relevant part of my openapi.yaml is:
parameters:
- name: created_at
in: query
description: Filter by creation date. Use an ISO 8601 string for exact match, or an object for range. Object can have 'lt', 'lte', 'gt', 'gte' fields (for less than, <=, >, >=) with ISO 8601 date-time values.
style: deepObject
explode: true
schema:
type: object
properties:
lt:
type: string
format: date-time
description: Less than the specified date-time.
lte:
type: string
format: date-time
description: Less than or equal to the specified date-time.
gt:
type: string
format: date-time
description: Greater than the specified date-time.
gte:
type: string
format: date-time
description: Greater than or equal to the specified date-time.
Would appreciate any help! 
Ok, so to wrap this up. After much experimentation, I believe that ChatGPT does not currently support the deepObject style, even though it is part of the openapi spec.
I would love to be proved wrong on this, so if anyone has any working examples, please let me know!
I managed to get around this by using parameters with names which match how the deepObject would have been serialised. i.e.
- name: created_at[lt]
in: query
description: Filter items for those whose created_at is < than the provided ISO 8601 datetime.
example: '2023-07-20T08:28:40Z'
schema:
type: string
format: date-time
- name: created_at[lte]
in: query
description: Filter items for those whose created_at is <= than the provided ISO 8601 datetime.
example: '2023-07-20T08:28:40Z'
schema:
type: string
format: date-time
etc.
As said, if people think I’m wrong here, (or if a fix is implemented) I would love to hear, as I’m keen to make use of this feature. 