This is quite fundamentally not solvable. As you correctly point out, the client cannot be trusted. You can't force the client to only give you data it obtained from the third party API if you can't communicate directly with the third party API. All you can see is the communication between the client and your backend, you cannot tell how the client arrived at the data it sends you.
A potential approach might be to reconsider whether your backend can't contact the third party API directly. Anything a browser can do, your backend can do as well. The only exception is if the network location such as the IP address becomes relevant when accessing the third party API, for example if this API imposes IP-based rate limits or if the third party API is not accessible from the public internet, but is accessible from the client's local network.
Another approach would be to reconsider the degree to which you must trust the user-submitted data. I have no idea what this data does, what business value it creates. In some cases, the user can only affect themselves. If they upload invalid or manipulated data, this will only affect the results they see, all other users are unaffected. In other cases, there might be a review or rollback process to handle invalid data after it enters the system. For example here on Stack Exchange, there is nothing preventing me from writing a factually wrong answer – but other people can edit or downvote my answer if necessary, and if I were to continuously abuse the system I would be banned.
You are using the word “replay”. You cannot affect the data the clients sends you. But you can enforce the order in which the client interacts with your backend. Typical examples include nonces or CSRF tokens that make it slightly more difficult to make requests to your backend. This can help with implementing rate limits or detecting anomalous behaviour, but by itself would only be a negligible protection against a determined attacker.
My suggested approach:
- Ensure that the third party API truly cannot provide the capabilities you need (e.g. direct requests, potentially performed on behalf of the user with OAuth, or digitally signed results). This is not purely a technical problem, perhaps it can be solved by talking with the third party.
- Otherwise, write down a threat model. What problems are you concerned about specifically, what capabilities would an attacker have?
- Do a risk assessment based on the threat model. What is the likelihood of such manipulation actually being a problem, and what would be the impact if it happens? Perhaps the risk is so great that your application is not feasible (some things just aren't possible!). Perhaps the risk can be tolerated.