An external mock API simulates a third-party API that your team does not control. It accepts representative requests and returns responses that let an application team develop and test an integration without depending on the real service. This is useful when the third-party API is unavailable or unstable, difficult to provision, expensive to call, or subject to a request quota. section 9.2 section 9.2.2
Choose the simulation and where it runs according to the test:
- Use canned responses for an early integration check. They are predictable, but can become repetitive or outdated. section 9.2 section 9.2.2
- Use dynamic responses or a configurable mock to exercise varied data, success cases, and errors. Mocks can also support tests of conditions such as high latency or random failures. section 9.2.2 section 9.2.1
- Run the mock locally for low-latency or offline work, or host it when multiple people, teams, or applications need access. Hosting location does not determine whether the API being simulated is external. section 9.2.2
Try the response modes
An illustrative Prism workflow uses an OpenAPI file: run `prism mock chapter8/apis/product-catalog.oas.yaml`, then request `http://localhost:4010/v1/catalog/categories` with `Accept: application/vnd.api+json` and `Authorization: Bearer my-secret-token`. Repeated requests return the same static response. Restart with `prism mock --dynamic chapter8/apis/product-catalog.oas.yaml`; repeated responses keep the same schema or shape but contain different values. This example demonstrates the mechanics, not a third-party API; an external mock simulates an API your team does not own. section 9.2.2
Use mocks to isolate automated tests from unreliable, costly, or restricted dependencies and to let client development proceed alongside API implementation. A sandbox is different: it runs an actual API implementation in a controlled environment. section 9.2.1 section 9.2
