Sophos XG - Dynamic rule / object group members used in SOAR automation?

I am not planning to use Sophos Central, my XG firewall is standalone.

I have a fairly complex security stack setup with a separate IDS/IDS and SOAR type system along with a honeypot outside my firewall protected zones.

I would like to automate whenever a threat actor is probing the honeypot to automatically add their IP address to a host group object that is included in several rules to block access to other resources.

I have poked around in the advanced console shell and it doesn't look like there is anything I can do there to accomplish this. I was hoping there might be some sort of RESTful API or something that could be done via the SSH shell interface, but to no avail.

The only approach I can think to use is to use a FQDN host object in the firewall rules to point to a local zone that I control and can populate that FQDN with multiple A records as each honeypot hit occurs. The problem with this approach is I don't see any nerd knobs to control how often the XG tries to resolve FQDN entries in firewall rules. It also means I have to hassle with a bind instance for this purpose. I already use a bind "DNS firewall" for all DNS resolution, and for various reasons would need to run a seperate instance. It appears the "DNS request routing" feature which I could use for a conditional forward for the blocking FQDN (threatactors.local) could point to an internal host to accomplish this, but it doesn't support setting a TCP/UDP port, assuming it just uses 53. So I can't just run a smaller bind instance on a different port for this purpose. Also, is there a limit to the # of A records the XG will populate for a given FQDN?

Also, I am wondering if the XG will obey TTL records on FQDN entries and resolve them when the TTL's expire or is there some default timer that it goes through all the defined FQDN's to update them?

Is there any better solution out there that works within the XG product as I really don't want to chain another firewall product below it. Looking for a more elegant solution that is less complex and prone to failures or latency with updating the blocking rules.