JetFormBuilder: action — read form data, call external API, write result back

Most custom JFB actions follow the same data-flow shape: pull values out of the submitted form, optionally interpolate admin-typed templates with %field% macros, hit an external HTTP API, transform the response, write it back into the form context so downstream actions can read it, and (optionally) dispatch a custom JFB event based on the outcome to fan out to conditional follow-up actions.

This skill covers that full lifecycle inside do_action(). It complements jfb-form-action (which covers the action class structure) and jfb-action-events (which covers event dispatch). This one is specifically about the PHP-side data flow — the API surface JFB exposes for read/write/macro/dispatch from inside an action.

API stability note

The jet_fb_context() global (with get_value, update_request, has_field, resolve_request), Tools::sanitize_text_field(), and the Tab_Handler_Manager::instance()->options( $tab_id ) accessor have been stable across JFB 3.x in source observed. The WordPress HTTP API (wp_remote_post, wp_remote_retrieve_body, WP_Error handling) is WP core. The plugin-version-tested value records last end-to-end verification.

When to use this skill

• A custom action calls a third-party HTTP API as part of its work.
• An action needs to read multiple form fields and interpolate them into a request body or instructions string.
• The admin should be able to write templates like "Verify %email% for order %order_id%" and have JFB substitute the field values.
• The API response should be written back into the form context so other actions can use it (for example, a "ChatGPT Decision" action writing the answer into a hidden form field that a "Send Email" action then includes).
• The action should branch the action chain based on the API response (success/failure/decision).
• The diff/files contain jet_fb_context(), update_request, wp_remote_post, wp_remote_retrieve_body, WP_Error, or macro substitution patterns like %[a-z_]+%.