Before you get the answer you are looking for, you need to decide on where you/your company stands in the spectrum of Testing:
- On the far right is something like Test Driven Development, which says for every line of code you write, you must have a failing test that some change or new line of code can fix.
- Somewhere in the middle is where other schools of thought are, they treat code as a black box and test only the value that comes out.
- On the far left you have no tests, or sparse tests.
With that aside, what you are talking about testing is a boundary, something between your code and someone else (Web Server, Database, etc.).
One of the great things about well written tests is they help you find what is causing a crash or bug quickly. However, something that close to a boundary, if the code is SOLID, could already be easy to find the problem; it would probably only break when the 3rd party code changed the JSON coming back - not within your code. So to me a test would not be merited
Two thoughts in closing:
You don't need TDD/tests to have good architecture, but good TDD & tests ensure (enforce) good architecture.
Testing on the boundaries often gets messy and hard to maintain. In general we have focused on writing good tests on the inner layers (DataLayer, NetworkLayer, Business Logic, etc.).