Understanding API Dependencies

Prev Next

Traceable enables you to define an application’s dependency graph, ensuring accurate reachability testing during DAST scans. Many APIs depend on prerequisite calls; for example, an order must be created before it can be retrieved. By defining these dependencies, you ensure that Traceable executes APIs in the correct sequence and supplies valid data to dependent requests. Before running reachability tests, Traceable evaluates and normalizes the execution order, automatically resolving missing APIs, reordering calls to satisfy producer–consumer relationships, and applying fallback or transformed values when required. This approach enables reliable testing even when workflows involve authentication, resource creation, or partially defined execution orders.

Components of a dependency graph

The dependency graph supports the following components:

API Dependencies

API Dependencies

Note

The components listed below are optional and can be used independently.

Component

Description

order

Defines the sequence in which Traceable should invoke the APIs. This is useful for workflows that involve authentication, resource creation, and subsequent retrieval or modification.

dependency

Defines the producer-consumer relationship between APIs:

  • producers specify the APIs that generate values, such as IDs, tokens, or user attributes.

  • consumers specify the APIs that utilize the above values.

  • You can define the producers or consumers parameter dependencies using the exact keys (resource_fqn) or regular expressions (resource_regex).

transform_params

Defines the rules to modify request parameters before execution. These rules can perform either of the following operations:

  • Inject static values

  • Substitute values from a store

  • Override extracted values

values_store

Defines the fallback or test values that Traceable can use during reachability testing:

  • single_choice_store provides one value at a time from the list.

  • group_choice_store provides logically grouped values that must be applied together.

  • You can also define static key-value pairs for direct substitution.


Order normalization and dependency resolution

Before executing reachability tests, Traceable evaluates and normalizes the order section to ensure that all declared dependencies are satisfied.

During this process, Traceable:

  • Analyzes the dependency section to identify producer–consumer relationships between APIs.

  • Reorders APIs when a consumer appears before its producer, ensuring the producer executes first.

  • Automatically adds APIs to the execution order if they are referenced in the dependency section, but are not included in the order list.

As a result, the final execution order always ensures that:

  • All producer APIs execute before their dependent consumers.

  • All required APIs participate in reachability testing, even if they were not explicitly listed in the order section.

This normalization keeps reachability testing reliable even when:

  • The initial execution order is incomplete.

  • The order does not fully reflect data dependencies.

  • The dependency graph is only partially defined.

Note

In case of an endless (circular) dependency, Traceable exits the execution after the first iteration.


Sample dependency graph and execution

The following sample dependency graph defines each component:

order:
- POST /identity/api/auth/login
- POST /workshop/api/order
- GET /workshop/api/order/{order-id}
- GET /workshop/api/order
dependency:
- producers:
  - api_name: POST /identity/api/auth/signup
    resource_fqn: http.request.body.email
  consumers:
  - api_name: POST /identity/api/auth/login
    resource_fqn: http.request.body.email
- producers:
  - api_name: POST /identity/api/auth/signup
    resource_fqn: http.request.body.password
  consumers:
  - api_name: POST /identity/api/auth/login
    resource_fqn: http.request.body.password
- producers:
  - api_name: POST /workshop/api/order
    resource_fqn: http.response.body.order.id
  - api_name: GET /workshop/api/order
    resource_regex: http\.response\.body\.order.*\.id
  consumers:
  - api_name: GET /workshop/api/order/{order-id}
    resource_fqn: http.request.path.param.4
  - api_name: GET /workshop/api/order/{order-id}
    resource_fqn: http.request.body.order.id
transform_params:
- key: http.request.body.phone
  value: "19295784464"
  action: MODIFY
- key: http.request.body.role
  value: "$SINGLE_ROLE"
  action: MODIFY
- key: http.request.body.firstname
  value: "$GROUP_NAME_VALUE"
  action: MODIFY
- key: http.request.body.lastname
  value: "$GROUP_NAME_VALUE"
  action: MODIFY
values_store:
  single_choice_store:
    "$SINGLE_ROLE":
    - admin
    - manager
    - guest
  group_choice_store:
    "$GROUP_NAME_VALUE":
    - http.request.body.firstname: John
      http.request.body.lastname: Doe
    - http.request.body.firstname: Jack
      http.request.body.lastname: Sparrow
  http.request.body.order.id: 1001

Using the above dependency graph, Traceable executes the reachability test as follows:

  1. Traceable detects that the API POST /identity/api/auth/signup is required by the dependency graph, but is missing from the execution order. Because this API produces values needed by POST /identity/api/auth/login, Traceable automatically inserts it into the execution order.

  2. Traceable also inserts all the APIs from the specification that are missing in the provided order, based on the heuristics.

  3. In the order you provided, the consumer (GET /workshop/api/order/{order-id}) appears before one of its producers (GET /workshop/api/order), which violates the dependency requirement. Traceable automatically reorders the APIs to ensure that all producers execute before their consumers.

  4. After inserting any missing APIs and resolving ordering conflicts, Traceable executes the reachability test in the following sequence:

    order:
    - POST /identity/api/auth/signup
    - POST /identity/api/auth/login
    - POST /workshop/api/order
    - GET /workshop/api/order
    - GET /workshop/api/order/{order-id}
  5. Traceable prepares and executes the POST /identity/api/auth/signup API in the following manner:

    • Selects a grouped value for http.request.body.firstname and http.request.body.lastname from the group_choice_store ($GROUP_NAME_VALUE).

    • Substitutes http.request.body.email with a value from the single_choice_store ($SINGLE_ROLE).

    • Applies the defined transform rules and executes the API request.

    • Extracts and stores the producer values defined in the dependency section for the http.request.body.email and http.request.body.password keys.

  6. Traceable prepares and executes the POST /identity/api/auth/login API in the following manner:

    • Uses the defined producer–consumer relationship to substitute the same http.request.body.email and http.request.body.password values.

    • Applies any defined transform rules.

    • Executes the API request.

  7. Using the same approach, Traceable executes the POST /workshop/api/order API and extracts http.response.body.order.id. Traceable caches this value for downstream consumers.

  8. Traceable executes the GET /workshop/api/order API to optionally extract additional order IDs using regex-based matching.

  9. Traceable executes the GET /workshop/api/order/{order-id} API, substituting the resolved order IDs into the path and request body parameters.

  10. Traceable continues this process until it executes all APIs in the defined order.