GPT actions with custom headers / OpenAPI compatibility

Generally, it works well, and I can build a simple workflow, even emulating user-level authentication to an acceptable degree. There are a couple of prominent issues that I assume are attributed to the service beta status, but are rather critical even for any POC/MVP level solutions involving external APIs. Note, that I have created my own API endpoints and have full flexibility to address all issues, but this might not be the case with general API cases.

  1. The schema parser/validator is not consistent, and I suppose, is running some particular/castrated version that prevents general v3 features from being used. Surely is related to how OpenAPI specs are consumed/added to the context. The issue is this has to be documented so that devs don’t have to guess what can be included in components, on what level parameters must be specified etc. Knowing that the spec is a part of the prompt helps quite a bit as it needs to be rather specific, but, generally a few words in docs would be appreciated.
  2. Custom headers are not acceptable, tried so many ways to feed those into the OpenAPI spec to no avail. This can have a workaround with API Gateways, or in my case, I just can modify my implementation, but I don’t think this wins many hearts of people who wish to simply connect the dots and viola. Hopefully, this will get resolved after beta.

Known reports on this subject:


Multiple APIs I would like to build actions for require more than one header in every request, so I simply can’t use them right now.

A workaround would be to build a simple server which can relay the requests. You can set any custom headers from your server code as you wish

1 Like

Thanks! Yes, that would be possible, however it defeats the benefit of being able to paste API docs to the actions GPT, then paste the supplied spec and have a GPT that connects to whatever service you need.

1 Like

Yes it’s a workaround until there is an official solution provided by OpenAI