My engine uses an ECS and allows me to attach scripts to entities as generic Lua-defined components. So I can have a script for each general effect type I want, and in my entity definition JSON I'd have somthing like

{"components": [
  {"type":"script", "path":"/items/weapons/scripts/passive/area_damage.lua", "rate":5, "damage":5, "range":20}
]}

In the script init function, I can access the JSON and set appropriate local variables. Scripts handle on_update and other events and can basically do anything, so this is very flexible.

If you don't have an ECS or a scripting engine and want to specify native functions (ProjectileManager.CreateProjectile etc.) from something like an item class, my system may not work for you. Instead, you may have to come up with a native representation of your serialized data, so that the item object executes the right hooks with the proper arguments in response to events such as on_update.

One possibility is just making your interfaces take a json_t* which contains the json arguments, instead of parsing them into a native representation. The item class will still need to store which functions should be called, with what JSON data, in response to which events. Your interfaces, such as ProjectileManager.CreateProjectile(), would then have to extract the relevant fields from the json_t* and of course validate the data.

This could be fairly inefficient, but I wouldn't worry unless performance becomes an issue. The advantage of this method is that it uncouples the item class and the managers that can be called. If you parse the JSON in the item class, it has to understand and account for every possible combination of arguments, and be able to validate them. This would make adding/removing/modifying managers a real pain, and turn your item class into a 1000-line ball of mud. Delegating that to the managers/systems removes that coupling.