An overly aggressive mock can work fine, but break much later

Then have your main function take in that json as a parameter (or class wrapping that json).

Then your code becomes the ideal code. Stateless and with no interaction with the outside world. Then it's trivial to test just like and other function that is simple inputs translated outputs (ie pure).

Every time you see the need for a mock, you're first thought should be "how can I take the 90% or 95% of this function that is pure and pull it out, and separate the impure portion (side effects and/or stateful) that now has almost no logic or complexity left in it and push it to the boundary of my codebase?"

Then the complex pure part you test the heck out of, and the stateful/side effectful impure part becomes barely a wrapper over system APIs.

You still need to write a test for how it all comes together and you should write tests for your error handling. You need a mock to respond with an error.

  value, err := externalLibraryFunctionFoo(a, b)
  if err != nil {
    return nil, fmt.Errorf("calling foo: %w", err)
  }