This article introduces some core concepts in Apidog. Many of these concepts may differ from similar products (such as Postman). Understanding these definitions and differences will help you better comprehend Apidog's workflow.Design-first Mode & Request-first Mode#
Apidog's APIs module features two modes that can be switched at the bottom left corner of the interface: Design-first Mode and Request-first Mode.Both modes provide similar functionalities but with different interfaces, catering to different team workflows.Design-first Mode is Apidog's recommended mode, suitable for teams following the API-Design First approach. In this mode, teams spec the API first and then proceed with development and testing based on the API spec.On the other hand, Request-first Mode is ideal for teams that do not initially define the API specifications. These teams typically focus on backend development, finalize the code, and then produce the API spec for testing and client-side work to begin.If you need to call APIs developed by someone else but you don't have the documentation, you should also use Request-first Mode.Endpoint#
Apidog is an API-first product, meaning everything starts with defining APIs, and Endpoints are the core elements in APIs.In Apidog's main interface, Endpoints are basic elements, grouped together in a directory form. For each Endpoint, you can modify its definition, preview it, send requests based on this endpoint spec, or save requests as endpoint cases.This structure is very different from Postman and is more like an extension based on OAS - an API spec that can directly debug and save requests.In Postman, the basic element is a request, and requests are essentially separate from API specs. This means that when the API spec changes, all requests and scripts need to be rewritten.In Apidog, all endpoint cases (corresponding to Postman's requests) are based on API specs. When API specs change, endpoint cases naturally change, and all test scenarios and CI/CD based on this can be automatically or manually updated, which is very suitable for development teams to maintain and update APIs.Request#
Test scenario#
When you need to send a batch of requests together (similar to running a Postman Collection), you'll need to use a Test scenario.Test scenarios also support logic components such as If, for, forEach, etc. You can pass data between requests, dynamically generate request parameters, and more.
Based on test scenarios, you can also view test reports, run performance tests, manage test data, integrate CI/CD, and more.Environment#
Environments in Apidog are similar to environments in Postman — they contain many variables. When you switch environments, you can use different values for the same set of environment variables. However, Apidog introduces another key concept: Base URL.In Apidog, the Base URL is the foundational part of the endpoint request address. When combined with the endpoint path, it forms the full request URL. Each environment can be configured with multiple Base URLs to support endpoint management across different services or microservices.This setup aligns with the OpenAPI(Swagger) specifications, where the endpoint path usually starts with a/, and the full request URL is created by combining theBase URLand the endpoint path.So, instead of writing the full request URL each time, you just enter the endpoint path (like/user), and Apidog will automatically splice the corresponding module's prefix URL configured in the current environment according to the module to which the endpoint belongs.For example, suppose your project has three modules, each representing a service. In the "Prod Env", their Base URLs are:User Service:https://user.example.com
Order Service:https://order.example.com
Product Service:https://product.example.com
User Service:GET /user/{id}
Order Service:GET /order/{id}
Product Service:GET /product/{id}
https://user.example.com/user/{id}
https://order.example.com/order/{id}
https://product.example.com/product/{id}
{{BaseUrl}} or duplicate environments for each module. Apidog will detect the module of the endpoints and automatically append the corresponding base URL in the current environment to form the full request URL.Module#
Within an Apidog project, you can use Module to organize endpoints logically. A module is similar to a "service" in technical architecture—it's designed to help manage endpoints better in scenarios like microservices.Each module includes a full set of related endpoints, components(schemas, responses, security schemes), and Base URL(one per environment), representing a standalone Swagger/OpenAPI specification file.When importing or exporting data, most formats (except the Apidog format) operate at the module level. This aligns more closely with OAS (OpenAPI Specification), enabling better standards compliance and easier integration with other tools.When you create a new project in Apidog, it starts with one default module. If you need multiple base URLs in one environment, you can simply create additional modules. All endpoints in a module will use that module’s base URL when making requests.Project#
A Project in Apidog consists of modules (endpoints and components), environments, test scenarios and more. It serves as the primary unit of collaboration. One project may contain multiple endpoint specifications.Compared to Postman, an Apidog project is roughly equivalent to a Postman Workspace. A module in Apidog corresponds to a Collection folder in Postman. Likewise, an Apidog Team functions similarly to a Postman Team. Modified at 2025-07-16 01:54:50
