Email, Webhook, and WordPress Hook Actions

Action tools can send HTML email, issue an HTTP GET/POST, or call a namespaced WordPress filter and return its result.

Action tools cause work outside the conversation. Email uses WordPress mail, webhook actions make a real HTTP request, and WordPress Hook actions call a namespaced filter supplied by custom code. The administrator test uses the same implementation, so a test can send a message, create a remote record, or run business logic just like a visitor-triggered call.

First, choose the action type and keep enabled off. The useful result comes later when you enable, run one visitor test, then monitor logs and the receiving system, because configuration values matter only when their effect can be seen in retrieval, a generated reply, visitor access, or the connected service.

What this feature does and when to use it

Use an action only when its destination, input validation, failure handling, and authorization are acceptable for visitor-triggered execution.

Use this feature in the following situations:

• A qualified lead or support request should be delivered to a controlled mailbox.
• An approved HTTPS service accepts a small validated GET query or POST JSON body.
• A companion WordPress plugin provides a secured custom callback and returns a safe result.

Choose the right feature

Do not connect irreversible, high-value, private-network, or weakly authenticated operations directly to a public assistant. Add server-side authorization, idempotency, and human approval where needed.

Where to find it

WordPress locationWordPress Dashboard → AI Website Chat → Tools → Add Tool

Before you begin

• SmartSite Assistant is installed and activated.
• You are signed in with an account that can manage WordPress options.

Set it up step by step

1. Choose the action type and keep Enabled off.
2. Define the smallest parameter schema.
3. For Email, configure a fixed To address and reviewed Subject/Body/CC/Reply-To templates.
4. For Webhook, configure HTTPS URL, GET or POST, and optional JSON headers; keep private/internal targets disallowed.
5. For WordPress Hook, choose the suffix consumed as smartsite_tool_{action} and ensure a callback is installed.
6. Run a test in a sandbox destination and inspect the real side effect.
7. Enable, run one visitor test, then monitor logs and the receiving system.

Fields, controls, and important values

Action tools let a conversation trigger email, an HTTPS request, or a WordPress callback. Their templates and destinations determine the real-world result; the AI only supplies arguments and decides when the described tool is relevant. Precise descriptions reduce accidental selection, while server-side validation, fixed recipients, authentication, and idempotency protect against unsafe or repeated actions.

Fields, controls, and important values

Field, control, or status	What SmartSite Assistant does with it	How to use it and why it matters
Email	Uses wp_mail with HTML content and nl2br. To is fixed/validated; Reply-To is validated after substitution.	“Email” shapes the email produced by the tool rather than the conversational answer. Use a safe test recipient, review every placeholder expansion, and make repeated calls harmless before visitors can trigger it.
Webhook GET	Sends arguments as query parameters.	Choose GET only when the receiving service expects arguments in the query string and the operation is safe to repeat. Query values can appear in logs and URLs, so avoid personal or secret tool inputs.
Webhook POST	Sends arguments as a JSON request body.	POST places the tool arguments in the request body, which suits structured or action-oriented integrations better than a query string. The receiver must still authenticate, validate, and make repeated deliveries harmless.
Headers	Optional JSON object. The HTTP timeout is 15 seconds.	Configure “Headers” from the receiving system’s documented contract, including method, headers, and expected response. It can deliver data used in an answer or action, but it cannot make an unsafe destination trustworthy.
Allow private/internal HTTP targets	Switches away from WordPress safe remote request behavior. Leave off unless an expert has reviewed SSRF and network risk.	Leave internal destinations unavailable unless a tightly reviewed integration genuinely requires them. Enabling this can let model-influenced requests reach services that were never designed for public conversation traffic, so network placement alone is not adequate protection.
WordPress hook action	Calls apply_filters("smartsite_tool_" . action, null, arguments); it is a filter despite the UI name “action.”	Evaluate “WordPress hook action” as part of the complete tool, including selection, arguments, side effects, and returned data. A useful description can improve tool choice, but only defensive code can prevent disclosure or unwanted actions.

How to confirm it is working

Success looks like

One intentional test reaches the approved destination, produces a 2xx/result, and returns a safe response to the assistant.

After saving Email, Webhook, and WordPress Hook Actions, repeat the final test with clean context. That distinction matters because WordPress can store a valid value even when remote processing, access rules, caching, or delivery prevents it from influencing the real experience.

Practical example

Post a support lead to a dedicated HTTPS webhook that validates its own shared authentication and field schema.

Recommended practice

• Change one part of Email, Webhook, and WordPress Hook Actions at a time and keep a short record of the previous value and test result.
• Use synthetic arguments and inspect the complete raw result before letting the model call the tool in visitor conversations.

Important warnings

Before using this in production

• Admin tests execute real actions. Use a sandbox inbox/endpoint.
• Allowing internal HTTP targets can expose services reachable from the WordPress host.
• A 2xx webhook status indicates transport success, not business completion.

Common problems and focused checks

Common problems and focused checks

Problem	What to check and what to do next
Webhook test fails.	Check HTTPS/DNS, 15-second timeout, method, header JSON, remote response status, and whether safe HTTP blocks the target.
WordPress hook returns no useful result.	Register a callback on the exact smartsite_tool_{action} filter and return a serializable value.
Email, Webhook, and WordPress Hook Actions is missing or does not match this guide.	Confirm the plugin is active and the account can manage WordPress options. Keep the tool disabled while comparing its schema, arguments, implementation result, and any side effect.
A change on Email, Webhook, and WordPress Hook Actions does not produce the expected result.	Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Keep the tool disabled while comparing its schema, arguments, implementation result, and any side effect.

Screen reference

tools-action-tools

Screenshot capture pending /images/screenshots/tools/action-tools.webp

Email, Webhook, and WordPress Hook Actions

Capture

Show a sanitized Webhook Action form with an example.invalid HTTPS URL, POST selected, safe targets enforced, and Enabled off.

Show

URL, method, headers JSON, private-target toggle, parameters, Test, Enabled

Viewport

Desktop, 1440 × 900

Annotate

Use numbered callouts only for controls referenced in the procedure.

Redact

OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text

Related guides

• Parameters
• Developer hooks