# API call within a tag change script **URL:** \ **Category:** Ignition\ **Created:** [December 18, 2023, 5:10pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272 "2023-12-18T17:10:09Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![wschauer](https://avatars.discourse-cdn.com/v4/letter/w/ecccb3/32.png) [@wschauer](https://forum.inductiveautomation.com/u/wschauer)\ **Post date:** [December 18, 2023, 5:10pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/1 "2023-12-18T17:10:09Z")
Hello, I am looking for the best practices in terms of running an API call from within a tag change event inside a UDT. I have a CMMS API call that that pulls in current work orders. If possible I would like to be able to define how often each call happens inside the UDT's however I hadn't thought about managing concurrent calls. From reading through some similar posts this is by default limited to 3 threads if called directly in the UDT. Alternatively I think a gateway scoped script that looks for this specific UDT and calls each sequentially would work as well. What is the best way to handle this type of thing? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 18, 2023, 5:17pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/2 "2023-12-18T17:17:29Z")
> [@wschauer](#): > > by default limited to 3 threads if called directly Not just limited for the API. That is the limit for all concurrent tag events in the _ **entire gateway** _ (tag events meaning those defined on a tag, not in a project event). Under no circumstances should you **ever** make external calls from a tag event, nor wait or sleep in any fashion. A gateway tag change event would be an appropriate solution, and would automatically singulate API calls for the tags in its list to monitor. ---
**Author:** ![wschauer](https://avatars.discourse-cdn.com/v4/letter/w/ecccb3/32.png) [@wschauer](https://forum.inductiveautomation.com/u/wschauer)\ **Post date:** [December 18, 2023, 5:52pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/3 "2023-12-18T17:52:42Z")
Thanks for response. Is there any way to have gateway tag change events be dynamic when new instances of the UDT are created? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 18, 2023, 5:57pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/4 "2023-12-18T17:57:47Z")
No. Consider using a tag event that simply puts the affected tagpath into a persistent ConcurrentLinkedQueue (or perhaps a BlockingQueue), and use a timer event to drain the queue, making the API calls from there. (You will need to learn how to safely use `system.util.getGlobals()`.. Non-trivial, unfortunately, but there are examples here on the forum.) ---
**Author:** ![wschauer](https://avatars.discourse-cdn.com/v4/letter/w/ecccb3/32.png) [@wschauer](https://forum.inductiveautomation.com/u/wschauer)\ **Post date:** [December 18, 2023, 6:05pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/5 "2023-12-18T18:05:45Z")
Thanks, yeah I am not familiar with the system.util.getGlobals().. Sounds like it may be more straightforward to just crawl the tag tree looking for the specific UDT. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 18, 2023, 6:15pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/6 "2023-12-18T18:15:46Z")
> [@wschauer](#): > > just crawl the tag tree looking for the specific UDT Do you mean at runtime, or just once at design time? If the former, don't. Really. If the latter, look at the tag report tool. It can make a list of tag paths for you to paste in to the gateway tag change event's monitoring list. ---
**Author:** ![wschauer](https://avatars.discourse-cdn.com/v4/letter/w/ecccb3/32.png) [@wschauer](https://forum.inductiveautomation.com/u/wschauer)\ **Post date:** [December 18, 2023, 6:29pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/7 "2023-12-18T18:29:37Z")
🙂 Runtime. Thinking about a UDT that is instantiated via MQTT topic from a machine. As equipment is brought online i would pull the work orders daily if they exist. Not talking tons of equipment either but it would skip a step of manually going into the system to set this up each time. What would the reasons to not have this at runtime be? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 18, 2023, 6:31pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/8 "2023-12-18T18:31:30Z")
It is computationally expensive. How often would you need to scan for new devices? (Or could you scan upon user action, and cache the results?) If UDTs are going to come and go semi-randomly, learn to use a queue with `getGlobals()`. ---
**Author:** ![wschauer](https://avatars.discourse-cdn.com/v4/letter/w/ecccb3/32.png) [@wschauer](https://forum.inductiveautomation.com/u/wschauer)\ **Post date:** [December 18, 2023, 6:35pm UTC](https://forum.inductiveautomation.com/t/api-call-within-a-tag-change-script/83272/9 "2023-12-18T18:35:37Z")
Yeah makes sense. For each API call the UDT then parses it into individual tags as well so could add up. New devices would come online rarely but for each new device I would scan daily for the work orders. I will check out he getGlobals() as well.