I want to mention how dependencies can be tested with a test plan. suppose we have dependenies with external web services, that the api implementation we provide depends on and the dependency communicates directly with the client and the we get notified by the client. In such a case, we have a circular flow of data where the flow is unidirectional.There is no way to flow the data in the reverse direction to see if the path is the same  and that all participants are working correctly. There may be latency in the data to come back once we have passed it to the dependency. During this latency, there is no way to guarantee that the data made it back to the client. Therefore it's important to enable a mechanism to detect and diagnose issues.
Since we are talking about only three participants, one way to do add this diagnosability would be to add duplex communication between the API server, the client and the dependency.
The API server need to check with both the dependency as well as the client.

When making a call to the downstream dependency, the API needs to check if the response was forwarded. With whatever capability the dependency provides, we should look forward to a suitable check. Suppose the dependency provides only CRUD functionality for an object. Then we can use the update to see if the object was created.
Similarly, the API server can check the client. If the client requests to register an information, we can look into the information to see if it originated from our server. This is important because this way we know that the data has completed the round trip.
The server should maintain a database for the domain objects only because it could compare with what was provided to it and what it sent over.