API mocking tools are extremely useful for building API clients while the backend is being implemented. An API client is anything that consumes an API, so it includes UIs, CLIs, and other backend services. Using API mocks also forces you to think harder about the design of your API and to document it, both of which are good practices.
In the absence of API mocks, many teams use JSON examples as "documentation". This is a flawed approach, since JSON examples are not descriptions/schemas of the payloads and therefore have tons of limitations. For example, JSON examples can't tell you which fields are optional (unless you have a large collection of examples).
In my own experience, API mocks have been a life-saver in many situations, as they allow you to work on the client without relying on the backend as the source of truth. When it comes to APIs, the source of truth should be the documentation/specification.
In the past few years, there has been an explosion of services and libraries offering API mocks. I can recommend the following:
Of course, using mocks is not a replacement for testing the integration between the client and the actual server, but if you can make sure that client works with a server mock based on the API specification, and at the same time you validate that the server complies with the specification (using for example schemathesis ), you'll be in a good position to deliver a successful API integration.