There are two basic approaches to what you want, I beleive.
One is to configure (by template or explicit -- template preferred) which items you will be sending back, specifically and explicitly (i.e. you know exactly how many, and what their names will be). This is the easiest, but not always possible.
The other is to configure the item dynamically by "Low level discovery" i.e. LLD. This lets you use a prototype item(s) and control at run time how many there are, and what they care called (within some limits). This is useful for things like switch interfaces, where you do not necessarily know how many will exist (and indeed with virtual ports it can change).
It is not clear from your posting which you need, but once you determine it, there are numerous examples. Where people often get confused is in treating the two steps similarly. If you need LLD, all it does is create the item definitions; you then still have to get data into them by either a pull (poll some agent for data) or push (zabbix trapper, possibly snmp trapper).
The normal (but not necessary) process is that LLD is infrequent (and usually more processor intensive) and the polling to fill in the data more frequent. In that case separate routines are used. It is also possible to use one routine which returns two sets of data - the JSON data to create the items via LLD (this comes back in STDOUT), and the item data via Zabbix Sender (to the zabbix server port) to populate the created items. Note if you do this the first time (or two) will not populate the items with data as it takes a bit of time for the items to fully be defined and ready, but subsequent calls to send both will work, as the LLD creation of an item that already exists is basically a no-op (I say "basically because if you FAIL to create an item during LLD it becomes eligible for automatic deletion, so you do need to send JSON for all items each time you do LLD).
Again, not completely clear you need LLD from your question; if not just create items for each one, and return them as separate items either from a poll to the agent, or again as zabbix sender (the advantage of "zabbix trapper" items populated by zabbix sender is you can with one remote operation calculate and send data for lots of items at once, as opposed to each item doing its own separate poll).
