TrueSift WordPress integration

Built-in flow

Protected WordPress form
→ local POST /wp-json/truesift/v1/challenge
→ TrueSift POST /api/v1/botguard/challenge
→ local POST /wp-json/truesift/v1/verify
→ TrueSift POST /api/v1/botguard/verify
→ browser receives one-time verificationToken
→ protected form submits verificationToken + signed truesift_context
→ WordPress PHP calls POST /api/v1/botguard/proof/verify
→ protected action continues only when the trusted proof allows it

The browser result is UI state only. PHP never authorizes an operation from browser-provided allowed, decision, score, status, failOpen, challengeId, action, path, or origin fields.

Manual shortcode

[truesift]

Optional selectors:

[truesift form_selector="#contact-form" button_selector="button[type=submit]"]

Optional official display values:

[truesift visual_mode="banner" size="flexible" theme="auto" locale="auto" appearance="always"]

Custom PHP handler

$proof = truesift_verify_request();

if (is_wp_error($proof)) {
    wp_die(
        esc_html($proof->get_error_message()),
        esc_html__('Security check failed', 'my-plugin'),
        array('response' => 403)
    );
}

if (empty($proof['allowed'])) {
    wp_die(esc_html__('Forbidden', 'my-plugin'), 403);
}

// Perform the protected business operation here.

The helper reads truesift_verification_token and truesift_context from form data or JSON. It atomically consumes the proof and caches the trusted result only for the current PHP request, so multiple validation hooks in the same request do not replay the token.

Custom rendering from PHP

echo truesift_render_widget(array(
    'source' => 'my-integration',
    'form_selector' => '#my-form',
    'button_selector' => '#my-submit',
));

All custom actions should continue to use the official action configured in Settings > TrueSift unless the TrueSift site contract intentionally defines a different action.

WooCommerce Checkout Block

The same woo_checkout setting protects both checkout architectures.

For the Checkout Block, TrueSift is rendered immediately before the Checkout Actions block. The browser bridge publishes only these values under the truesift Checkout Store extension namespace:

{
  "verificationToken": "opaque one-time token",
  "contextToken": "signed WordPress form context"
}

The rest_authentication_errors boundary validates and consumes the proof only for the effective final POST /wc/store[/vN]/checkout request. WordPress REST method overrides are resolved with the same precedence as WP_REST_Server, so WooCommerce draft updates such as PUT /checkout remain draft updates even when the browser transports them as HTTP POST with _method or X-HTTP-Method-Override. Those updates do not consume a TrueSift proof.

Missing, invalid, expired, replayed, mismatched, reviewed, or blocked proofs on the actual final POST request stop Store API checkout processing. After a checkout processing failure, the client clears extension data and starts a fresh TrueSift verification because the previous proof may already be consumed.