REST API

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

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/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