API Lifecycle & Reuse in Test Cases

API Definitions are designed to be reused across the testing lifecycle. Once created, an API can be referenced by multiple test cases, updated over time, and executed consistently without duplicating request logic.

Why it matters

• No duplication: The same API logic is not redefined in every test case.
• Centralized updates: Changes to an API Definition apply everywhere it is used.
• Long-term maintainability: Tests remain readable even as APIs evolve.

When to use it

• You want to reference an existing API inside a test case.
• Multiple test cases rely on the same endpoint.
• An API changes and must be updated without rewriting tests.

Core concepts

• API Lifecycle – the journey of an API Definition from creation to execution.
• Reuse – using the same API Definition across multiple test cases.
• Binding – linking a test case step to a specific API Definition.
• Execution Context – parameter values provided at runtime.

How it works

1. An API Definition is created and validated in API Manager.
2. The API becomes available for selection inside test cases.
3. Test cases reference the API Definition instead of embedding request logic.
4. During execution, test-specific values are injected into the API.

How to use it

Step 1: Create and validate the API Definition

Before reuse, ensure the API:

• Has correct endpoint, method, and authentication.
• Includes all required parameters.
• Passes at least one successful test execution.

Step 2: Reference the API in a test case

Inside a test case:

• Select an existing API Definition as the action or validation step.
• Map test-specific values to the API parameters.

Step 3: Provide execution values

At runtime:

• Parameter values are supplied by the test case.
• Defaults defined in the API may be used when no value is provided.
• Array parameters may result in multiple executions.

Step 4: Execute and evaluate

The API executes using:

• The latest saved definition.
• Values provided by the test case.

Step 5: Update the API over time

When the API changes:

• Update the API Definition in API Manager.
• All test cases automatically use the updated version.

Best practices

• Treat API Definitions as shared assets, not test-specific objects.
• Validate APIs independently before binding them to test cases.
• Communicate breaking API changes to the team before updating definitions.
• Use clear API names to make reuse obvious.

Common mistakes

❌ Mistake 1: Duplicating the same endpoint in multiple API Definitions
✔ Fix: Use one shared API Definition and reuse it across tests.

❌ Mistake 2: Modifying an API Definition to satisfy a single test
✔ Fix: Keep APIs generic and pass variations through test parameters instead.

Security & permissions

• API reuse follows project-level access controls.
• Only authorized users can modify API Definitions.
• Test cases consume APIs but do not expose authentication details.

Related documentation

• Creating a New API Definition
• Parameters in Depth
• Testing an API
• Test Case Overview