Non-consistent overwriting during import with Apidog JSON

Bug Report
1

I would like to integrate Apidog and GitLab into my documentation update workflow.
I use Apidog JSON as the export format.

Steps before

  1. I exported the Apidog main branch and commit the export file to GitLab.
  2. I made some changes in the Apidog main branch.
  3. I decided to Revert the branch state by importing the previously exported file from GitLab (using default overwrite behavior).
  4. To verify the revert I checked chanhed of one endpoint.
  1. The changes was looking strange for me and I did import with the same file again.

Current Behavior

  • During the first import, schema data is not updated - fields remain empty (null).
  • On the second import (with the same file), the schema data is updated correctly.
  • Additionally, imports from the same file generate new IDs for response examples.

Expected Behavior

  • Schema data should be updated correctly on the first import.

Question

If it is possible, IDs in response examples should remain stable between imports of the same file. Is there a way to prevent IDs from changing when importing the same file?

Please let me know if you need additional details or clarifications.

2

Thank you for your feedback. We’d like to know if the inconsistent IDs in response examples are causing any specific issues for your workflow. If necessary, could you please provide screenshots to illustrate the problem?

3

Thank you for your quick response. The inconsistent IDs in the response examples aren’t causing any specific issues, as they don’t appear in the export JSON. I just haven’t found any information about that. Much more important for my workflow is that I am experiencing non-consistent overwriting during import with Apidog JSON, as my workflow is based on importing/exporting using Git as the source of truth.

4

Thank you for the detailed explanation. To better understand the issue, could you please:

  1. Confirm what changes were made to the endpoint before re-importing.
  2. Let us know if you refreshed the page after importing.
  3. Share how you verified the import results.

Screenshots of the process would help us reproduce the issue.

5

Well, for now it looks like Apidog can’t handle this properly.

I would like to have a workflow based on Import/Export files.

I can ignore the non-consistent overwriting during import with Apidog JSON (although it is still very bothersome).

The problem I can’t ignore → non-consistent Security Schemas during import.

Steps:

  1. Create any docs with Security Schemas in the Apidog main branch.
  2. Export the main branch.
  3. Create a sprint branch based on main (let’s call it develop).
  4. Import the content to the develop branch using the file from step 2.
  5. The Import Preview & Configuration pop-up will appear.
    image
    image1513×935 166 KB

Now you have two options:

Option 1:
6. Do not select Security Schemas for the import → this leads to imported (overwritten) endpoints having null Security Schemas, because the Security Schemas won’t be found.
As I understand it, during the export of develop, its content will be merged with main, right? But at the moment of importing into develop, the endpoints don’t have access to the Security Schemas from main.
So the endpoints fail to find SS → they set SS to null → broken branch/docs :warning:

Option 2:
6. Import with Security Schemas → this leads to imported (overwritten) endpoints having Security Schemas, BUT they won’t be the same as in main.
Instead, new duplicates with different IDs will be created.
Why? Why? Why? Why does importing (or exporting) require changing IDs?
So I end up in a situation where each export/import creates another set of orphaned duplicate Security Schemas, which eventually grow with exponential complexity in my export files. :warning:

Looks like Apidogs imports can’t be used in this way and I’m forced to use Apidog’s built-in Git…

Here is the workflow I would like to have:

README.txt (6.0 KB)

I don’t want to use Apidog’s built-in Git.
Can you suggest a solution for my problem or a workflow where I can primarily use Apidog as a docs-hosting tool, while keeping docs versions stored in my GitLab?

Do you want me to also make it shorter and more formal (so it’s ready to post as a bug report/feature request), or keep it as a more detailed explanation (like now)?

6

Thank you for providing such detailed information. We will look into how to better support your workflow scenario.

7

So, do I understand correctly that I can’t use Git for version control in my Apidog project at all? I’m fine with any reasonable workflow, even if it isn’t the easiest one, I just want it to be reliable.