Prevent infinite AJAX loop when using own API

I am currently trying to figure out integration between 2 WordPress plugins: the WooCommerce Follow Up Emails plugin, and the Ninja Forms plugin (with the end goal that we can send a manual-type followup email template as an action in response to ninja forms submission). We are using Ninja Forms 3, for what it’s worth.

When defining the options for the Action class I am providing a list of the templates to the user, so that when defining the action they can choose the template to send. To get the email templates from the follow-up emails plugin I am using their API client, specifically the get_emails() method (which, in turn, translates to a GET call to the /emails endpoint under their API URL).

The problem is this: On every page load the ninja_forms_register_actions action is called, during which I instantiate my action class. During the __construct call, we populate the settings for the action, and in order to do so, we call the Follow Up Emails API. This initiates a page load, during which the ninja_forms_register_actions action is called…

Although I did anticipate this problem, my planned solution did not help: that is, I had planned to use transients to store the result of the API call, like so:

private static function _get_templates()
    {
        error_log('_get_templates() started - ' . microtime(true));
        if (false === ($templates = get_transient(self::TEMPLATE_TRANSIENT))) {
            error_log('_get_templates() fetching - ' . microtime(true));
            $fue_api = self::fue_api();
            $templates = $fue_api->get_emails();
            set_transient(self::TEMPLATE_TRANSIENT, $templates, self::TEMPLATE_TRANSIENT_EXPIRY);
            error_log('_get_templates() fetched - ' . microtime(true));
        }
        error_log('_get_templates() done - ' . microtime(true));

        return $templates;
    }

However the result in my logs is the following:

[22-May-2016 23:53:33 UTC] _get_templates() started - 1463961213.692187
[22-May-2016 23:53:33 UTC] _get_templates() fetching - 1463961213.694222
[22-May-2016 23:53:34 UTC] _get_templates() started - 1463961214.05998
[22-May-2016 23:53:34 UTC] _get_templates() fetching - 1463961214.061054
[22-May-2016 23:53:38 UTC] _get_templates() started - 1463961218.660683
[22-May-2016 23:53:38 UTC] _get_templates() fetching - 1463961218.661265
[22-May-2016 23:53:40 UTC] _get_templates() started - 1463961220.772228
[22-May-2016 23:53:40 UTC] _get_templates() fetching - 1463961220.774142
[22-May-2016 23:53:41 UTC] _get_templates() started - 1463961221.150277
[22-May-2016 23:53:41 UTC] _get_templates() fetching - 1463961221.654757
[22-May-2016 23:53:45 UTC] _get_templates() started - 1463961225.306565
[22-May-2016 23:53:45 UTC] _get_templates() fetching - 1463961225.308898
[22-May-2016 23:53:46 UTC] _get_templates() started - 1463961226.281794
[22-May-2016 23:53:46 UTC] _get_templates() fetching - 1463961226.283803

Which continues until I kill the web server process or something else drastic like deleting/renaming the plugin folder, at which point the transient is filled with an HTTP error code (which is, in itself, unsurprising). So clearly my transient solution doesn’t work as the transient is still unset until after the request.

In some situations like this I would add a check for DOING_AJAX, however this doesn’t fit for two reasons – I still need this data to be available to the Ninja Forms AJAX processes, and also I am not sure if DOING_AJAX would actually be set here, as the FUE API does not use admin-ajax.php. I was considering changing to something like the following:

private static function _get_templates()
        {
            error_log('_get_templates() started - ' . microtime(true));
            if (false === get_option(self::TEMPLATE_LOCK_OPTION, false) && false === ($templates = get_transient(self::TEMPLATE_TRANSIENT))) {
                delete_option(self::TEMPLATE_LOCK_OPTION);
                add_option(self::TEMPLATE_LOCK_OPTION, true, '', 'no');
                error_log('_get_templates() fetching - ' . microtime(true));
                $fue_api = self::fue_api();
                $templates = $fue_api->get_emails();
                delete_option(self::TEMPLATE_LOCK_OPTION);
                set_transient(self::TEMPLATE_TRANSIENT, $templates, self::TEMPLATE_TRANSIENT_EXPIRY);
                error_log('_get_templates() fetched - ' . microtime(true));
            }
            error_log('_get_templates() done - ' . microtime(true));

            return $templates;
        }

But using options as locks feel dirty and wrong, and I feel like it leaves room for errors when object caching is in use (eg WPEngine et al). Is there a better/normal way to deal with this, or, alternatively, is there no real problem with the above?

Edit: So the lock solution doesn’t work 100% either – I’ve ended up doing this with a WP Cron job – every ten minutes we fetch the list of templates, rather than as needed, and store it in an option. I don’t like particularly like this solution – but I haven’t been able to come up with a better one as of yet. Still interested if there is a common solution for this problem.