The first thing you need to clarify with your team is whether the tests they want to write are even unit tests at this point because when you start testing business logic along with the data layer, you're no longer dealing with pure unit tests. Unit tests should ideally isolate and test a single unit of code in complete isolation from external dependencies like the network or databases. What you're describing your team wants to achieve is more akin to integration testing.
Personally I would mock outer dependencies when writing a "Unit Test". Even if your team members are adamant of testing the data layer, intercepting network calls and injecting JSON responses will quickly become unwieldy, especially as your app's API surface grows. Managing these JSON payloads across multiple tests can lead to duplication, which will only make it harder to maintain and update when the API changes. Additionally, if your team ever needs to test edge cases or error scenarios, crafting the right JSON responses for each scenario will be a headache.
If your team still prefers the interceptor approach for now, you could suggest setting up a dedicated module or utility class to manage the JSON payloads centrally. This way, you can at least contain the complexity and make it easier to update or replace the payloads in the future.
Nvm, I just saw that you peeps are indeed writing integration tests and not unit tests in which case I am with what your team has decided. Mocking a certain section of the code defies what integration tests are set to achieve.