Skip to content

Settings

What each setting controls and recommended defaults.

Settings reference

This guide explains what each major settings group controls and how to pick safe defaults for common deployment models.

This reference is based on approved schema/UI copy. Some options may vary by plugin version; see the plugin admin UI.

Settings categories

API surface and endpoint exposure

These controls define what the API exposes:

  • extensions.*.enabled toggles provider modules (for example bookings, forms, affiliate, Woo-related extensions).
  • Endpoints tab route toggles let you disable routes you do not need.
  • Endpoint access mode supports Any or API key only for selected routes.

Recommended baseline:

  • keep only required extensions enabled
  • disable unused routes
  • use API key only for high-impact server integrations

Auth modes

Identity and auth controls live under identity.* and tokenAuth.*, including:

  • identity.serviceAccounts.enableApiKeys
  • identity.registration.enabled
  • identity.passwordReset.enabled
  • identity.passwordSet.enabled
  • identity.security.emailExistsEnabled
  • identity.security.sessions.enableSessionListing
  • tokenAuth.enabled
  • tokenAuth.ttlSeconds

Recommended baseline:

  • enable only auth paths your product uses
  • keep service-account keys disabled unless you actively use server-side integrations
  • prefer least-privilege scopes for every key

Rate limiting

Rate controls are under security.rateLimit.* and identity security presets:

  • security.rateLimit.couponApply.enabled
  • security.rateLimit.couponApply.ipLimit
  • security.rateLimit.couponApply.windowSeconds
  • security.rateLimit.couponProbe.enabled
  • security.rateLimit.couponProbe.maxInvalidAttempts
  • security.rateLimit.couponProbe.windowSeconds
  • identity.security.loginRatePreset (paranoid, balanced, relaxed)

Recommended baseline:

  • keep the coupon probe limiter enabled
  • start with balanced login preset
  • tune limits per environment based on observed traffic and false positives

Suspicious request scoring

Suspicious request handling policy is under security.suspiciousRequests.*:

  • security.suspiciousRequests.mode (off, log, throttle, block)
  • security.suspiciousRequests.scoreThresholdLog
  • security.suspiciousRequests.scoreThresholdThrottle
  • security.suspiciousRequests.scoreThresholdBlock
  • security.suspiciousRequests.windowSeconds
  • security.suspiciousRequests.excludeRoutes

Recommended baseline:

  • keep suspicious request checks enabled
  • start in log while validating integrations
  • move to throttle or block once normal traffic patterns are confirmed

Field guide (plain-language meanings)

  • cors.allowedOrigins: Exact browser origins allowed to call the plugin API.
  • requestSize.bytes: Maximum accepted request body size.
  • requestSize.scope: Whether the size cap applies globally or only to HWP routes.
  • logging.ipStorageMode: How client IPs are stored in logs/events.
  • logging.maxBodyChars: Maximum request body characters retained by logs.
  • cache.publicMaxAgeSeconds: Public cache max-age for cacheable responses.
  • identity.security.password.minLength: Password floor enforced by identity rules.
  • identity.security.registrationSecurityMode: Registration hardening preset.
  • identity.security.generatedPassword.length: Generated password length when plugin creates one.
  • commerce.checkout.enabled: Master toggle for checkout endpoints.
  • commerce.checkout.strategy: Checkout behavior (stub, redirect_to_woo, token_handoff).
  • bookings.guestTokens.ttlSeconds: Lifetime for booking guest tokens.

Safe defaults guidance

Use this order when hardening a new environment:

  1. Restrict cors.allowedOrigins to exact known origins.
  2. Keep coupon probe protection enabled and use conservative rate limits.
  3. Start security.suspiciousRequests.mode=log, then raise to throttle or block.
  4. Keep identity.serviceAccounts.enableApiKeys=false until needed, then issue scoped keys.
  5. Enable only required extensions and endpoint routes.

Common configurations

Server-only apps (backend-to-backend)

Typical posture:

  • endpoint access mode set to API key only where possible
  • identity.serviceAccounts.enableApiKeys=true
  • tokenAuth.enabled only if your integration requires bearer tokens
  • browser CORS minimized or unused
  • strict route enablement (only machine-consumed routes)

Operational notes:

  • keep API keys in server secret storage only
  • use scoped keys per job/service
  • audit logs and security events for scope denials and rate spikes

Typical posture:

  • browser flows use cookie sessions + nonce habits
  • server jobs use API keys with scoped access
  • CORS allowlist contains only your production/staging UI origins
  • suspicious request mode starts at log during rollout, then hardens

Operational notes:

  • keep endpoint toggles tight for both browser and server traffic
  • use correlation ids to trace cross-surface issues
  • review security events after deploys for regressions