We have a url query parameter used in many places: docs, api reference, quick requests, tests.
What is the best/fastest way to do a global replace for the name of this parameter?
The project has a live site. We want minimum outages.
We have a url query parameter used in many places: docs, api reference, quick requests, tests.
What is the best/fastest way to do a global replace for the name of this parameter?
The project has a live site. We want minimum outages.
To globally replace a URL query parameter name across your Apidog project with minimal downtime, you can export the project in Apidog format (.apidog.json), perform a find-and-replace in a text editor or IDE, then reimport the updated file. This ensures all instances (docs, API references, tests, etc.) are updated simultaneously. Remember to backup before making changes.
Cool. Thank you. Can I update in place my project by importing the newly updated .apidog.json? Or do I need to import the json file into a new project?
You can import the updated .apidog.json file into either your existing project or a new project, depending on your preference. Both options are supported in Apidog.
I am noticing a number of things missing when I import into a new project:
This is actually a good thing. Can you please give me some details how you preserve secret values on your backend? Encrypted in your DB? If yes, how does the encryption work? Using a cloud provider encryption service?
Understood. Not to hard to reconstitute
Yes, these were components references. Most time consuming part. Had to delete all those tabs with a 0 and readd them. A fix here would be great.
Did not know that - will use this trchnique next time. Also, when I created a new project I did that by saying picking un the exported Apidog JSON and importing a project with a new name.
It looks like it’s probably better to export in place, correct? iie have the project from which I exported opened when importing the JSON file. In that case 2 and 4 would not an issue. Potentially 1 too? Don’t know about 3.
2 & 4. You can create a new project and set up the same custom fields in project settings as your original project before importing. This will ensure all interface field values are properly imported.
using this version
Could you please share the problematic interface and corresponding response component in Apidog format (with sensitive data removed) so we can import and reproduce the issue? This will help us investigate the missing variables, project settings, and HTTP responses you mentioned.
hmmm…so the export jsoon should not have any secrets in it, correct? I could share that file if you provide me a secure mechanism to send you the file. Or can you just do the export from your side if I give you the project id?
done
I’ve imported the data you provided but couldn’t reproduce the issue - response components are correctly linked to interfaces and there are no duplicate global variables. Could you please detail your exact steps from creating the new project to importing, including all settings in the import preview dialog?
I’ve just exported from the old project using the Apidog format. then took that JSON and imported and gave the project a new name.
when I did the export and import I used to have version 2.7.4 I think, not 2.8.6 - could that have been the problem?
related to this: is the descprtion for the variable a new property?
since the secret values were not imported, I just went to the old project, in the buld edit script - copied all that and came and put it as bulk edit in the new project. Maybe I had to a description field?