I've got an API I'm using that has an OpenAPI spec. On the spec, the servers field is:
{
"openapi":"3.0.0",
"info": {
"title": "My API",
"version":"1.0.0"
},
"servers": [{"url":"/v1"}]
}
The server origin is not specified in the spec here (usually I imagine it's https://my-api.com/v1) but this spec doesn't. Retool correctly detects this in the resource configurator and specifies the full URL by inferring it from the spec path.
But when executing the resource on a route from the spec, Retool responds with an internal error saying Invalid url.
The way I've found to bypass this is by select the endpoint not covered bit which works.
Summary
An OpenAPI resource fails at query execution with an 'Invalid url' internal error when the OpenAPI spec's servers field contains only a relative path (e.g. /v1) and no absolute origin, even though the resource configurator infers and displays a full URL.
AI Response
This behavior stems from the spec's servers entry lacking an absolute origin, so Retool cannot resolve a valid URL when running an operation from that spec. The most reliable fix is to edit the spec so the servers URL contains the full absolute base URL (e.g. https://my-api.com/v1) rather than a relative path, then point the resource at that corrected spec. The bypass already identified — choosing the 'endpoint not covered' option and supplying the path manually — is a valid alternative when editing the spec isn't possible.
Sources
OpenAPI Resource with a custom base url
A solved thread on the same root cause (an OpenAPI spec without a usable absolute base URL) where editing the spec's servers entry to include the full absolute base URL and hosting the corrected spec resolved the issue.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a
,
, or
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. 