# Creating tag groups with the openapi endpoints in the gateway? **URL:** \ **Category:** Ignition\ **Tags:** modbus, ignition83\ **Created:** [October 21, 2025, 9:46pm UTC](https://forum.inductiveautomation.com/t/creating-tag-groups-with-the-openapi-endpoints-in-the-gateway/111633 "2025-10-21T21:46:35Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 22, 2025, 3:55pm UTC](https://forum.inductiveautomation.com/t/creating-tag-groups-with-the-openapi-endpoints-in-the-gateway/111633/2 "2025-10-22T15:55:11Z")
> [@epaulson](#): > > is it possible to create and assign tag groups through the API the gateway exposes No, not through the rest API nor directly via scripting at present. It's very poorly documented at present because it's brand new to 8.3, but there is another possible solution to your issue; more on that later. > [@epaulson](#): > > (which I think is new in 8.3?) Correct, the entire many file based configuration storage is new to 8.3; prior versions used a SQLite "internal database" to store all configuration and we did not support editing that database directly. > [@epaulson](#): > > then even better, I think I can upload an ‘address-mapping.txt’ for it and get registers mapped For posterity, while you _can_ do this, the address mapping feature is generally recommended _against_ as an antipattern. While the ability to "know" which addresses you have when configuring tags later is nice, the added indirection only serves to make things more confusing when you're debugging. Further, it's a non-standard item that's Ignition specific instead of a more direct mapping of holding registers/etc that users of other SCADA/PLC software will probably find more readable. > [@epaulson](#): > > it looks like the default Modbus polling is 1 second, and the way to fix that is with Tag groups and adjusting the polling setting on the group There's an important distinction to pull out of this statement that will help you understand things. When you create a device connection in Ignition, ~nothing happens other than a device connection being made. Devices (mostly; some have different protocols that require this) do not poll by themselves. It is the act of creating an OPC UA subscription or read, **usually** by creating an OPC tag, that actually tells Ignition's built in OPC UA server to issue a read call to a device. That is, you can create a Modbus device connection, and whether populated with an address map or not, _nothing_ is being read from your device until you create Ignition tags that consume those OPC UA addresses. It is the **tags** you create that use the tag group settings, and that in turn means that your Modbus device is being polled at whatever your tag group rates are, but until those tags are made _nothing_ is being polled. In other words: you cannot assign **registers** to a tag group. You can give particular **tags** a tag group, and those tags in turn may be **reading** registers, which may sound like a distinction without a difference, but understanding that fundamental fact now will make things easier to understand down the road. > [@epaulson](#): > > I would like to avoid the Designer if possible, in part because at scale pointing and clicking is not ideal This isn't the worst goal, but part of using Ignition is going to be using the designer, and there's no reason to hamstring yourself now. In particular, "at scale" you're going to have a **much** easier time creating UDTs to make setup en-masse easier and less error prone, and there are tools like the multi-instance wizard built in to the Designer that just don't work without a GUI. > [@epaulson](#): > > Macbook with an ARM Ubuntu VM in UTM, and the Gateway works great, but Designer doesn’t run here. Run the gateway virtualized, but run the designer launcher "locally" on your Macbook. For one, performance is going to be much better. For another, that's how you should run things in production - you _shouldn't_ run the designer on the local environment where Ignition is installed. For a third thing, that's how you're going to end up running things when you're connected to 'real' systems - any number of gateways you connect to are going to end up being physically remote from your laptop so you're going to have to run the designer launcher somewhere to get connected. If you're worried about it, while I'm obviously not a neutral party, Ignition's installed applications are good citizens and won't cause a bunch of annoyances across your system if they're installed 'natively' - you can happily install and uninstall them as regular OS applications at will. * * * All _that_ said, like I said at the top it's not currently possible to create tag groups dynamically via the REST API or scripting. But I'll posit that truly dynamic creation is _probably_ not what you really need, and you could probably get by with creating a set of 'standard' tag groups for all your systems. The way to do that (immutably) in 8.3 is via the `external` resource collection. In the installation directory, in the `data/` folder, you'll see a series of folders in this directory: `data/config/resources/core/ignition/tag-group/` Each of those folders will correspond 1:1 with the 'realtime tag providers' defined on your system (probably just one named `default/`). In that folder you'll see a folder for each tag group you have defined; by default `Default/` and `Default Historical/`. In each of these folders will be two files, `config.json` and `resource.json`. You'll notice `config.json` has all the settings for any particular tag group. If you go up a few levels you'll also see a `data/config/resources/external/` folder. Any Ignition resources you create in that `external/` folder are **guaranteed** to be loaded by Ignition, and **guaranteed** not to be written back to by Ignition - they become immutable system configuration delivered by the filesystem. So if you're setting up a hundred gateways, and you've created Ignition resources in the `external/` directory of each, you can guarantee those resources are available (and cannot be removed). Also note that you can just create resources via the filesystem in `core/` if you want "regular" resources that can be modified/removed via the designer. "Creating" an Ignition resource via the filesystem is easy - just duplicate the folder structure, so that e.g. `data/config/resources/core/ignition/tag-group/default/Default/` Moves to `data/config/resources/external/ignition/tag-group/default/Default/` At that point, you can either hit the 'scan filesystem' button or restart your gateway, and we'll pick up those new resources. Some more context on the way Ignition "resources" are built up via disparate files: > [@Ignition internal Folder Structure](https://forum.inductiveautomation.com/t/ignition-internal-folder-structure/110717/2): > > I thought we had some kind of reference page for this in the manual, but all I found was this, which is not quite the full story: This old post of mine goes into more detail, though is a bit out of date: Basically: projects/ has an ignorable .resources/ folder. All other folders in projects/ will be scanned - if they contain a valid project.json manifest, then they make up an Ignition project. The name of the project will be the literal name of the folder on disk. Below each project direc… --- _[View the full topic](https://forum.inductiveautomation.com/t/creating-tag-groups-with-the-openapi-endpoints-in-the-gateway/111633)._