Skip to main content

Common Questions

1. Is Apidog Free?​

Apidog offers free version. You can choose a suitable plan according to your actual needs. Please refer to the pricing page for more details.

2. How to handle the auth state?​

View documentation for auth state here.

3. If the API needs to call the login API to get the token to place in the header before sending the request, how do you implement it?​

View documentation for auth state here.

4. If the request parameters of API B depend on API A, how do you implement it?​

View the documentation for how to pass data between APIs here.

5. How to handle APIs with different domains under the same project?​

  • Method 1:

Create different services in the environment and set different base URLs for them correspondingly. The API group and API dimension can be associated with a certain base URL. We recommend this method.

  • Method 2:

Set URL as environment variable, such as DOMAIN_1. Write API path as https:///users. When the API paths start with http:// or https://, the system will automatically ignore the base URL.

  • Method 3:

Set different environments for different domains, and run APIs under different domains by switching the environment. We do not recommend this solution.

6. How do you read and modify API request messages through scripts?​

View the documentation for using scripts to read/modify API requests here.

7. Does it support using querying database fields as API parameters?​

Yes, we do support it. For more details, view the database operation documentation here.

8. Where do you store data? Is it stored locally or on cloud?​

Apidog offers three versions: Standard SaaS version, On-Premisses version, and Europe version. They have different data storage strategies respectively.

For the Standard SaaS version, the data will be stored in the cloud(AWS, United States), so you will need a network to access.

For the On-Premisses version, the data can be stored internally so that you can access it without extranets.

For the Europe version, data created or uploaded in Apidog Europe is exclusively stored within Europe region(AWS, Ireland). Check here to learn more.

TIP

the environment and global variables are stored locally. These will not be synced to the cloud and will not be shared among team members. Therefore, you can use them to store tokens, accounts, passwords, or other sensitive data.

9. My API call works as expected in Postman, why it returns an error in Apidog?​

Please check to make sure that the actual request messages (url, arguments, body, and header) delivered by postman and Apidog are the same.

  • Apidog:

Go to the actual request tab under return message to view the actual request message.

  • Posman:

Click on the Console in the status bar at the bottom to view the actual request message.

10. Why is there no change after modifying the value of the environment or global variable?​

  1. Please check if there are variables with the same name defined in multiple places in environment variables, global variables and local variables. The priority of different variables is as follows: local variables > environment variables > global variables.
  2. If there are variables with the same name, it will default to the variable type with the highest precedence.
  3. Please check if you modify the current value. Environment variables and global variables only read from current values, not remote values.

11. Can I use Apidog for Commercial Use?​

Yes. There are no restrictions on using the Apidog platform and the data you create within it for commercial purposes, or sharing internally within your company or with other individuals.

However, you still need to be aware of the disclaimers outlined in the TOS.

12. What is the Difference Between API, Requests and API Cases?​

Let's break it down using an analogy with your favorite restaurant:

  • APIs

    Imagine walking into your favorite restaurant and being handed a menu. Each dish on the menu is like an API endpoint, offering specific functionality. Just like a menu provides details about available dishes, an API specifies the functionalities (endpoints) and how to interact with them.

  • Requests

    A request is like placing an order based on the menu (API). It's a specific message sent to an API endpoint, asking for a particular action (parameters). For example, on the menu, you see "Pizza" (endpoint). Your request would specify the type of pizza (Hawaiian, Pepperoni), size (small, medium), and any additional options (extra cheese).

  • API Cases

    Bringing it back to the Apidog context, saving a Request as an API case defines specific ways to interact with each API endpoint. Each API Case is a variant of how you might order a dish (or interact with an endpoint) with specific parameters or conditions (like ordering your large pepperoni pizza with extra cheese). This allows for easier management and testing of different ways to interact with the same API functionality.

So, if you're testing how an endpoint responds to different types of inputs, you can have multiple API Cases under the same API endpoint. Each case adds a different combination of parameters (sides, toppings, cooking preferences), which is akin to customizing your dish orders. This not only makes debugging simpler but also makes it incredibly efficient to update and maintain API testing as your API evolves—similar to how a restaurant might update their menu over time.