Feedback

Hi Apidog Team, Please consider adding support in the module-level “Bind data source” option to use an existing Apidog request from the same module as the data source. Currently, data sources can be OpenAPI URLs, or Git-based YAML/JSON sources. It would be very useful if Apidog could simply run an existing request and use its response as the import source. Suggested flow: Bind data source → Existing Apidog request → Select request → Choose output type: OpenAPI / Postman Collection / other supported format This would allow users to handle custom authentication, headers, scripts, and external API calls inside a normal Apidog request, while still using Apidog’s existing import/sync logic. For example, a request could fetch a Postman collection from the Postman API, and Apidog could treat that response as a Postman Collection source and refresh the module. This would make the current data source feature much more flexible.

When using test scenarios, it would be nice if the auth token could be autofilled between requests easily, and would not be cleared when updating from an api spec or test case

Hey! I am moving over from postman, and work in the integration space of the world, so understanding API's is part of my life. Postman, for OAuth 2.0 has auto-refresh tokens, which is awesome, as when the token expires, postman will get a new one without me needing to go and click on to refresh/get. This would be super awesome, and make life super smooth compared to always going to refresh or get a new token depending on the service/timeout. Some services I work with have 30 minutes for the token.

Our API allows 2 types of Authentication: Bearer and API Key. Unless we are missing something, we can only choose 1 type of authentication. The root folder should allow multiple auth types to be declared. Each endpoint should allow to select 1 or more of these auth types. (maybe a multiselect?) The generated docs should show what auth methods are available, and for each endpoint, which one(s) are accepted. At the moment, it is very annoying testing each endpoint using different auth methods, as we have to go to root folder, change auth types then run the endpoint again.

The last changelog was for 2.8.29. We are currently on 2.8.32. I am curious what are the newer changes.

I tried to setup a local LLM model for using AI features. The connection not able to works beceuase some code issue I guess. I tried different endpoints but everytime the response is the same. It is also not working, If I don't set an API key, so setup a dummy one. I checked with powershell, end the endpoint is working in LMstudio. Please investigate it. We have a PRO subspription. Thanks!

When a request has variable extractors configured (e.g. extract $.id → global variable), Apidog generates the following pattern in the test script: ```js ;(async () => { const value = JSONPath({ json: pm.response.json(), path: expression, wrap: false }); pm.globals.set(formattedName, value); })(); ``` This async IIFE is invoked without await , making it fire-and-forget. The runtime does not wait for the promise to resolve before advancing to the next request in the scenario. As a result, global variables are not yet set when the next request executes, causing it to run with undefined or stale values. This breaks any multi-step scenario where each step depends on variables extracted from the previous response. Additional Context: The issue affects all auto-generated extractors across an entire scenario - every single extractor block has this pattern. Global timeout settings have no effect on this issue

When I click on “Generate client code” it is not exporting the body and headers values to me. Version 2.8.28

Hello Apidog Support, We are importing our API definition from an OpenAPI 3.0.3 specification. We have several request header parameters where the schema is referenced via $ref. The referenced schema is a string enum, and it also contains the x-apidog-enum extension with names and descriptions. Example: parameters: - in: header name: x-custom-source required: true schema: $ref: '#/components/schemas/SourceSystemEnum' components: schemas: SourceSystemEnum: description: Source system identifier type: string enum: - system-a - system-b example: system-a x-apidog-enum: - value: system-a name: System A description: Example source system A - value: system-b name: System B description: Example source system B After importing the OpenAPI file, the schema itself is recognized correctly in Apidog: if we open the schema/model, the field is shown as an enum and the enum values are visible. However, when we open an endpoint and try to execute a request in the UI, the request header field is displayed as a simple text input. It does not appear as a dropdown with the possible enum values. Could you please confirm whether Apidog supports dropdown rendering for request header parameters when the enum schema is referenced via $ref and includes x-apidog-enum? If this is supported, could you let us know what the expected OpenAPI structure should be? Thank you.

I'm experiencing a persistent bug where GraphQL suggestions disappear after switching between tabs. The Problem: > Schema is "Fetched" successfully, but autocomplete (Ctrl+Space) stops working once I switch to another endpoint and come back. It only shows basic word suggestions (abc icons), not the actual GraphQL schema fields. What I've tried (and failed): Disabled "Optimize in-project tab rendering". Cleared %AppData% cache and local storage. Manual schema refresh. Re-installing the app. The only temporary fix is restarting the entire app, which is very frustrating for large collections. This happens on both Desktop and Web versions. Please fix the state management for GraphQL tabs.