As a side note, if you can, rename your types. If you have two profiles which differ in their schema, it’s bound to confuse consumers of your API and other developers on your team.
Additionally, I found it extremely beneficial to keep the API hierarchy as flat as possible. Something I took away from @michaelhibay’s reading material, which I would also recommend you to read. This would lead me to your option 4.
So you would prefix all 20 resources that fall under the HR department umbrella for example with "type":"hr-*" ? So to keep some form of organization. Better use long resources name than nested ones is your mantra.
I’ll read @michaelhibay material, but I need some time for this, APIs are not something I do for a living.
Fortunately I do ‘do’ APIs for a living, and as part of the community am here to help. Once you have gone through the material, I think you’ll get an understanding of what I mean by using hypermedia APIs and the following response to Oliver.
I would also suggest renaming the resources, but my suggestion would be to have the renamed resources be a result of the output of properly developed domain vocabulary design, not a direct first step. Simply renaming the resources would only cover up the most obvious confusion problem, while leaving the more insidious and difficult to deal with concerns about redundancy across multiple domains. Realistically, the domains should be modeled in a semantically intuitive way, where the redundant or other confusing quirks could be identified before a lot of work has happened, or worse users have started using the system.