Knowing whether your application has internal only or at least some external users will help you figure out how defensive your coding and therefore your testing needs to be. For internal only applications, it's often possible to make the assumption that users will work in a more consistent way than if you have external users. Internal users have shared goals, training, purposes, and assumptions. In addition, if all users are internal users, the cost of error may be smaller. Of course, you need to check all of these assumptions. If they hold true, however, that implies that you can do less testing.
For example, if you have an API that is exposed for reporting, and the only reporting application is internal, you can be less defensive in the implementation of that API. You can, for example, assume that IDs will always be numbers without explicitly checking for it, as long as the consuming reporting application always uses IDs that are numbers.
Will this cause you to miss some problems? Absolutely. Not performing negative testing leaves you more vulnerable to problems caused when your users step off that positive path. However, that might be acceptable if you have more need to get features out quickly than to be able to handle change without explicit inter-group planning.
For applications used by external parties, you will generally have less notice of change and more variety in use cases seen in the field. Therefore, you need to do more testing that will expose problems in those scenarios - more negative testing.
As with most things in software development, how much you test off the happy path will depend on your specific circumstances. Just make sure you ask the questions so you can take advantage of your internal users wherever possible.