Docs/Integrations & Platform Ops

Integrations, APIs, Webhooks, and Platform Operations

The integration layer is intentionally generic and CodeCanyon-friendly. Buyers get API tokens, webhooks, email inbox ingestion, lead and ticket payloads, verification hooks, and platform utilities without needing vendor-specific CRM sync code baked into the core product.

1) Workspace API Tokens and Scopes

Workspace admins can create bearer tokens from Chat > Integrations. Tokens are scope-based and every API response is restricted to the current workspace.

Scope	Use
conversations:read	Read conversation lists and detail payloads.
tickets:read / tickets:write	Read, create-from-conversation, update, and reopen tickets.
leads:read / leads:write	Read leads, update lifecycle fields, and mark converted.
widgets:read	Read widget metadata, domains, and generated embed code.

Workspace API routes

GET   /api/v1/conversations
GET   /api/v1/conversations/{conversation}
GET   /api/v1/leads
GET   /api/v1/leads/{lead}
PATCH /api/v1/leads/{lead}
POST  /api/v1/leads/{lead}/convert
GET   /api/v1/widgets
GET   /api/v1/tickets
POST  /api/v1/conversations/{conversation}/tickets
PATCH /api/v1/tickets/{ticket}
POST  /api/v1/tickets/{ticket}/reopen

2) Webhooks and Signed Delivery

Webhooks are configured per workspace. Each endpoint can subscribe to specific event names or use wildcard patterns, and every delivery is stored with status information for replay or debugging.

Delivery headers

X-Aibot-Event
X-Aibot-Delivery
X-Aibot-Signature

Common event	When it fires
conversation.created	A new public widget conversation is created.
conversation.message.created	A visitor or agent message is stored.
conversation.status.changed	Status changes to open, pending, resolved, or closed.
lead.created / lead.updated	A lead is captured or changed.
lead.qualified / lead.converted	A lead reaches a later commercial milestone.
conversation.sales_intent.detected	Sales intent is detected for the first time.
widget.offline_submission.created	A visitor leaves details while the widget is offline.
ticket.created / ticket.updated / ticket.reopened	Ticket lifecycle operations occur.

3) Email Inbox and Reply-by-Email

Email channels let the support desk behave like a shared inbox. The application exposes an inbound endpoint that receives parsed email payloads and turns them into chat conversations. Agent replies on email-originated conversations can then be sent back out through the configured mail channel.

Inbound email endpoint

POST /api/v1/email/inbound/{emailChannel}
Header: X-Aibot-Email-Secret: {channel_secret}

The inbound payload supports the sender address, sender name, subject, body, optional message IDs, locale, and an optional conversation reference for threaded replies. A 403 response usually means the channel secret is wrong.

4) Commerce Verification

Buyers who need purchase or order verification can configure Envato and WooCommerce credentials from the integrations screen. Verification results are stored against leads so support and sales teams have a consistent audit trail.

Envato verification uses the author sale API and can enforce a specific item ID.
WooCommerce verification uses the REST API with store URL, consumer key, and secret.
Verification status is written back to the lead record and retained in verification history.

5) Platform Ops

Platform administrators get a dedicated operations screen for license handling, update checks, and demo import. This is meant for product ownership rather than day-to-day workspace support staff.

License operations

Store or remotely verify a purchase code
Track verification timestamp and metadata
Prepare a CodeCanyon-ready buyer setup flow

Update and demo tools

Check a remote manifest for the latest version
Store download URL metadata for future updater UI
Import a sample demo workspace for previews and screenshots

6) Recommended Integration Strategy

For CodeCanyon buyers, start with email notifications and generic webhooks. Add custom CRM or ERP logic outside the core product by consuming API and webhook payloads instead of patching the chat controllers directly.

Create tokens with the smallest scope required.
Subscribe webhooks only to events the buyer actually consumes.
Keep one inbound email channel per mailbox or department for cleaner routing.
Document webhook signing in buyer-facing setup notes if external integrators are involved.