Skip to main content
12-Amethyst
September 16, 2026
Question

API cannot have a user modifying the project while the API is modifying the project?

  • September 16, 2026
  • 3 replies
  • 48 views

The project configuration seems really limited. Only allowing one person at a time to connect and make changes.

We were hoping the API would help but it seems to require giving itself write access over and over again for every edit you make, changing the project ID and not allowing, as far as I can tell, any kind of bulk import. So if I want to manipulate 100 tags it gives itself write access 100 different times and is fairly slow.

I'm not sure but it seemed like anytime the API was manipulated anything if there was another user live looking at the project they lost access.

Am I missing something? Is there a way to have more than one user editing a project at a time? Is there any way to bulk import devices and channels and tags in one shot with the API?

3 replies

Support
October 5, 2026

Greetings ​@Tanquen ,

 

What you are seeing is generally expected behavior with the KEPServerEX Configuration API. The project configuration supports a single configuration writer at a time, so if the API is making configuration changes while another user has the project open for editing, the other session may lose access or need to reconnect.

Regarding the API requiring write access for configuration changes, this is part of the configuration locking mechanism. If the script is acquiring and releasing write access for each individual tag modification, this can certainly add overhead when making a large number of changes.

For larger configuration updates, it may be worth reviewing the API workflow to minimize the number of individual write operations and group changes where the API supports it. The Configuration API does not provide a single call to bulk-import an entire hierarchy of channels, devices, and tags in the same way as a project import.

If you share the KEPServerEX version and a sample of how you are currently using the API to create/update the 100 tags, the community may be able to suggest a more efficient approach.


Regards,

Mohit

Tanquen12-AmethystAuthor
12-Amethyst
October 5, 2026

It's great that the API exists but if you can't do a bulk import and you're importing maybe 100 tags or more and it's constantly taking write access away and giving it back, just seems clunky. Then that means basically nobody else can use it while you're messing with it. It's also pretty slow because it's kind of logging in and adding a tag and then logging out and logging in logging out etc. Was just trying to verify that that is the way it works.

 And seemed the only other option was to replace the whole project through the API but then that takes it offline.

 We're using the latest version of Kepware Server. It doesn't look like the API has been updated in a very long time.

Support
October 8, 2026

Greetings,

 

Thanks for the additional context and for confirming your observations.

Yes, your understanding is generally correct. The Configuration API was designed around the same configuration locking mechanism used by the Configuration Client, which allows only a single configuration writer at a time. As a result, configuration changes made through the API can impact other users attempting to edit the project concurrently.

For large-scale configuration changes, repeatedly acquiring and releasing write access for individual operations can introduce noticeable overhead. While the API provides programmatic access to create and modify configuration objects, it does not currently provide a native bulk-import endpoint for channels, devices, and tags in a single request comparable to importing a project file.

In environments where a large number of changes are required, many users find it more efficient to build or modify the configuration offline and then import or deploy the updated project during a planned maintenance window. As you noted, replacing the project configuration can result in a temporary interruption while the new configuration is applied.

We understand your feedback regarding scalability and usability for larger deployments. The Configuration API has remained largely unchanged for some time, and your comments are valid considerations when managing high-volume configuration updates. We appreciate you sharing your experience with the community.

Regards,
Mohit