Skip to content

REST API

Jump to bottom
Shane Rounce edited this page May 11, 2026 · 4 revisions

REST API

All current routes live under:

adaptive-customer-engagement/v1

Public routes

POST /track

This is the main public tracking endpoint.

It accepts event payloads including:

  • session UUID
  • visitor UUID
  • event UUID
  • event type
  • page URL and path
  • post and taxonomy context
  • product or brand context
  • number ID where relevant
  • UTM values
  • limited metadata

The endpoint respects:

  • the plugin enabled setting
  • Do Not Track behaviour
  • admin-user ignore rules
  • rate limiting
  • bot detection

GET /number/resolve

This returns the most appropriate phone number for the current request context.

Useful request inputs include:

  • path
  • utm_source
  • utm_campaign

The response can include:

  • number_id
  • display_number
  • e164_number
  • label

Bot runtime routes

These routes are intended for bot middleware such as Lambda or another controlled runtime, not for open public use.

  • POST /bot/site-context/answer
  • POST /bot/site-context/search
  • GET /bot/site-context/document/{postId}

They read from current published WordPress content so a bot can answer from live pages, posts, and WooCommerce products rather than relying only on pre-generated FAQ-style content.

The caller must send the saved webhook secret in the X-ACE-Webhook-Secret header.

Admin routes

These routes require the plugin management capability and drive the admin app.

Dashboard and reporting

  • GET /admin/dashboard
  • GET /admin/sessions
  • GET /admin/sessions/{id}
  • GET /admin/companies
  • GET /admin/companies/{id}
  • GET /admin/commerce
  • GET /admin/calls
  • GET /admin/calls/{id}
  • GET /admin/numbers
  • GET /admin/numbers/{id}

Number management

  • POST /admin/numbers
  • PATCH /admin/numbers/{id}
  • DELETE /admin/numbers/{id}

Settings and helpers

  • GET /admin/settings
  • POST /admin/settings
  • GET /admin/settings/export
  • POST /admin/settings/import
  • GET /admin/connect-readiness
  • GET /admin/connect/resources
  • GET /admin/connect/assistants
  • GET /admin/connect/lex-bots
  • POST /admin/connect/lex-bots
  • POST /admin/connect/phone-numbers/search
  • POST /admin/connect/phone-numbers/claim
  • GET /admin/reporting-segments
  • POST /admin/reporting-segments
  • DELETE /admin/reporting-segments/{id}
  • POST /admin/privacy/purge
  • POST /admin/enrichment/test
  • GET /admin/sample-data
  • POST /admin/sample-data
  • DELETE /admin/sample-data

Notes for extension work

If I am extending the plugin, I want REST additions to follow the same basic pattern:

  1. capability checks on admin routes
  2. sanitisation close to the request boundary
  3. simple payload shapes
  4. predictable naming under the same namespace
  5. no speculative endpoints that are not yet wired into a real feature

The chatbot-related routes are still part of an active implementation area, so I do not yet treat their exact runtime contract as frozen.

Clone this wiki locally