For End-to-End testing, no, it's not great, but you may not have other options. If that's the case, as the test team, you need to make sure that the powers that be are aware of the risk that's being taken by mocking versus true end-to-end testing. They also need to realize that the mocking isn't free; you're going to have to maintain and update the mocking tool. You might want to give them classes of problems (performance, serialization, etc) that you won't be able to properly test.
With that said, though, there might be other options. Some companies that provide API services also provide some sort of test interface as well; instead of sending requests to http.company.com, you'd point to test.http.company.com. And you listen to test.queuemanager.company.com, not queue manager.company.com.
Another option, unpleasant as it can be, is time-based. Is there a time during the week/month/quarter that the overall service isn't needed? If so, you can always do your end-to-end testing then. Just be aware that this usually tends to happen from, say, midnight-8 AM Sunday, or something similar. You could still do most of your testing with mocking, and then have a final checkout with the real system. Some companies will deliberately schedule downtime for systems to allow this sort of testing to be done. But this requires a great deal of planning and coordination; there's no "Just one more test . . ." opportunity.
And, as @dzieciou says, record/playback is also an option, though it depends on what sort of changes you're testing.
And to answer your specific question: happy path testing with mocking is easy. It's testing failures that can be hard, because there are many, many different types of failures. And with End-to-End testing, it's often the failure states you need to focus on. You don't need 1 happy path test and 1 sad path test, you need 1 happy path test and many sad path tests.