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.

8

We have reproduced the issue where importing with Security Schemas creates duplicates with new IDs instead of maintaining associations with the main branch. This will be fixed in an upcoming update to ensure child branches properly reference the main branch’s Security Schemas.

9

Thank you for your answer. I’m glad to hear that the bug will be resolved soon. I would also like to ask if you plan to remove the inconsistent IDs in the response examples (the original reason why I filed this report, I noticed the inconsistent Security Schema ID behavior much later). I guess this is also crucial, but I have a feeling it might have been done intentionally for some cloud-mocking purposes or something like that. Please let me know if you need a step-by-step list to reproduce it.

10

Sure, you can provide the specific steps for me to verify this issue.

11

  1. Create an empty project.
  2. Create an endpoint with a response example.
  3. Export this project using Apidog JSON (I think this is the most accurate export option, correct me if I’m wrong).
  4. Import the project using the file from the previous step.
  5. Check the changes in the endpoint changes history.

Expected: Nothing should change, as Apidog wasn’t modified between export and import.
Current behavior: IDs for responses are changed, ordering is modified, and some fields are added to the request body. This list is quite short because it was a testing endpoint, but a fully configured endpoint will contain many more changes. By “fully configured,” I mean only the endpoint’s configuration from the edit tab; for now, I will ignore what happens with Test Cases/Mocks and assume they contain default settings or are empty. This behavior is crucial because it breaks the possibility of making MR reviews / resolving conflicts using Git. (Short reminder: I would like to use Apidog with Git as the source of truth, using Apidog only as an editor/representer.)

The same behavior is observed when, in step 4), I create a new branch based on main and perform the import there.

12

Thank you for the information. We will confirm and get back to you.