This is the complete documentation for OpsIQ. Set up the product, run support, configure AI, manage CRM, install the widget, build connectors, call the REST API, receive webhooks, package marketplace apps, and operate self-hosted deployments.
Everything OpsIQ does, in one place: how each screen works, how to connect your own systems, and how to build on top of it. Start anywhere, the sections follow the same order as the admin sidebar.
Use the dedicated administrator and developer guide for Portal architecture, pages, components, preview, Help Center, identity, SCIM, governed releases, extensions, migrations and certification.
Every screen in the admin: analytics, live chat, tickets, CRM, knowledge base, Site Intelligence, promotions and the customer account portal. What each page does, what the numbers mean, and what to do when they look wrong.
The website widget, email mailboxes, inbound and outbound webhooks, and the connector library for platforms like Shopify, WooCommerce, WHMCS, Zendesk, Stripe, Slack and Gmail.
The Connector Builder for no-code connectors, Actions & Triggers if you would rather not use connectors at all, and the REST API with every action, scope and error code.
Roles and permissions, security, cron, diagnostics, backups, and both hosted and self-hosted deployment.
Read the screen sections in sidebar order. Each opens with what the page is for, so you can stop as soon as you have what you need.
Add Settings, Security, Diagnostics, Cron and Production. These are the sections that decide whether everything else keeps working.
Start at Connectors, then the Connector Builder, then the REST API and webhooks. Read those in order and you will have seen every way OpsIQ can talk to another system.
OpsIQ is a complete AI-first business operating platform. It replaces your analytics, live chat, helpdesk, CRM, SEO toolkit, integration middleware, and developer platform with a single unified admin where every tool shares the same customer context. Instead of stitching together 8-12 separate SaaS products, you install OpsIQ once and operate everything from one screen.
Every page load, click, scroll, and navigation event is captured in real time. See who is on your site right now, what pages they are viewing, how long they spend, and where they came from, all without third-party cookies.
Full history of every visitor with device, browser, operating system, country, city, referrer, UTM parameters, landing page, and identity resolution. Sessions group page views into journeys so you can see the entire path a visitor takes.
Timeline-style playback of captured visitor sessions. See exactly what users did: mouse movements, clicks, scrolls, page transitions, and form interactions. Use it to diagnose UX issues, understand drop-off points, and verify conversion flows.
A real-time stream of visitor activity as it happens. See page views, chat starts, form submissions, and intent signals updating every few seconds. Filter by country, device, or referrer to focus on specific traffic segments.
Pages ranked by visits, engagement time, bounce rate, conversions, and support activity. Identify your highest-performing content and pages that need improvement.
Country, city, and region breakdowns with maps. Device and browser distribution, traffic source analysis, search engine referrer tracking, and market penetration insights.
Track visitor intent signals (pricing page visits, repeated returns, documentation browsing patterns, and support interactions) to identify visitors who are likely to buy, churn, or need help.
Run split tests on your website directly from OpsIQ. Create variants, set traffic allocation, define conversion goals, and measure statistical significance. No external testing tool needed.
Capture client-side JavaScript errors from your website automatically. See error messages, stack traces, affected browsers, frequency counts, and which pages trigger them. Debug frontend issues without separate error monitoring.
Every tracked event (page views, custom events, chat interactions, form submissions, purchases) in a searchable, filterable log with full metadata.
Track orders, revenue, refunds, subscription renewals, and attribute conversions to traffic sources, campaigns, and visitor journeys. Revenue dashboards with period comparison and trend analysis.
High-intent visitors identified by behavior patterns. Score leads based on page visits, time on site, return frequency, support interactions, and custom signals. Feed leads directly into the CRM pipeline.
Automated crawling of your entire website to discover pages, detect broken links, find missing meta tags, check image alt text, validate canonical URLs, and map your site structure. Schedule crawls to run daily, weekly, or on demand.
Comprehensive technical analysis: page speed scores, mobile responsiveness, Core Web Vitals, SSL certificate status, redirect chains, duplicate content detection, crawl depth analysis, and structured data validation.
Evaluate every page for content quality, word count, readability score, keyword density, heading structure, internal/external link ratio, and freshness. Identify thin content, duplicate pages, and content gaps.
Semantic search across your entire site content. Ask natural language questions about your content and get AI-synthesized answers with source page references.
Monitor your search engine rankings for target keywords across Google and other engines. Track position changes over time, compare against competitors, and see which pages rank for which terms.
Discover keyword opportunities based on your content, competitor analysis, and search volume data. Get suggestions for new content topics, long-tail variations, and content optimization targets.
Monitor your inbound link profile. See which sites link to you, track new and lost links, analyze anchor text distribution, and identify link-building opportunities.
For businesses with physical locations: visualize your local search visibility across a geographic grid. See how your rankings vary by location, distance from your business, and search intent.
Connect your Google Business Profile to OpsIQ. Sync reviews, posts, Q&A, photos, and business information. Manage your GBP listing from inside OpsIQ. Respond to reviews, publish posts, and monitor insights.
Automated SEO and analytics reports generated on your schedule (daily, weekly, monthly). Reports include ranking changes, traffic trends, technical issues found, and content performance. White-label output available for agencies.
AI answers customer questions on your website 24/7 using your knowledge base, connected platform data (orders, accounts, subscriptions), and custom training prompts. Supports multiple AI providers: Claude (Anthropic), GPT-4o (OpenAI), Gemini (Google), and Grok (xAI).
An AI copilot inside your admin panel that helps you write ticket replies, draft customer communications, analyze support trends, look up customer data across connected platforms, and execute actions through the connector system.
The AI is grounded in your knowledge base articles, FAQ entries, product documentation, and connected platform data. It does not hallucinate. It answers from your actual business information or escalates when uncertain.
When the AI cannot resolve a question, detects frustration, or the customer asks for a human, it automatically hands off to your team with full conversation context. Configurable decline/timeout auto-revert back to AI.
Write separate instruction prompts for customer-facing AI and admin-facing AI. Control tone, boundaries, escalation rules, prohibited topics, and business-specific behavior. Per-workspace configuration supported.
Every AI conversation is logged with full request/response details, token usage, cost tracking, provider used, and model version. Review conversations to identify training gaps and improve AI accuracy.
Automated analysis of AI conversation patterns. See common questions, resolution rates, handoff frequency, customer satisfaction by topic, and areas where the AI needs better training.
Each connected site/workspace can use its own AI provider, model, temperature, token budget, and training prompts. A SaaS company can use Claude for the main product and GPT-4o for a secondary brand.
Two AI modes: Managed AI (included in your plan, no API key needed) or Bring Your Own Key (use your own OpenAI/Anthropic/Google/xAI API key for full control over model selection and costs). Both are first-class, every feature works with either mode.
Set monthly token budgets, per-conversation limits, and low-balance alerts. Track spending per provider, per workspace, and per conversation. Prevent runaway costs with hard ceilings.
Full helpdesk with departments, priorities (low/medium/high/urgent), statuses, SLA tracking, internal notes, customer replies, file attachments, and threaded conversations. No external helpdesk needed.
AI automatically triages incoming tickets by department and priority. Enable auto-reply for safe departments. The AI drafts and sends a response after a configurable delay (default: 2 minutes) so humans can intervene first.
Connect a mailbox (Gmail, IMAP, or provider-specific) to automatically create tickets from inbound emails. Replies to ticket notification emails update the ticket thread.
Embed a customer-facing ticket portal on your website. Customers can submit tickets, view their history, reply to open tickets, and check status, all branded to your design.
Merge duplicate tickets into a single thread. Merged tickets show [Merged] on the subject line. All conversation history is preserved in the surviving ticket.
After a human agent takes over a ticket, use "Return to AI" to let the AI resume auto-reply on that ticket. Useful when the human-required portion is resolved but the customer has follow-up questions the AI can handle.
AI-assisted ticket management from the inbox view. The copilot suggests replies, summarizes conversation history, recommends priority/department assignments, and can execute actions on connected platforms.
Real-time customer chat managed from a unified inbox. See all active conversations, customer identity, conversation history, and AI suggestions. Multiple agents can collaborate on a conversation.
Trigger chat messages based on visitor behavior: time on page, specific URL visited, scroll depth, return visit count, exit intent, or custom events. Example: show a help message after 60 seconds on the pricing page.
A customizable chat widget embedded on your website. Supports AI chat, live agent chat, ticket submission, knowledge base search, and visitor identity. Responsive, accessible, and brandable.
Collect customer satisfaction ratings after chat and ticket interactions. Design surveys with your own questions, rating scales, and follow-up prompts. Results feed into team performance and AI insights.
After a chat ends, visitors with a known email can receive one branded mail with an AI summary of what was handled and a one-click "Was it easy?" Yes/No. Once per thread, signed single-use links, every send logged, and the result lands on the Feedback page as its own signal beside the in-chat stars.
Every feedback item that carries a person shows them: name, email, a click-through to their full customer journey and CRM contact, and one-click Email or AI-draft replies grounded in their actual history.
Separate AI writing assistant for composing email drafts, ticket replies, announcements, and customer communications. Uses its own prompt (not the chat brain) for professional business writing.
A single screen showing your entire CRM state: pipeline value, deal velocity, upcoming tasks, at-risk deals, agent activity, and AI recommendations. The CRM home page is your daily starting point.
Manage customer contacts with full profiles: name, email, phone, company, tags, lifecycle stage, conversation history, ticket history, purchase history, and custom fields. Link contacts to companies for B2B relationship management.
Visual Kanban-style deal board with customizable stages. Drag deals between stages, set values, assign owners, track close dates, and see pipeline value at each stage. Multiple pipelines supported.
The AI analyzes each deal and provides coaching: risk signals (gone quiet, competitor mentioned, budget concerns), next-best-action recommendations, win probability, and suggested follow-up timing.
Revenue forecasting based on pipeline data, historical close rates, and deal velocity. Reports include pipeline by stage, by owner, by source, conversion rates, average deal size, and sales cycle length.
AI-powered prospecting that identifies potential customers from your visitor data, lead signals, and connected platform activity. Suggests outreach targets, drafts initial messages, and scores lead quality.
Automated multi-step follow-up sequences: email, wait, email, check response, escalate. Define sequences for new leads, stalled deals, post-purchase check-ins, and re-engagement campaigns.
Track customer lifecycle stages (lead, prospect, customer, churned) with automated transitions. The retention agent monitors for churn signals and suggests interventions.
AI agent that continuously cleans and enriches your CRM data: deduplicates contacts, fills missing fields, validates emails, standardizes company names, and flags stale records.
Natural language CRM configuration: tell the AI what your sales process looks like and it builds your pipeline stages, custom fields, deal templates, and automation rules.
Automated audit of your CRM data quality: duplicate contacts, deals without next steps, stale pipelines, missing contact information, and data completeness scoring.
Three-level autonomy control for each CRM AI agent: Autopilot (AI acts independently), Copilot (AI suggests, human approves), and Manual (AI observes only). Set the dial per agent, per action type, and per deal value threshold.
The CRM runs four specialized AI agents: Steward (data quality), SDR (prospecting), Retention (churn prevention), and Analyst (reporting and insights). Each agent has its own Trust Dial setting.
Ready-to-use connectors for Shopify, WooCommerce, BigCommerce, Magento 2, PrestaShop, OpenCart, osCommerce, WordPress, WHMCS, Zendesk, Stripe, Amazon SES, Postmark, Resend, SendGrid, Mailgun, Gmail, IMAP, Slack, and Google Business Profile. Each connector brings platform-specific AI actions, knowledge, and data sync.
Build custom connectors for any platform, no code, AI-assisted, or full code. The builder supports REST and GraphQL APIs, OAuth authorization code flow, webhook auto-registration with Stripe and simple signature schemes, pagination (offset, page, cursor, and link-header), list/error transforms, multi-action context, and marketplace packaging.
The ConnectorBuilderAI helps you build connectors: describe what you want and it suggests actions, writes request handlers, and maps API responses. Handles authentication, pagination, and error handling automatically.
Generic in-app OAuth authorization flow that works with any connector. PKCE support, site-scoped state management, automatic token refresh. Connectors define their OAuth parameters and OpsIQ handles the flow.
Connectors don't just add platform actions. They can power core features through capability "buses". A connector declares a capability (calendar, enrichment, esign in CRM; local_listing, rank_data in Site Intelligence; web_analytics in Analytics; payment_provider in Payments; email_sync in Mailbox; video_meeting in Comms) and implements its small method set; OpsIQ discovers it via CapabilityRegistry and wires it into the UI, the Customer 360 timeline, and the AI actions. Several connectors can offer the same capability with no lock-in. See connectors/PLATFORM_CONNECTORS.md.
Connectors live in one of two tiers. Pre-installed connectors (connectors/) are registry-active out of the box, kept lean to just the keyless reference and the most-used provider per capability (e.g. Google Calendar, Gmail, Google Business Profile). Marketplace connectors (marketplace_connectors/) are discoverable but inert until installed, e.g. Microsoft 365 Calendar, Outlook, DocuSign, Stripe, GA4, SerpApi, Zoom. Every bridge surfaces a marketplace list so the UI and the AI can prompt "install from the marketplace" (notify-to-install) when a capability has no ready provider, never a broken button.
Publish your connectors to the OpsIQ marketplace. Package connectors with profile.json, knowledge.json, workflow_recipes.json, and signed archives. Marketplace supports free and paid connectors with multi-source billing.
All connectors are cryptographically signed for integrity verification. Signing is checked at install time. Use the resign_all_connectors tool to re-sign after updates.
Declarative fuzzy-matching system for connector actions. Define lookup rules and OpsIQ matches user queries to platform entities using fuzzyScore and smartRank algorithms. Example: find_country("germ") matches Germany with 88.9% confidence.
The General OpsIQ API publishes 1,312 named actions, while connector packages declare their own vendor actions with typed parameters, authentication requirements, pagination rules, and response transforms through the unified ActionExecutor.
Pre-built workflow recipes that combine multiple connector actions into common business workflows. Example: "When a new order comes in on Shopify, create a ticket, update the CRM, and send a Slack notification."
Connectors declare knowledge topics that sync to the AI knowledge base. Platform-specific help articles, setup guides, and troubleshooting steps are automatically available to the AI without manual knowledge entry.
A named JSON API covers every registered administrator JSON operation, with API-key authentication, workspace isolation, scopes, rate limiting, idempotent writes, OpenAPI, and a generated Postman collection.
Outbound webhooks for all major events: orders, invoices, subscriptions, tickets, chats, leads, user registrations, and cart abandonment. Async delivery via job queue, exponential backoff retry, SSRF protection, and auto-disable after 15 consecutive failures.
Every outbound webhook is signed with HMAC-SHA256. Verify signatures on your receiving end to ensure webhook authenticity. Stable event_id for idempotent processing.
JavaScript SDK for the tracking widget with identity resolution, custom event tracking, programmatic chat control, and page-specific configuration. Install recipes for React, Vue, Next.js, WordPress, Shopify, and static HTML.
Server-side SDKs and plugins for common frameworks. WordPress plugin, WHMCS module, and generic PHP/Node.js integration libraries.
Push custom events into OpsIQ from your backend: purchases, signups, feature usage, errors, or any business event. Events appear in the visitor timeline and feed into analytics and AI context.
Build automated workflows triggered by events: new ticket, chat started, visitor identified, deal stage changed, or custom event. Triggers execute connector actions, send webhooks, update records, or notify your team.
Visual API and webhook builder inside the admin. Configure endpoints, test requests, inspect responses, and debug integrations without leaving OpsIQ.
Three roles: Owner (full access, billing, danger zone), Full Admin (all operations except billing and danger zone), and Agent (only assigned departments, no settings access). All sensitive pages are hard-gated by role.
Owner and Full Admin-only dashboard showing resolution times, workload distribution, handle depth, channel breakdown, trend analysis, SLA compliance, CSAT by agent, reopen rates, team rollups, and busiest hours. Updated in real time.
Real-time who-is-online widget in the admin navigation. Heartbeat-based presence detection (60-second ping, 300-second extend, auto-prune after 120 days). See which admins are currently active and on which pages.
Each connected site (workspace) can have its own AI configuration, connector settings, ticket departments, branding, and operational rules. Global defaults cascade to workspaces that do not override them.
Manage multiple websites from one OpsIQ admin. Each site has its own tracking snippet, visitor data, and configuration. Switch between sites from the admin navigation.
Registry-driven email templates for all automated communications: ticket notifications, chat transcripts, welcome emails, password resets, and system alerts. Edit HTML templates with live preview, variable chips ({{customer_name}}, {{ticket_id}}), and global layout control.
Import contacts, tickets, and knowledge articles from CSV/JSON. Export visitor data, analytics reports, and CRM records. Data portability for migration between systems.
OIDC (OpenID Connect) single sign-on with full runtime: discovery, authorize, callback, JWKS signature verification, userinfo, domain allow-listing, JIT provisioning, and status guards. SAML configuration support.
Built-in DSAR (Data Subject Access Request) handling: export and delete customer data across all systems. Contact-level data erasure covering sessions, tickets, chats, CRM records, and email logs. Consent management and retention policies.
Block specific IPs or ranges from accessing your site or admin. Automatic lockout after configurable failed login attempts. Failed login log with IP, timestamp, and user agent.
HTTP Strict Transport Security, Permissions-Policy headers, and secure cookie configuration. Self-hosted deployments can add CSP headers through server configuration.
SSRF guard blocks webhooks to private/metadata IP ranges. Async delivery prevents slow endpoints from blocking your application. Auto-disable after 15 consecutive failures prevents resource waste on dead endpoints.
Strict data isolation between workspaces. Visitors, tickets, chats, CRM records, and AI conversations are scoped to their workspace. Cross-workspace data leaks are prevented at the query layer.
Support for monthly, quarterly, semi-annual, yearly, biennial, and lifetime billing cycles. Currency normalization for multi-currency gateways. FX conversion on payment receipt for accurate revenue reporting.
Built-in cron system for scheduled tasks: report generation, data cleanup, subscription renewals, AI training updates, connector syncs, and webhook retries. Health diagnostics with warning indicators.
Configure how long visitor sessions, chat transcripts, AI conversation history, and event logs are retained. Automatic cleanup of aged data to manage storage and comply with retention policies.
System health dashboard showing cron status, database connectivity, AI provider status, connector health, webhook delivery rates, and storage usage. Warnings for configuration issues and performance bottlenecks.
Track every visitor from landing to purchase. Let AI answer "Where is my order?" using live Shopify/WooCommerce/BigCommerce data. Manage support tickets with AI auto-reply. Run a deal pipeline for wholesale and B2B leads. Attribute revenue to traffic sources and campaigns. Monitor cart abandonment with recovery workflows.
Monitor trial signups and feature adoption with session replay. Track which documentation pages convert. Automate support with AI grounded in your API docs. Manage subscription revenue and expansion deals in the CRM. Connect your billing platform (Stripe, WHMCS) for real-time MRR tracking. Use the CRM lifecycle agent to detect and prevent churn.
Offer white-label analytics and support portals to clients. Track leads across multiple client sites from one admin. Use the CRM pipeline to manage prospects and project leads. Build custom connectors for client platforms using the Connector Builder. Generate branded SEO reports with Site Intelligence. Resell marketplace connectors as value-add services.
Deep WHMCS integration with 80+ AI actions for order lookup, service management, DNS, and provisioning. Auto-reply to common hosting questions using knowledge base articles. Track server status page engagement. Manage technical support tickets with AI triage. Use the billing cycle ladder for monthly through lifetime hosting plans.
Deflect 40-70% of repetitive questions with AI chat grounded in your knowledge base. Route tickets to the right department with AI triage. Track team performance with resolution times, SLA compliance, and CSAT by agent. Use the writing AI for professional reply drafting. Monitor support trends with AI insights.
Full Site Intelligence suite: crawls, technical SEO audits, content analysis, SERP rank tracking, keyword research, backlink monitoring, and local SEO grid. Google Business Profile management. Scheduled white-label reports for clients. A/B testing built into the tracking widget. Campaign attribution across all channels.
Start with just tracking and chat, free to add. Then add tickets when you get support volume. Turn on the CRM when you start selling. Connect platforms as you adopt them. OpsIQ scales from one person doing everything to a 50-person operations team with RBAC, departments, and per-agent performance tracking.
Enterprise SSO with OIDC for centralized authentication. Multi-workspace isolation for separate brands or divisions. Per-workspace AI configuration with different providers and models. Custom connector development with marketplace distribution. Audit trails, GDPR compliance tools, and data retention policies.
Full website analytics with visitor tracking, session replay, page rankings, geo intelligence, intent funnels, conversion attribution, events, A/B experiments, and JS error tracking, all privacy-friendly, all in one platform.
AI-powered customer chat with knowledge grounding, multi-provider AI support, auto-handoff to humans, proactive chat rules, conversation history, CSAT surveys, and ticket creation from chat.
Native ticket system with departments, priorities, SLA, AI triage, auto-reply with configurable delay, email ingestion, ticket embed, ticket merging, inbox copilot, and Return to AI capability.
AI-first CRM with four specialized AI agents (Steward, SDR, Retention, Analyst), Trust Dial autonomy control, pipeline board, deal coaching, forecasting, sequences, lifecycle management, and natural language CRM configuration.
Site Intelligence with automated crawls, technical SEO audits, content analysis, AI search, SERP rank tracking, keyword research, backlink analysis, local SEO grid, and scheduled white-label reports.
Connector SDK with 25+ pre-built connectors, Connector Builder (no-code/AI-assisted/full-code), OAuth flow, webhook auto-registration, a large catalogue of connector action definitions that become executable only when the relevant connector is installed, enabled, configured and validated, SmartLookup, marketplace, and signed packages.
Full GBP connector: review management, post publishing, Q&A management, photo uploads, business info sync, insights tracking, and AI-powered review responses, all from inside OpsIQ.
Registry-driven email templates with visual editor, live preview, variable chips, global layout control, and per-event customization for all automated communications.
Built-in team performance: resolution times, workload, SLA compliance, CSAT by agent, reopen rates, busiest hours, real-time presence tracking, and per-department breakdowns.
Native DSAR handling, data erasure across all systems, consent management, retention policies, and audit trails, built into the platform, not bolted on.
OpsIQ runs on managed infrastructure. Product operation is the same; infrastructure, updates and backups are handled by the hosting operator. This handbook documents the OpsIQ runtime rather than marketing or commercial account flows.
Install OpsIQ on your own server for full control over data, branding, updates, and integrations. Requires PHP 8.4+, MySQL 5.7+ or MariaDB 10.3+, HTTPS, and the OpsIQ unified cron. Supports WHMCS integration as an addon module. Full data sovereignty.
Follow the 30-minute setup guide to get tracking, chat, and basic AI working on your website.
Learn how to read your visitor data, set up session replay, identify leads, and understand traffic patterns.
Run your first SEO crawl, check your technical health, and set up SERP rank tracking for your target keywords.
Set up departments, configure auto-reply with AI, connect email ingestion, and train your AI to handle common questions.
Organize contacts, build your pipeline, configure the AI agents, set Trust Dial levels, and let AI coach your deals.
Connect your e-commerce/billing platform, build custom connectors, set up webhooks, and integrate via the REST API.
Follow these steps in order to get OpsIQ running. Each step builds on the previous one. By the end, you will have visitor tracking, AI chat, and basic ticket support.
Enter your license key in the OpsIQ admin. Go to Settings, enter the licence key supplied for this installation, and click Activate. You should see a green "Active" badge.
Go to Settings and fill in your business name, industry, timezone, default currency, and support hours. This information is used by the AI when answering customer questions and by analytics for timezone-aware reports.
Go to AI Configuration and select your provider. Options: Claude (Anthropic), GPT-4o (OpenAI), Gemini (Google), or Grok (xAI). Enter your API key if using your own key, or use Managed AI if available on your plan. Click "Test connection" to verify.
Go to Connected Sites, copy the tracking snippet, and paste it before the closing </body> tag on your website. Visit your site in a private browser, then check the Live Feed in OpsIQ. You should see yourself as a visitor within 15 seconds.
If you use Shopify, WooCommerce, WHMCS, or another supported platform, go to Connectors, find your platform, enter credentials, and click Test Connection. This gives the AI access to order data, customer profiles, and support context.
Go to Team, click Invite, enter their email and role (Owner, Full Admin, or Agent). Agents can only access departments you assign them to. Owners and Full Admins see everything.
Copy the snippet from Connected Sites and paste it on your website. This gives you tracking immediately.
Go to AI Configuration, pick a provider, enter your key, and save. AI chat is now active on your website.
You now have visitor tracking and AI chat. You can add tickets, CRM, and connectors later.
Go to Knowledge Base and add 5-10 articles about your most common questions. The AI uses these to answer customers accurately.
Go to Tickets and create at least 2 departments (e.g., "Sales" and "Support"). Assign team members to each.
Go to AI Training and write a Customer AI prompt that describes your business, tone, and escalation rules.
Open your website in a private browser and chat with the AI as a customer. Check that answers are accurate and tone is right.
Set up a mailbox (Gmail, IMAP, or a provider connector) so customer emails automatically create tickets.
Enable ticket auto-reply for safe departments. Set a 2-minute delay so humans can intervene first.
Check Dashboard daily. Look at visitor count, bounce rate, top pages, and sales if tracking is connected.
Open AI CRM and let OpsIQ import contacts from your connected platforms. Review the pipeline board.
Check AI History weekly. Look for wrong answers, missed questions, and opportunities to add knowledge.
Create a rule: if a visitor is on the pricing page for 60+ seconds, show a chat message asking if they need help.
If you use a platform that does not have a built-in connector, use the Connector Builder to create one.
Connect OpsIQ to your internal tools using outbound webhooks for ticket, chat, and sales events.
Yes. The AI provider is optional. OpsIQ works as a pure analytics and ticketing platform without AI. You can enable AI later when you are ready.
Yes. Connectors enrich the AI with platform-specific data, but OpsIQ works without them. Start with tracking and chat, then connect platforms when needed.
You can still use OpsIQ for tickets, CRM, and team collaboration. The tracking widget is optional. Add it when your website is ready.
Visit your website in a private/incognito browser. Then check OpsIQ Live Feed. You should see your visit appear within 15 seconds. If not, check: (1) is the snippet pasted correctly, (2) is the site key correct, (3) are ad blockers or CSP headers blocking the script.
OpsIQ is not one feature. It is an operator admin, a website widget, an AI support layer, a ticket/helpdesk system, a full CRM with four AI agents, a Site Intelligence suite, a connector platform with marketplace, and a developer surface. Here is every component it contains.
Dashboard, live feed, visitor log, sessions, session replay, top pages, geo intelligence, intent funnel, events log, A/B experiments, JS error tracking, sales and conversions, leads, AI CRM (command center, contacts, companies, deals, pipeline board, deal coaching, forecast, prospecting, sequences, lifecycle, data steward, Build my CRM, CRM config, CRM health, CRM API), tickets, chat inbox, proactive rules, CSAT surveys, email drafts, mailboxes, AI configuration, AI training, AI history, AI insights, knowledge base, connectors, Connector Builder, marketplace, connected sites, team management, team performance, settings, diagnostics, and license.
Website tracking widget (analytics beacon + chat + ticket embed + knowledge base search), client AI chat, ticket submission portal, visitor identity token handling, file uploads, CSAT survey widget, and customer-facing help center.
Command center, contacts, companies, deals, pipeline board with drag-and-drop, AI deal coaching (risk signals, next-best-action, win probability), revenue forecasting, prospecting agent (SDR), automated follow-up sequences, lifecycle and retention management, data steward agent (dedup, enrich, validate), Build my CRM (natural language setup), CRM configuration, CRM health check, Trust Dial (Autopilot/Copilot/Manual per agent), four specialized agents (Steward, SDR, Retention, Analyst), and CRM API with webhooks.
Automated site crawls, technical SEO audit (speed, mobile, Core Web Vitals, SSL, redirects, structured data), content audit (word count, readability, keyword density, heading structure), AI-powered semantic search, SERP rank tracking across engines, keyword research with opportunity scoring, backlink analysis and monitoring, local SEO grid visualization, Google Business Profile sync (reviews, posts, Q&A, photos, insights), scheduled reports (daily/weekly/monthly), and white-label PDF output for agencies.
Customer AI chat (multi-provider: Claude, GPT-4o, Gemini, Grok), admin AI assistant, AI knowledge grounding, auto-handoff with configurable revert, per-workspace AI configuration, managed AI and BYOK modes, token budgets and cost controls, AI history audit trail, AI insights analysis, ticket AI triage, ticket auto-reply with delay, writing AI (separate prompt), and admin inbox copilot.
25+ pre-built connectors (Shopify, WooCommerce, BigCommerce, Magento 2, PrestaShop, OpenCart, osCommerce, WordPress, WHMCS, Zendesk, Stripe, Amazon SES, Postmark, Resend, SendGrid, Mailgun, Gmail, IMAP, Slack, Google Business Profile), Connector Builder (no-code/AI-assisted/full-code), generic OAuth flow with PKCE, connector marketplace with paid distribution, connector signing and verification, SmartLookup fuzzy matching, a large catalogue of HTTP action definitions whose availability depends on connector installation, enablement, configuration and validation, knowledge sync, and workflow recipes.
REST API (visitors, events, tickets, contacts, settings, connectors), OpenAPI spec, API key management, outbound webhooks (async, signed, retried, SSRF-guarded, auto-disable), Events API for custom event ingestion, widget SDK with identity resolution, triggers cookbook, action contracts, connector SDK, marketplace packaging, server-side SDKs (PHP, Node.js), WordPress plugin, and WHMCS module.
Business identity, AI configuration per workspace, tracking settings, security (HSTS, Permissions-Policy, IP blocking, brute-force protection), RBAC (Owner/Full Admin/Agent), team management and invitations, team performance dashboard, admin presence tracking, email template system (registry-driven, visual editor, variable chips), survey designer, domain knowledge, ticket embed configuration, branding, data retention policies, billing cycle management (monthly through lifetime), currency normalization, import/export, diagnostics, cron automation, and danger zone.
Enterprise SSO (OIDC with JWKS verification, JIT provisioning), SAML configuration, GDPR/DSAR handling (export and delete across all systems), data erasure per contact, consent management, workspace isolation (strict query-layer scoping), audit trails, failed login tracking, IP blocking, outbound webhook SSRF guard, and data retention policies.
Managed AI proxied through OpsIQ provider URL, Site Intelligence provider calls, license validation, health reports, PDF rendering, and data exports, all routed through the configured provider endpoint, not direct vendor API calls from your server.
Daily command center: traffic overview, live visitor count, sales summary, support queue depth, AI activity alerts, and quick-action shortcuts.
Real-time visitor stream: page views, chat starts, form submissions, and intent signals updating every few seconds with country, device, and referrer filters.
Complete visit records: device, browser, OS, country, city, referrer, UTM params, landing page, identity, and full page-view history.
Journey-grouped view: page flow, time on page, scroll depth, conversion path, and exit page for each visitor session.
Timeline playback of captured events: mouse movement, clicks, scrolls, page transitions, and form interactions for UX diagnosis.
Page performance ranking: visits, engagement time, bounce rate, conversions, support interactions, and trend direction.
Geographic reports: country/city breakdown with maps, device distribution, browser share, traffic sources, and market penetration.
Behavioral intent tracking: pricing visits, return frequency, doc browsing, support interactions, and custom signals with conversion probability.
Searchable event history: page views, custom events, chats, purchases, form submissions with full metadata and filtering.
Split testing: create variants, allocate traffic, define goals, measure significance, and declare winners, all from inside OpsIQ.
Frontend error capture: messages, stack traces, affected browsers, frequency, affected pages, and trend tracking.
Revenue dashboard: orders, renewals, refunds, attribution by source, campaign performance, period comparison, and trend analysis.
Lead management: scoring, source attribution, CRM status, contact details, behavioral signals, and pipeline routing.
Full CRM: command center, contacts, companies, deals, pipeline board, coaching, forecast, prospecting, sequences, lifecycle, data steward, and health.
Support inbox: departments, priorities, SLA tracking, AI triage, auto-reply, internal notes, file attachments, merging, and status management.
Live conversations: AI and human chat, handoff, collaboration, conversation history, customer identity, and CSAT collection.
Email management: inbound mail to tickets, AI-assisted reply composition, template selection, and mailbox configuration.
Provider setup: select Claude/GPT-4o/Gemini/Grok, enter API key or enable managed AI, set model, temperature, and token budgets per workspace.
Prompt authoring: customer-facing and admin-facing prompts, escalation rules, tone guidelines, prohibited topics, and boundary configuration.
Conversation audit: full request/response logs, token usage, cost per conversation, provider, model version, and resolution outcome.
Pattern analysis: common questions, resolution rates, handoff frequency, satisfaction by topic, and training gap identification.
AI training content: articles, FAQ entries, product docs, connector knowledge, and custom entries. Semantic and keyword search for AI grounding.
Integration hub: installed connectors, health status, action inventory, credential management, marketplace browser, and Connector Builder.
Site management: tracking snippet, site key, widget configuration, domain settings, and per-site workspace isolation.
User management: invite members, assign roles (Owner/Full Admin/Agent), set department access, and manage permissions.
Ops metrics: resolution times, workload, SLA compliance, CSAT by agent, reopen rates, busiest hours, and trend analysis.
Configuration: business identity, AI setup, tracking, security, branding, retention, email templates, billing, import/export, diagnostics, and danger zone.
Plan management: license status, plan features, usage metrics, renewal date, and upgrade/downgrade options.
The onboarding journey turns a new installation into a working OpsIQ workspace and can be left and resumed without losing progress.
The journey stores completion per workspace. Returning to Onboarding should show completed steps rather than forcing a restart.
The Analytics hub brings support, chat, AI, visitor and agent reporting into one date-filtered workspace with exportable results.
Use Analytics Hub for cross-team review; use the dedicated Visitors, Tickets, CSAT, AI History and Team Performance pages when you need record-level investigation.
The Dashboard is your daily command center. It shows traffic, sales, support load, AI activity, and conversion indicators in one view. Open it every morning to understand what happened overnight and what needs attention today.
The number of people on your website right now. This updates every 15 seconds (configurable). A visitor is "active" if they loaded a page within the active threshold (default: 90 seconds).
How many different people visited your website in the selected date range. OpsIQ identifies visitors by a combination of browser fingerprint, cookies, and (if available) authenticated identity.
New visitors are seeing your site for the first time. Returning visitors have been seen before. A high returning ratio means your content brings people back. A very low returning ratio might mean you are not retaining interest.
The percentage of visitors who left after viewing only one page. A bounce rate above 70% on landing pages usually means the page is not meeting visitor expectations, wrong content, slow load, or poor mobile experience.
How long visitors spend on each page on average. Very short times (under 10 seconds) on content pages suggest the content is not engaging. Very long times on checkout pages might indicate confusion.
IP addresses that OpsIQ identified as potentially malicious based on threat scoring, brute force attempts, or manual blocks. Click to see the blocked IPs list.
Revenue from connected sales sources (Shopify, WooCommerce, Stripe, etc.). If sales show zero, check that your platform connector is connected and syncing.
A line graph showing visitor count over the selected date range. Look for patterns: traffic spikes (campaigns, press mentions), dips (weekends, holidays), and sustained trends.
Where your visitors come from: direct, Google, social media, email campaigns, referral sites. Use this to understand which marketing channels are working.
Chrome, Safari, Firefox, Edge, and others. If a browser has unusually high bounce rate, you might have a CSS or JavaScript compatibility issue.
A grid showing visitor activity by hour of day and day of week. Use this to decide when to schedule support shifts, when to send announcements, and when to run promotions.
The last few visitors with country, page, device, and source. Useful for quick spot-checks during campaigns.
Click the date picker at the top right of the Dashboard. Presets: Today, Yesterday, Last 7 days, Last 30 days, This month, Last month, Custom range. All dashboard cards and charts update when you change the range. The date range is in your configured timezone (set in Settings).
Your bounce rate jumped from 45% to 78% this week. What happened?
Check: (1) Did a specific landing page change? Go to Top Pages and sort by bounce rate. (2) Did a campaign send traffic to the wrong page? Check Top Sources for new referrers. (3) Did the site break on mobile? Check browser breakdown for mobile bounce rate. (4) Is it bot traffic? Check the Threats counter and visitor details for suspicious patterns.
The dashboard shows 0 live visitors even though your website is getting traffic.
Check: (1) Is the tracking widget installed? View your website source code and search for the OpsIQ script. (2) Is the site key correct? Compare the data-site-key in the script with the key in Connected Sites. (3) Is a CDN or cache serving a stale page without the script? Clear your CDN cache. (4) Is an ad blocker or CSP header blocking the script? Check the browser console for blocked requests.
Your heatmap shows heavy activity between 10am-2pm on weekdays but nothing on weekends.
This is a B2B traffic pattern. Your visitors are working professionals browsing during business hours. Implications: (1) Schedule support staff for weekday business hours. (2) Send email campaigns Tuesday-Thursday morning. (3) Weekend maintenance windows are safe. (4) Consider offering live chat only during peak hours.
You see a sudden spike of 500 visitors in one hour from an unknown referrer.
Go to Visitors and filter by the time window. Check: (1) Are they real visitors or bots? Look at session duration, pages viewed, and browser diversity. (2) If real, what page are they landing on? (3) Check the referrer URL. Someone might have linked to you from Reddit, Hacker News, or a popular blog. (4) If it is bot traffic, check Threats and consider blocking the IP range.
OpsIQ counts visitors differently. It uses browser fingerprinting and cookies, while GA uses a different cookie model. Bot filtering, ad blocker rates, and script loading order can also cause differences. A 10-20% variance is normal.
The dashboard is designed for the OpsIQ admin. For external reporting, use the REST API to pull analytics data and display it in your own dashboard or BI tool.
It counts IP addresses that OpsIQ has flagged or blocked based on threat scoring, repeated failed logins, or manual blocks. Click the counter to see details and manage blocks.
The Visitor Log shows every visit to your tracked websites. Each row is one page load from one visitor. Use it to investigate individual visitor behavior, find campaign traffic, and diagnose tracking issues.
The visitor's IP address. Anonymized if IP anonymization is enabled in Settings. Click to see all visits from this IP.
Detected from the IP address using GeoIP data. Requires MaxMind GeoLite2 database or Cloudflare geo headers. Shows "Unknown" if GeoIP is not configured.
The page the visitor loaded. Click to see the full URL. Long URLs are truncated in the table view.
Where the visitor came from before landing on your site. "Direct" means no referrer (bookmarks, typed URLs, some app links).
The visitor's device type (desktop, mobile, tablet) and browser (Chrome, Safari, Firefox, etc.). Parsed from the User-Agent header.
When the page was loaded, in your configured timezone.
If the visitor is identified (via identity token or login), their name or email appears. Otherwise shows as anonymous.
Filter visits to a specific time period. Default: last 7 days.
Search by IP address, page URL, referrer, country, or customer email.
Filter by traffic source: Direct, Organic, Social, Referral, Paid, Email.
Filter by Desktop, Mobile, or Tablet.
Show only first-time visitors who have never been seen before.
You launched a Google Ads campaign with UTM parameter utm_source=google&utm_medium=cpc&utm_campaign=summer-sale. How do you find those visitors?
In the Visitor Log, use the Search field and type "summer-sale". The search checks referrer URLs and page URLs, so UTM parameters will match. You can also filter by Source = Paid to narrow down further.
A customer emailed saying "your checkout page was broken yesterday around 3pm." How do you find their session?
Search by their email address in the Visitor Log. If they were logged in, their identity will appear. Set the date range to yesterday. Look for visits to checkout pages around 3pm. Click their session to see the full page flow and any JavaScript errors.
You notice an IP address has 500+ visits in one hour, all to the same page.
This is likely a bot, scraper, or broken script. Go to the Visitor Log and search by that IP. Check: (1) Are all visits to the same page? (2) Is the user agent a known bot? (3) Is the session duration always 0 seconds? If confirmed as a bot, go to Security and block the IP.
Raw page loads. One row per page view. Best for: investigating specific pages, finding traffic from specific sources, diagnosing tracking issues.
Groups page views into journeys. One row per visit session. Best for: understanding user flow, measuring session duration, identifying conversion paths.
Real-time activity. Shows visitors currently on your site. Best for: monitoring campaigns in progress, spotting high-intent visitors, watching support opportunities.
OpsIQ tracks all visits by default. To exclude your own traffic, add your IP address to the excluded IPs list in Settings > Tracking.
GeoIP lookup requires either Cloudflare geo headers (automatic if using Cloudflare) or a MaxMind GeoLite2 database file. Check Settings > GeoIP Path to ensure the database file exists and is readable.
Visitor data is kept for the retention period configured in Settings (default: 90 days). After that, old records are automatically cleaned up by the cron retention job.
Sessions group multiple page views from the same person into a single journey. While the Visitor Log shows individual page loads, Sessions show you how people move through your website from landing to exit.
A session starts when a visitor loads their first page. It continues as they navigate to more pages. A session ends when the visitor is inactive for the session timeout period (default: 30 minutes) or closes their browser. The same person returning after the timeout creates a new session.
The landing page, where the visitor entered your site. This tells you which content is attracting people.
The exit page, where the visitor left. If the exit page is often the pricing page, visitors might be comparing you with competitors.
How many pages the visitor viewed in this session. More pages usually means more engagement, but it can also mean the visitor is lost.
Total time from first page load to last activity. Sessions with 0 seconds are bounces (single page view, no further interaction).
The traffic source for this session (Direct, Google, social, referral, etc.).
Detected country from the visitor's IP address.
Whether the visitor left after viewing only one page. Bounced sessions have a red indicator.
Whether the visitor completed a tracked conversion event (purchase, signup, form submission) during this session.
Search by IP, email, page URL, or referrer within sessions.
Filter by New visitors (first session ever) or Returning visitors.
Filter by traffic source.
Filter by country to see sessions from a specific region.
Filter to show only bounced sessions or sessions flagged as threats.
A customer just made a large purchase. You want to understand their journey before buying.
Search for their email in Sessions. Look at all their sessions: (1) How many times did they visit before buying? (2) Which pages did they view? (3) Did they use chat or open a ticket? (4) What was the total time from first visit to purchase? This tells you the typical buying journey for high-value customers.
A customer usually logs in from Nigeria but you see a session from Russia.
Search for the customer email in Sessions. Compare the country of recent sessions. If a session suddenly appears from an unusual country, it could be legitimate travel or a compromised account. Check: (1) Was there a failed login attempt before the successful one? (2) Did the IP change within the same session? Flag it for review if suspicious.
A visitor is a person (or browser). A session is one visit from that person. The same visitor can have many sessions over time. Sessions expire after the timeout period.
OpsIQ uses a combination of cookies, browser fingerprinting, and authenticated identity tokens. If a visitor clears their cookies and is not logged in, they will appear as a new visitor.
The Live Feed shows visitors currently on your website in real time. It updates automatically every 15 seconds (configurable). Use it during campaigns, product launches, and busy support periods to see what is happening right now.
The Live Feed polls your server at the configured refresh interval. Each row shows a visitor currently on your site: their current page, country, device, source, session duration, and page count. Green highlights indicate new activity since the last refresh. Click any visitor row to see their full session details.
How often the live feed updates. Default: 15 seconds. Lower values (5-10s) give faster updates but use more server resources. Higher values (30-60s) are easier on the server but less real-time.
How long a visitor is considered "active" after their last page load. Default: 90 seconds. If a visitor loads a page and then reads it for 2 minutes without clicking, they disappear from the live feed after the threshold.
Click Pause to stop auto-refresh. Useful when you want to read details without the list updating. Click Resume to restart.
You are running a product launch. A visitor just viewed your homepage, then features, then pricing, and is now on the checkout page.
This is high-intent behavior. In the Live Feed: (1) Click the visitor to see their session. (2) If they start a chat, the AI will have their full journey context. (3) If they leave without buying, they become a lead in the Leads page. (4) Consider creating a proactive rule to show a chat message when visitors reach checkout.
You see 20 visitors from the same IP address, all on different pages.
This could be: (1) An office with shared internet. Check if the visits look like real humans (different pages, reasonable session durations). (2) A bot or scraper. Check if sessions are very short (0-1 seconds) or hitting pages systematically. (3) A load test. If you are running automated tests, exclude the IP from tracking.
Check: (1) Is the widget script installed on your site? (2) Is the site key correct? (3) Has the active threshold passed? (4) Are visitors using aggressive ad blockers that block the tracking script?
The live feed shows all active visitors. For filtered views, use the Visitor Log or Sessions pages with their filter options. The live feed is intentionally simple for real-time monitoring.
Top Pages shows which pages on your website get the most traffic. It ranks pages by visits, engagement, conversions, and support activity. Use it to identify your best content, find underperforming pages, and discover pages that generate support questions.
The full URL path. Similar pages (e.g., product variants) are grouped if grouping is enabled.
Total number of times this page was loaded in the selected date range.
How many different people viewed this page (a person viewing the same page twice counts as 1 unique).
Percentage of visitors who left your site after viewing only this page. High bounce on landing pages = problem. High bounce on "thank you" pages = normal.
How long visitors spend on this page on average. Very short = not reading. Very long on a form page = confusion.
How many chat conversations were started from this page. High chat starts on a product page means the product description might be unclear.
How many support tickets were created by visitors who were on this page. High ticket count = potential UX or content problem.
Your support team keeps getting questions about shipping. Which page is failing?
Sort Top Pages by "Support tickets" or "Chat starts" descending. Look for product or shipping pages with high counts. The page with the most support questions probably has unclear information. Fix the page content and monitor whether support questions decrease.
You want to know where people leave your site most often.
Sort by bounce rate descending. Ignore pages that are naturally exit points (thank you pages, confirmation pages). Focus on pages that should keep visitors engaged: product pages, pricing, features. These need better calls-to-action or clearer content.
Check: (1) Is the tracking widget installed on that specific page? Single-page apps might not fire page views on route changes. (2) Is the page excluded in tracking settings? (3) Is a CDN serving a cached version without the tracking script?
Geo Intelligence shows where your visitors come from by country, city, device, and source. Use it to understand your geographic markets, decide on language support, plan regional marketing, and detect suspicious traffic patterns.
The top countries ranked by visitor count. Click a country to drill down to city-level data.
Visual breakdown of traffic by country. Hover for percentages.
Every country with visitors in the selected period, showing visitor count, session count, bounce rate, and conversion rate.
Click a country to see which cities within that country have the most visitors.
OpsIQ detects visitor location in two ways: (1) Cloudflare geo headers. If your site is behind Cloudflare, country detection is automatic and accurate. (2) MaxMind GeoLite2 database. Download the free database and configure the path in Settings. City-level detection requires the GeoLite2-City database, not just the Country database.
Visitors using VPNs will appear to come from the VPN server's location, not their real location. This is by design. OpsIQ cannot and should not try to bypass VPNs. If you see unusual country patterns, consider that 10-20% of visitors may be using VPNs.
You run a US-only business but 30% of traffic is from India.
Check: (1) Are these real visitors? Look at session duration and pages viewed. Very short sessions with high bounce = likely bots. (2) Are they finding you through Google? Check the referrer. (3) Could they be potential customers in a new market? If the traffic is genuine and engaged, consider adding India-specific pricing or content.
You want to know if you should translate your site into Spanish.
Look at the Geo Intelligence page. If Spanish-speaking countries (Spain, Mexico, Colombia, Argentina, etc.) together represent more than 10% of your traffic with low bounce rates, translation is worth considering. Also check: do visitors from these countries convert at similar rates to your primary market?
You need to decide support team hours for different time zones.
Use the hourly heatmap (on Dashboard) combined with Geo Intelligence. If 40% of your traffic is from Europe and 35% from the US, you need coverage for both time zones. The heatmap shows exactly when each region is most active.
Germany shows 500 visitors this month but zero sales.
Investigate: (1) Are they bouncing on the pricing page? Maybe your pricing is not competitive for that market. (2) Do you ship to Germany? Check if your shipping page mentions Germany. (3) Is your checkout available in EUR? Currency mismatch causes abandoned checkouts. (4) Are these visitors from a single source that might be low-intent traffic?
GeoIP is not configured. Either set up Cloudflare (which adds geo headers automatically) or download the MaxMind GeoLite2 database and set the file path in Settings > GeoIP Path.
OpsIQ does not block by country. Use your web server or Cloudflare firewall rules for country-based blocking. OpsIQ focuses on visibility, not access control at the network level.
The Intent Funnel classifies visitor sessions by what they seem to be trying to do: browse, research, compare, buy, get support, or leave. Use it to understand the balance of intent on your site and identify where visitors drop off.
Visitors casually looking around. Short sessions, few pages, no specific goal detected.
Visitors reading product/feature pages, docs, or blog content. Longer time on page, multiple content pages.
Visitors viewing pricing, plan comparison, or feature tables. Often returning visitors.
Visitors on checkout, cart, or signup pages. High intent. These are your conversion opportunities.
Visitors on help pages, contact pages, or starting chat. They need assistance.
Visitors who left after one page. Low engagement.
1,000 visitors viewed Pricing. 270 opened chat. 92 started checkout. 64 paid. 18 opened support tickets.
Pricing page is strong enough to create intent. Chat is important in the buying path: 27% of pricing visitors engage with chat before buying. Support tickets after checkout may indicate activation or payment confusion. Action: (1) Ensure AI chat answers pricing questions well. (2) Investigate the 18 post-checkout support tickets for common issues.
Use the date range filter to compare intent patterns across periods. For example, compare Black Friday week to a normal week. You should see a spike in "Buying" intent and possibly "Support-seeking" if your promotions created confusion.
OpsIQ looks at page URLs, session behavior, and time patterns. Pricing pages signal comparison intent. Checkout pages signal buying intent. Help/contact pages signal support intent. The classification is heuristic-based, not AI-driven.
Not currently. The categories are built-in based on common web behavior patterns. Custom intent classification is on the roadmap.
Build custom journeys from page or event steps, measure cohort retention and discover the paths visitors most often take through a site.
Create a named funnel with 2 to 8 page or event steps. Set the conversion window in hours; a visitor counts only when the ordered steps occur inside that window. Use the drop between steps to choose where to inspect replay, errors, page speed or messaging.
Retention groups visitors into weekly cohorts and shows how many return. Choose a 6, 8 or 12 week horizon. Keep the cohort definition stable when comparing releases or campaigns.
Paths lists the most common page sequences. Choose a path length from 2 to 5 pages to keep the result readable. Use it to find unexpected detours, common exits and content that repeatedly precedes conversion.
Custom funnels are analytical definitions, not automations. To react to a completed step, create a conversion goal, segment, trigger or workflow.
Session Replay lets you watch a timeline of what a visitor did on your site: which elements they clicked, how they scrolled, where they hovered, and what they typed (with sensitive fields masked). Use it to diagnose UX problems, verify bug reports, and understand customer confusion.
From the Sessions page, look for sessions with reported issues, high page counts with no conversion, or sessions from customers who filed support tickets. Click the replay icon to open the timeline view.
A horizontal bar showing events over time. Click anywhere on the timeline to jump to that moment.
Each page load appears as a segment on the timeline. You can see the exact path the visitor took.
Click events are shown as dots on the timeline and as highlights on the page reconstruction.
Scroll depth is tracked so you can see how far down the visitor read.
Field focus and typing events are recorded. Text input in password and sensitive fields is masked by default.
Session replay masks sensitive form fields by default. Password fields, credit card inputs, and fields marked with data-opsiq-mask are never recorded. You can configure additional masking rules in Settings > Tracking. If your compliance policy requires it, you can disable replay entirely.
A customer says "I tried to buy but the button did nothing."
Find their session in the Sessions page (search by email). Open the replay. Watch the checkout page segment. Look for: (1) Did they click the right button? (2) Did a JavaScript error occur? (Check the JS Errors page for that time.) (3) Did the page reload or show an error message? (4) Was a required field empty? The replay shows exactly what happened.
Replay data grows with traffic volume. Use retention settings to automatically clean up old replay data. For high-traffic sites, consider a shorter replay retention period (e.g., 30 days) to manage storage.
If "Respect Do Not Track" is enabled in Settings, visitors with DNT headers are not recorded. You can also exclude specific pages from replay in the tracking settings.
The Events Log shows every event that OpsIQ has recorded: page views, clicks, chat starts, ticket creations, sales, and custom events. Use it to debug integrations, verify webhook delivery, and understand the sequence of actions.
webhooks.events.list; subscribing to a name from this table will not deliver anything.Each row shows the name you send and the canonical name OpsIQ stores it as. Both are recorded: the raw name you sent, and the canonical one it maps to, so a report written against the canonical taxonomy keeps working whichever alias a tracker used.
A tracked page loads. Includes URL, title, referrer and timestamp. page_view and view are accepted as the same thing.
A visitor opens the chat widget.
A visitor sends a chat message. The reply side is stored as support.chat_message_received.
A support ticket is created. ticket_create is accepted as the same thing; replies and closures are stored as support.ticket_replied and support.ticket_closed.
A tracked form is submitted. submit is accepted as the same thing.
A purchase completes. purchase_success, and the sale aliases order.completed, sale.completed, payment.completed and invoice.paid, are all accepted from a connected platform.
Checkout begins. Related: cart_view, checkout_view, checkout_intent, checkout_abandon, add_to_cart.
A visitor signs in. A failure is login_failed, stored as identity.login_failed; a lockout is login_lockout_created.
A visitor completes a signup. A lead is lead, stored as conversion.lead.
A JavaScript error is captured on a tracked page.
You can send custom events from your website or server to OpsIQ. Custom events are useful for tracking actions specific to your business: button clicks, feature usage, video plays, downloads, etc.
// Send a custom event from the browser
window.OpsIQ = window.OpsIQ || [];
window.OpsIQ.push(["track", "plan_selected", {
plan: "pro",
billing: "annual",
value: 99
}]);// Record a server-side activity for a contact (PHP)
$ch = curl_init("https://your-opsiq-domain.com/api/v1.php");
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
"Authorization: Bearer opq_your_key",
"Content-Type: application/json",
],
CURLOPT_POSTFIELDS => json_encode([
"action" => "crm.activities.record",
"site_key" => "site_abc123",
"email" => "[email protected]",
"event" => "subscription.upgraded",
"value" => 50,
"currency" => "USD",
]),
]);
$response = curl_exec($ch);
curl_close($ch);Filter by specific event names: pageview, chat.started, ticket.created, etc.
Show events from a specific time period.
Search event data by keyword (URL, email, event property values).
Events follow the retention policy set in Settings. Default: 90 days. High-value events (purchases, security events) can be configured with longer retention.
Yes. When creating an experiment, you choose a conversion event. Any built-in or custom event can be used as the conversion goal.
Experiments let you test two versions of a page or feature and measure which one performs better. OpsIQ tracks impressions, conversions, and statistical significance.
Give it a name, define your primary metric (conversion event), and set the variants (control and test).
OpsIQ randomly assigns visitors to variants and tracks their behavior. Do not change the experiment while it is running.
After enough data is collected, check confidence level. 95% confidence means you can be 95% sure the difference is real, not random chance.
Created but not yet started. You can still edit variants and metrics.
Actively assigning visitors to variants. Do not edit while running.
Reached statistical significance or was manually stopped. Results are final.
Results have been reviewed and the experiment is no longer needed in the active list.
Decide what you are measuring before starting. Choosing a metric after seeing results introduces bias.
Add your team's IP addresses to the exclusion list so staff visits do not skew results.
Do not stop an experiment after 100 visitors. You need hundreds or thousands of visitors per variant for reliable results.
If you change the headline AND the button color, you will not know which change caused the improvement.
After the experiment ends, note which variant won and why you chose to implement it.
It depends on the baseline conversion rate and the effect size you want to detect. As a rule of thumb: at least 500 visitors per variant for a 20% effect size. For smaller effects, you need thousands.
Yes, but be careful. If two experiments affect the same page, their results may interact. It is safer to run experiments on different pages or features simultaneously.
JavaScript Errors collects client-side errors from your website visitors. A broken button, a failed API call, or a missing resource shows up here. Use it to find and fix bugs that affect real customers.
The JavaScript error text (e.g., "TypeError: Cannot read properties of undefined").
Which page the error occurred on.
Which browser and device type saw the error. Some errors are browser-specific.
The code location where the error occurred. Click to expand the full stack trace.
When this error first appeared.
When this error most recently occurred.
How many times this error has been recorded.
How many different visitor sessions experienced this error.
Not all JavaScript errors need immediate attention. Prioritize by: (1) errors on critical pages (checkout, signup, login), (2) errors with high session counts, (3) errors that appeared recently (possible regression from a code change), (4) errors on your own code (not third-party scripts).
The JS Errors page shows "TypeError: Cannot read properties of undefined (reading submit)" on /checkout, affecting 45 sessions this week.
This means 45 real customers could not complete checkout. Steps: (1) Open the page in the same browser/device combination. (2) Open browser console and reproduce the error. (3) Check the stack trace to find the exact line of code. (4) Fix the bug, deploy, and monitor the error count going to zero.
Yes, OpsIQ captures all JavaScript errors on the page, including errors from analytics scripts, chat widgets, and ad scripts. Filter by URL in the stack trace to focus on your own code.
You cannot suppress specific errors in OpsIQ, but you can filter the list by page URL or error message. Fix or ignore errors from browser extensions (they often show as errors from unknown sources).
Sales tracking connects your store or billing platform to OpsIQ so you can see revenue alongside visitor behavior. Every purchase is attributed to a visitor journey so you know which pages, campaigns, and channels drive revenue.
Revenue from orders completed today. Refreshes with each new order event from your connected platform.
Revenue aggregated over the period. Refunds are subtracted from these totals.
Line graph showing daily revenue over the selected date range. Look for spikes (promotions, campaigns) and dips (issues, seasonal).
Which traffic sources lead to the most purchases. "Direct" buyers often bookmarked your site. "Google" buyers found you through search.
The latest orders with customer email, amount, currency, and items purchased.
Go to Connectors > Shopify. Create a custom app in your Shopify admin (Settings > Apps and sales channels > Develop apps). Grant scopes: read_orders, read_customers, read_products. Copy the Admin API access token. In OpsIQ, enter your store domain (e.g., your-store.myshopify.com) and the access token. Click Test Connection. If successful, enable webhook sync for real-time order notifications.
Go to Connectors > WooCommerce. In your WordPress admin, go to WooCommerce > Settings > Advanced > REST API. Create a key with Read/Write permission. Copy the consumer key and consumer secret. In OpsIQ, enter your site URL, consumer key, and consumer secret. Click Test Connection.
Go to Connectors > BigCommerce. In your BigCommerce admin, go to Advanced Settings > API Accounts. Create a V2/V3 API Account with read scope for Orders, Customers, and Products. Copy the access token, client ID, and API path. Enter them in OpsIQ and test.
Go to Connectors > Magento. In your Magento admin, go to System > Integrations. Create a new integration with API resource access to Sales, Customers, and Catalog. Activate the integration and copy the access token. Enter it in OpsIQ with your Magento base URL.
Go to Connectors > PrestaShop. In your PrestaShop admin, go to Advanced Parameters > Webservice. Enable the webservice and create a new key. Grant access to orders, customers, and products. Copy the key and enter it in OpsIQ with your store URL.
Go to Connectors > OpenCart. Generate API credentials from your OpenCart admin panel. Enter the API URL, username, and key in OpsIQ. The connector uses OpenCart's REST API for order and customer data.
Go to Connectors > osCommerce. Configure database access or API credentials as documented in the connector settings. osCommerce integration typically requires direct database access or a custom API module.
Go to Connectors > Stripe. Copy your Stripe restricted API key from the Stripe Dashboard (Developers > API keys). The key needs read access to Customers, Charges, Invoices, and Subscriptions. Enter it in OpsIQ. Configure webhook endpoint for real-time events.
Use the REST API or webhooks to send sales events from any platform. Send order.completed events with customer email, amount, currency, and items. See the Events API section for the payload format.
Shows which channels bring paying customers. If Google brings 1000 visitors and 50 sales, that is a 5% conversion rate. If email brings 200 visitors and 30 sales, that is 15%. Email is more effective per visitor.
Refunded orders are tracked separately. They reduce your net revenue totals. If refund rates are high from a specific source, the traffic might be low quality.
OpsIQ stores the original transaction currency and amount. Multi-currency businesses see revenue in each currency. Normalized reporting uses the configured exchange rate.
Your pricing page gets 100 visitors per day but zero conversions.
Investigate: (1) Use Session Replay on pricing page visitors. Watch how they interact with the pricing table. (2) Check Top Pages for the pricing page bounce rate and time-on-page. (3) Check Chat conversations from pricing page visitors. What questions do they ask? (4) Compare your pricing page to competitors. (5) Try an A/B experiment with different pricing layouts.
You sent an email campaign with UTM tags. How do you measure its revenue impact?
Go to Sales and filter by source. Search for the campaign UTM parameter. You will see: (1) How many visitors came from the email. (2) How many converted to sales. (3) Total revenue attributed to the campaign. (4) Compare to the same period before the campaign.
Check: (1) Is the platform connector connected and healthy? Go to Connectors and check the status. (2) Is webhook sync enabled? If using polling, is the cron job running? (3) Does the connector have the right API scopes? For Shopify, you need read_orders.
When an order comes in via the connector, OpsIQ matches the customer email to a known visitor. If the visitor was tracked before the purchase, the sale is attributed to their visitor journey, including the traffic source, landing page, and session history.
You can send sales events via the REST API or webhooks from any system. The event format is documented in the Events API section.
Leads are visitors or customers who show buying or support intent. OpsIQ automatically detects leads based on behavior: pricing page visits, return visits, chat interactions, checkout starts, and high engagement. Use the Leads page to prioritize follow-up and feed your CRM pipeline.
Visitors who view your pricing or plans page are actively considering a purchase.
Visitors who come back multiple times are engaged but not yet converted.
Visitors who start a chat are actively seeking help, either pre-purchase or post-purchase.
Visitors who reach the checkout page but do not complete the purchase.
Visitors who submit a contact form, demo request, or signup form.
Visitors who view many pages with long session duration are deeply researching.
Click any lead to see their full profile:
Name, email, company if known. Anonymous leads show IP and location.
All sessions from this lead with page flow, duration, and source.
Every page they visited, ordered by recency.
How they found you: organic, paid, social, referral, direct.
A 0-100 score based on behavior intensity, recency, and page intent.
Whether this lead has been added to the CRM as a contact or deal.
AI-generated suggestion on what to do next (e.g., "Visited pricing 3 times · consider proactive outreach").
Leads with a score above 80 get a "High Value" badge. These are your hottest prospects. Prioritize them for outreach, proactive chat, or CRM pipeline entry.
A lead viewed your pricing page 3 times in 2 days, started a chat asking about enterprise plans, but has not purchased.
This is a high-intent lead. Steps: (1) Check their lead detail for company and role information. (2) Review the chat transcript for specific needs and objections. (3) Create a deal in the CRM with the information gathered. (4) Assign a follow-up task for a sales team member. (5) If they return to the pricing page, the proactive chat rule can trigger a personalized message.
You have 50 anonymous leads with high scores but no email addresses.
Options: (1) Create a proactive rule that offers a discount or resource download in exchange for email on high-intent pages. (2) Use the chat widget to ask for email when anonymous visitors start a conversation. (3) Add an identity token to your login/signup pages so returning visitors are automatically identified.
The score considers: recency of visits (recent = higher), frequency of visits (more = higher), pages viewed (pricing/checkout = higher), session duration (longer = higher), chat interactions (engaged = higher), and return visits (multiple sessions = higher).
Yes. In CRM Configuration, you can add lead-scoring rules that boost the score based on specific keywords, events, sources, or page patterns.
OpsIQ ships a full AI-first CRM that captures customer truth, cleans data, scores leads, coaches deals, forecasts revenue, and acts, with website intelligence, support, tickets, products and payments as one live graph. Every AI action is sourced, explainable, reversible and approval-controlled.
Your daily home screen: revenue pulse, what AI found, what it did, approval queue, next moves, agent health, and ROI.
People and companies in your CRM. Search, filter, score, and manage profiles.
Visual deal board with drag-and-drop stages, win probability, and AI coaching.
Board-grade forecasting: committed, likely, best case, with confidence intervals and accuracy tracking.
Where every customer stands: active, at risk, expansion ready, renewal due, or churning.
Describe your CRM setup in plain English. OpsIQ generates a reversible plan and applies it on approval.
Self-check page: schema, agents, routes, AI actions, and live data counts.
AI proposals go to the approval queue. You approve, edit, or reject each one. Nothing happens without your say.
When AI suggests a change, it shows the current value and the proposed value. Human-entered data has provenance protection.
Every AI action is recorded in the journal. You can undo any change with one click.
Every AI recommendation shows its reasoning and the data sources it used. No black box.
Click AI CRM in the left navigation. The Command Center shows your current state.
Open CRM Health to verify the schema, agents, and routes are ready.
If a connector is active (Shopify, WHMCS, etc.), contacts are imported automatically. Otherwise, import via CSV or create manually.
Go to Pipeline and create your first pipeline with stages (e.g., Lead, Qualified, Proposal, Negotiation, Won, Lost).
Create a deal from a contact, set the amount and stage, and let the Deal Coach guide you.
No. The CRM is optional. OpsIQ works perfectly as a tracking + support + AI platform without the CRM. Enable it when you are ready to manage sales and customer relationships.
Yes. You can create contacts and deals manually. Connectors enrich the CRM with platform data (orders, subscriptions, tickets) but are not required.
The Trust Layer is the safety system that controls what the AI can do. Copilot mode (default): AI proposes, human approves. Autopilot mode (opt-in): AI acts automatically on low-risk, reversible operations.
The Command Center is your daily briefing. Open it every morning to see what happened, what needs attention, and what to do next.
Pipeline value, deals won/lost, new leads, active deals, and revenue trend, a snapshot of your current state.
AI-discovered insights: stalled deals, at-risk accounts, new opportunities, data quality issues, and market signals.
Actions the AI has taken (in Autopilot) or proposed (in Copilot): stage advances, score updates, contact enrichment, and task creation.
Queue of AI proposals waiting for your decision. Each shows the proposed action, reasoning, and evidence. Approve, edit, or reject.
AI-ranked list of the 10 most important things to do today: follow up on a hot deal, check an at-risk account, research a new lead, etc.
Health of AI agents: Capture, Data Steward, Deal Intelligence, Deal Coach, SDR, Retention. Green = running, amber = needs attention, red = error.
ROI tracking: deals influenced by AI, time saved, accuracy of predictions, and comparison to manual CRM work.
Check pipeline health and revenue trend. Are you on track this month?
Review each AI proposal. Approve safe actions, edit where needed, reject bad suggestions.
Read AI insights. Are any deals at risk? Are there new opportunities?
Start with the top priority. The AI has ranked these by urgency and potential impact.
You were away for a week. What happened while you were gone?
Open the Command Center and check: (1) "What OpsIQ did" shows all AI actions during your absence. (2) "Needs approval" shows proposals waiting for your review. (3) "What OpsIQ found" highlights urgent items. (4) Set the dashboard date range to your absence period to see the trend.
The CRM organizes your business relationships into four objects: Contacts (people), Companies (organizations), Deals (revenue opportunities), and Tasks (follow-up actions).
A person in your CRM. They might be a customer, a prospect, a partner, or a lead. Contacts have an email, name, company, tags, lifecycle stage, and hotness score.
Use the search bar to find by name, email, company, or tags. Use filters: lifecycle stage, lead score, source, country, last activity date, assigned owner.
Click a contact to see their full profile: personal info, company, deals, activities, tickets, chats, website visits, lead score, and AI insights.
A 0-100 score calculated from behavior signals: website visits, email engagement, chat interactions, purchase history, and recency. Higher = hotter.
Contacts are linked to companies by email domain or manual assignment. One company can have many contacts.
A revenue opportunity. Deals have a title, amount, pipeline, stage, win probability, close date, assigned owner, and associated contacts/company.
A percentage chance of winning the deal. Set manually or calculated by AI based on your historical win data. Drives the weighted forecast.
Green (healthy), amber (at risk), or red (stalled). Based on activity recency, stage duration, and engagement signals.
A follow-up action assigned to a person. Tasks have a title, due date, priority, type (call, email, meeting, other), and linked contact/deal.
The AI creates tasks automatically when it detects something needs attention: follow up on a stalled deal, respond to an at-risk account, research a new lead.
You want to see all high-score contacts in the UK who have not been contacted recently.
Go to Contacts. Filter by: Lead score > 80, Country = United Kingdom, Last activity > 7 days ago. Sort by lead score descending. These are your hottest neglected leads, prioritize outreach.
A contact just expressed interest in your enterprise plan during a chat.
Open the contact profile. Click "Create deal." Enter the deal title (e.g., "Acme Corp - Enterprise Plan"), amount, pipeline, and stage (e.g., "Qualified"). Set the close date and assign it to yourself. The Deal Coach will begin tracking this opportunity.
The Pipeline is a visual board where deals move through stages from left to right. Drag and drop cards to advance deals. Each card shows the deal amount, win probability, and health status.
The pipeline shows all active deals as cards arranged in columns (stages). Each column header shows the total value of deals in that stage.
Drag a card to the next stage. The win probability and counts update instantly. If the move fails (validation error), the card snaps back to its original position.
Green badge = healthy (recent activity, on track). Amber = at risk (slowing down, needs attention). Red = stalled (no activity for too long).
Click a card to open the deal detail panel with contacts, activities, Deal Coach brief, and quick actions.
AI proposals appear in the approval queue at the top of the pipeline page. Each proposal shows what the AI wants to do, why, and the evidence. You can:
Accept the proposal as-is. The action runs through the Trust Layer and is recorded in the journal.
Modify the proposal before approving. For example, change the suggested stage or adjust the amount.
Decline the proposal. The AI learns from rejections to make better suggestions in the future.
Win probability can be set manually or calculated by AI. When AI calculates it, it uses a model trained on your own closed deals (won and lost). If you don't have enough historical data, the AI uses the stage default probability. The probability drives the weighted forecast: a $10,000 deal at 30% probability contributes $3,000 to the "likely" forecast.
A customer signed the contract and paid.
Drag the deal card to the "Won" stage. OpsIQ will: (1) Mark the deal as closed-won. (2) Update the forecast. (3) Add a "Won" activity to the timeline. (4) If configured, trigger a webhook event (crm.deal.won). (5) Update the contact lifecycle stage to "Customer."
You want to find deals that have been in the same stage for too long.
Look for red (stalled) badges on the pipeline board. These deals have had no activity for longer than the configured rotting threshold (set in CRM Configuration > Pipelines). Click each stalled deal to see the Deal Coach's recommendation for reactivation.
Yes. Go to CRM Configuration > Pipelines to create additional pipelines. Common use cases: separate pipelines for new business vs. renewals, or for different products/services.
The deal is marked as closed-lost. You will be asked for a loss reason. The deal is removed from the active board but can be found in the closed deals filter. The contact remains in the CRM.
The Deal Coach analyzes each deal and gives you a brief with health status, risk signals, key people, a qualification checklist, meeting prep, and suggested next actions. Everything is sourced. The coach shows which ticket, chat, or activity each claim comes from.
Why the deal is healthy, at risk, or stalled. Specific signals: days in stage, last contact date, activity frequency, competitor mentions, objection patterns.
Categorized into: objections raised, competitor mentions, pricing discussions, support risk indicators, renewal/expansion signals. Each signal links to its source (chat transcript, ticket, email, activity).
Who is helping the deal (champion) and who is resisting (blocker). Based on interaction analysis and contact roles.
MEDDICC or BANT checklist (configurable) showing which qualification criteria are met and which are missing. Grade: A, B, C, D, or F.
Before a scheduled meeting, the coach generates a brief: agenda, key points to cover, questions to ask, risks to address, and materials to prepare.
Suggested next message or call script based on the current deal state and recent interactions.
Every claim the coach makes links to a source: a ticket number, chat transcript ID, activity date, or website visit.
Open any deal and scroll to the Deal Coach section. Read the health status and key signals.
Check the qualification checklist. If "Economic Buyer" is missing, plan to identify and engage the budget holder.
The coach suggests concrete next actions. Click to create a task, draft an email, or schedule a meeting, all routed through the approval queue.
You have a meeting with a prospect tomorrow about a $50,000 deal.
Open the deal and read the Meeting Prep section. It shows: (1) Key talking points based on recent interactions. (2) Objections they raised in chat last week. (3) Competitor they mentioned in a support ticket. (4) Questions to ask about their timeline. (5) Risk factors to address proactively. Use this brief to prepare a focused, evidence-based agenda.
The pipeline shows a red badge on a deal you thought was going well.
Click the deal and read the Deal Coach health explanation. It might say: "This deal has been in Proposal stage for 22 days (threshold: 14). Last contact was 11 days ago. The primary contact opened a support ticket about data migration concerns 5 days ago (ticket #T-892). Suggestion: address the migration concern and schedule a follow-up call." Now you know exactly what to fix.
Board-grade forecasting with a defensible range, deal-level change explanations, and accuracy tracking so you can prove and explain your numbers.
Deals with 80% or higher win probability. These are your most likely wins. This should be your minimum expected revenue.
All open deals weighted by their AI-calculated win probability. This is the most realistic prediction of what you will close.
All open deals at full value. This is the maximum possible revenue if everything goes perfectly (it rarely does).
An 80% probability band showing the realistic range. Example: "You will likely close between $45,000 and $72,000 this quarter."
The forecast includes week-over-week change attribution. When your forecast drops by $15,000, the report explains exactly which deals caused the change: "Deal A slipped to next quarter ($8,000), Deal B lost ($5,000), Deal C reduced in value ($2,000)."
Mean Absolute Percentage Error: how far off your forecasts have been historically. Lower is better. A MAPE of 15% means your forecasts are typically within 15% of actual results.
Brier score measuring how well win probabilities match actual outcomes. If deals at 70% probability actually win 70% of the time, calibration is good.
OpsIQ captures a snapshot of your forecast each week (via cron). Over time, you can see how your forecast accuracy improves.
How many deals move from each stage to the next. If 80% pass from Qualified to Proposal but only 20% go from Proposal to Negotiation, your proposals might need work.
Which lead sources produce the most wins. Invest more in high-win-rate sources.
How each sales team member is performing: deals won, pipeline value, average deal size, win rate.
Sandbagging (unrealistically low probabilities), overcommitting (unrealistically high), and committed-at-risk (high-probability deals showing stall signals).
Your quarterly forecast dropped from $180,000 to $155,000 since last week.
Open the Forecast page and check "What changed." The report shows: "Acme Corp deal ($15,000) moved to Lost, competitor chosen. Beta Inc deal ($8,000) close date pushed to next quarter. New deal with Gamma LLC ($3,000) added this week." The net change is -$20,000 + $3,000 = -$17,000, explaining the drop from $180K to $163K (with the remaining $8K explained by probability adjustments on other deals).
The Prospecting Agent helps you find and research potential customers. Describe your ideal customer, add target companies, and let the AI research, score, and draft first-touch outreach.
Go to CRM Configuration > Prospecting. Describe your ideal customer profile (ICP): target industries, company sizes, job titles, geographic focus, product-match terms, and minimum fit score. Example: "B2B SaaS companies with 50-500 employees in the US/UK, selling developer tools, with a VP of Sales or Head of Growth as the primary contact."
Enter company domains or names you want to research. You can also let the AI suggest companies based on your ICP.
The AI enriches each company with available data: size, industry, tech stack, recent news, and fit score with explanation.
For good-fit companies, the AI drafts a personalized first-touch message. Review and approve in the queue.
Each prospect gets a 0-100 fit score based on five factors:
How well the company matches your ideal customer profile (industry, size, location).
Is there evidence they need your product now? Job postings, tech changes, complaints about competitors.
Company size, funding stage, and revenue indicators suggest budget availability.
How relevant your product is to their business based on industry and technology.
Whether you can effectively serve this customer (timezone, language, complexity).
You want to evaluate whether acme.com is worth pursuing.
Add acme.com to the prospecting list. The AI returns: Fit score 78/100 (good fit). Reasons: B2B SaaS, 120 employees, US-based, recently hired a VP of Sales (urgency signal), uses competitor X (product match). Buying signals: visited your pricing page twice last month (from website tracking). Best contact: [email protected] (VP of Sales). Drafted opener references their recent hiring and pricing page visits.
Sequences automate multi-step follow-up: a mix of email, wait, task, call, and webhook steps that run automatically after you approve the initial send.
Define the steps: email, wait 3 days, email, wait 5 days, task (call if no reply), email. Each email step has a template you can customize.
Add contacts to the sequence. The AI may also propose enrollment from prospecting results.
Steps run automatically on schedule. If a contact replies at any point, the sequence pauses automatically.
See open rates, reply rates, conversion rates, and unsubscribes per step. Use this to optimize your sequence.
When a contact replies, the AI classifies the reply:
Interested, wants to talk. Sequence pauses, task created for follow-up.
Has concerns but not rejecting. Sequence pauses, task created with objection details.
Wants to stop receiving messages. Contact is suppressed permanently.
Interested but timing is wrong. Sequence pauses, snooze task created.
Not the right contact. Sequence stops, contact flagged for review.
A support question, not a sales response. Sequence pauses, ticket created.
Unsubscribe requests are honored immediately and the contact is suppressed from all future sequences.
Workspace-level daily limit (default: 1,000 emails). Prevents mass sends that trigger spam filters.
Maximum 1 message per contact per day. Prevents overwhelming individual people.
Steps that exceed the daily cap are deferred to the next day. They are never dropped or skipped.
The sequence pauses automatically. Support takes priority over outreach. The sequence can be manually resumed after the support issue is resolved.
Not directly within sequences, but you can create two sequences with different messaging and compare their results.
One page under CRM that holds the growth engine: recurring revenue (MRR/ARR), the product catalog, lead-capture forms, booking links and lead routing. Everything here writes straight into the CRM, so a form submission or a booked call is a contact with history, not a row in a spreadsheet.
MRR and ARR projected from your real billing ledger. Subscriptions are grouped from payments per platform, the billing cycle is inferred from payment gaps, and a subscription lapses when a payment is overdue past 1.5 times its cycle. Customers link to CRM contacts automatically when the ledger carries their email.
One source of truth for what you sell. Quotes pull the name and list price from the catalog, and accepted quotes roll up into revenue by product. Products archive, they never delete.
Each form gets a hosted page plus an iframe embed code for your own site. Submissions become contacts, the owner gets a notification, and your routing rules assign the lead.
Share a link, let prospects pick a free slot. Slots respect the organizer's working hours, timezone and existing meetings. A booking creates the meeting, emails the prospect a confirmation and notifies the organizer.
Territory rules run first, then field rules (match a field such as country or source), then round-robin across your rep pool. It routes CONTACTS AND DEALS alike, whatever the deal’s status: a won deal still needs an owner for commission attribution, account responsibility and follow-up, and in owner or team visibility mode an unowned record is invisible to everyone but a manager. Records created by automation (a connector sale, chat, an import) carry no interactive creator, so they are routed by the same rules on create rather than left ownerless. Anything that already has an owner is never reassigned.
Go to CRM, then Growth Tools, then the Lead-capture forms section.
Type a name and a comma-separated field list, for example name,email,phone,message. Email is always required.
Copy the hosted link to share it anywhere, or copy the embed code and paste it into any page of your website.
Every submission is a CRM contact with a form.submitted activity, an owner notification, and automatic routing.
A hidden honeypot field silently discards bot submissions.
Ten submissions per hour per IP address across forms and bookings.
Submitting a form does not grant marketing consent. Only an explicit consent checkbox does.
A slot is re-validated against a fresh availability check at the moment of booking.
From the same commerce ledger your Sales page uses, fed by billing connectors. Use Re-sync from billing after connecting a new platform.
Yes. Every form has a hosted page on your own address that works standalone, with or without JavaScript.
One connector, up to twenty gateways. Connect the SMS and WhatsApp providers you actually use, mark one as default, and pick any of them when texting a contact. Consent is checked by the CRM before any gateway is contacted.
On the Connectors page, open Messaging Hub (SMS and WhatsApp) and enable it.
In the same drawer, or in CRM Growth Tools, pick a gateway from the dropdown (Twilio, Vonage, Termii, Meta WhatsApp Cloud, Infobip and more), paste its API credentials and connect. You can add several, including the same gateway twice with different accounts.
Each provider entry shows its own webhook URL with a copy button. Paste it into the gateway's delivery-report and inbound-message settings to get delivery status and replies back into OpsIQ.
Open a contact and use the SMS or WhatsApp button. If more than one provider supports the channel, a selector lets you choose; otherwise the default is used.
Unknown consent is not consent. A send refuses unless SMS consent is explicitly granted. WhatsApp rides the same consent.
A do-not-contact flag blocks every channel, no matter what else is set.
Contacts on the suppression list are never messaged.
A blocked send tells you exactly why, so you can fix the data instead of guessing.
https://your-address/opsiq/cron/messaging_webhook.php?sk=SITE_KEY&e=ENTRY_ID&t=TOKEN. The per-entry token is minted when the provider is connected and never rotates on edit.
Twilio form posts (MessageStatus/MessageSid for delivery, Body/From for inbound), Meta WhatsApp Cloud JSON (statuses and messages, including the hub.challenge subscription handshake), and a generic JSON shape: {"type":"delivery","message_id":"...","status":"delivered"} or {"type":"inbound","from":"+234...","body":"..."}.
Delivery reports stamp the outreach ledger row that carries the provider message id as delivered or bounced. Inbound messages match the contact by phone number inside the workspace, land as a message.received activity, and mark the conversation replied.
Wrong or missing token answers 403. Unknown payloads are counted and ignored, never fatal, so a misconfigured gateway cannot break the endpoint.
Twilio, Vonage, Plivo, MessageBird, Sinch, Infobip, Telnyx, ClickSend, Termii, Africa's Talking, BulkSMS, Textlocal, Meta WhatsApp Cloud, 360dialog, SMSAPI, Gupshup, Kaleyra, D7 Networks, Hubtel, and a custom HTTPS webhook for anything else.
Credentials are stored encrypted in the connector settings and are never echoed back to the browser. Editing an entry with a blank secret keeps the stored one.
Yes, through registered actions that require confirmation and run the same consent gate. The AI can also list connected providers to explain what is available.
Lifecycle management helps you protect existing revenue. Each account gets a churn risk score, a health score, an expansion score, and a recommended success playbook.
Visual board showing where every account stands: Lead, Prospect, Opportunity, Customer, Expansion, Renewal, At Risk, Churned.
Accounts flagged with high churn risk. Each shows the top driver (support spike, inactivity, payment failure) and a recommended save play.
Accounts that show signals of readiness to buy more: high usage, feature requests, plan inquiries.
Accounts with upcoming renewal dates. Sorted by risk level and revenue value.
Churn risk is calculated from multiple signals fused together:
Deal health, inactivity, recent losses, declining engagement.
Open ticket count, ticket volume spikes, negative sentiment, escalations.
Login frequency, feature usage, page visits, API calls.
Failed payments, overdue invoices, downgrade requests, cancellation page visits.
For at-risk accounts: reach out proactively, address the concern, offer support, escalate if needed.
For upcoming renewals: confirm satisfaction, review usage, present value, offer incentive if appropriate.
For ready-to-grow accounts: present upgrade options, share success stories, demonstrate ROI.
For underutilizing accounts: offer training, share best practices, enable features they are not using.
A customer who normally logs in daily has not logged in for 2 weeks, and they opened 3 support tickets this month.
The Lifecycle board flags this account as "At Risk" with drivers: inactivity (14 days since last login) and support spike (3x normal ticket volume). Recommended play: proactive outreach call to understand what is happening. Is there a product issue? Are they evaluating competitors? Early intervention can save the account.
The Data Steward agent automatically finds and fixes data quality issues: duplicates, missing fields, inconsistencies, and stale records.
Multiple records for the same person (e.g., [email protected] and [email protected]). The steward proposes merging them.
Contacts without email, deals without amounts, companies without domains. Suggests filling from available sources.
Deals without associated contacts, contacts without companies. Proposes linking based on email domain and context.
A deal in "Won" stage with 20% probability, a contact marked "Customer" with no deals, a company with mismatched industry.
Deals that have been in the same stage for too long or contacts whose lifecycle stage does not match their activity.
Go to CRM and find the Data Steward section (or open it from CRM Health).
Green items are safe: clear duplicates, obvious missing data. Approve these in bulk.
Amber items need your judgment: possible duplicates with slight differences, proposed stage changes, company linking. Review each one.
The steward found "John Smith ([email protected])" and "J. Smith ([email protected])": same email, different display names.
The steward proposes merging: keep the record with more activity, merge the other record's deals and activities. Review the proposal, adjust the surviving display name if needed, and approve. Both records' history is preserved in the merged contact.
Build My CRM lets you describe your CRM setup in plain English. OpsIQ generates a validated, reversible plan and applies it on approval. No coding, no manual configuration clicking.
Type a plain-English description of your CRM setup. Example: "Create a renewal pipeline with stages: Upcoming, Contacted, Negotiating, Renewed, Lost. Score leads higher when they view pricing twice."
OpsIQ shows a preview of what it will create: pipeline, stages, stage probabilities, scoring rules, lifecycle rules. Review each item.
Click Apply to execute the plan. Every change is recorded as a bundle you can undo in one click.
If something is not right, click Undo to revert the entire bundle. Your CRM returns to its previous state.
Create named pipelines with custom stages, default probabilities, and rotting thresholds.
Boost lead scores based on behavior: "Score higher when they view pricing," "Score lower when they visit careers page."
Automatically advance lifecycle stages: "Move to SQL when they request a demo," "Move to Customer when deal is won."
Add fields to contacts, deals, or companies: text, number, date, select, checkbox, URL, email.
Define the MEDDICC or BANT checklist the Deal Coach grades against.
You manage SaaS subscriptions and need a pipeline for renewals.
Type: "Create a renewal pipeline. Stages: 90 Days Out (10%), 60 Days Out (25%), Contacted (40%), Negotiating (60%), Renewed (100%), Churned (0%). Set the rotting threshold to 14 days." OpsIQ generates the plan, you review it, and click Apply. The pipeline appears on your Pipeline page immediately.
The builder only generates actions it knows how to validate. If you ask for something outside its capabilities (e.g., "Integrate with my custom API"), it will reject the request and explain what it can do instead.
Yes. Every Build My CRM action is captured as a reversible bundle. Go to CRM Health > Change History to see all bundles and undo any of them.
Manual CRM configuration for teams that prefer clicking over typing. All settings that Build My CRM can create are also available as traditional form fields.
Create, rename, reorder, and delete pipelines and stages. Set default win probability per stage. Set the rotting threshold (days without activity before a deal is marked "stalled").
Add fields to deals, contacts, or companies. Field types: text, number, date, select (dropdown with predefined options), checkbox, URL, email. Custom fields appear on the object profile and in filters.
Define the checklist the Deal Coach uses to evaluate deals. Choose MEDDICC, BANT, or a custom set of criteria. Each item can be marked required or optional.
Define automatic stage transitions: when a contact meets a condition (views pricing, submits a form, makes a purchase), their lifecycle stage advances automatically.
Boost or reduce lead scores based on behavior. Examples: "Viewed pricing page = +15 points," "Downloaded whitepaper = +10 points," "Visited careers page = -5 points." Minimum count can be set (e.g., "must view pricing at least 2 times").
Create named filter+sort combinations for contacts, deals, or companies. Share views with your team. Set a default view per object type.
You want contacts who view your pricing page twice or more to get a higher score.
Go to CRM Configuration > Lead Scoring Rules. Click Add Rule. Set: Event = "pageview", URL contains = "/pricing", Minimum count = 2, Score boost = +20. Save. The next time the scorer runs, contacts matching this rule will get +20 to their lead score.
CRM Health is a self-diagnostic page that verifies your CRM is set up correctly and running smoothly.
Database tables exist and have the correct columns. If a migration was missed, CRM Health will flag it.
All CRM agents (Capture, Data Steward, Deal Intelligence, etc.) are registered and healthy. Green = running, amber = needs attention, red = error.
CRM API routes and AJAX endpoints are registered and callable.
The CRM action catalog is registered in the Action Registry. If actions are missing, CRM Health self-heals by re-registering them.
Total contacts, companies, deals, tasks, activities, and events. Useful for verifying imports and ongoing data capture.
After first-time CRM setup, open CRM Health and verify all checks are green. If any are amber or red, click the item for a diagnostic explanation and suggested fix.
Check after initial setup, after major updates, and whenever CRM behavior seems wrong. CRM Health self-heals many issues (like missing action registrations) just by opening the page.
The CRM exposes a complete public REST API and outbound webhooks so it fits any stack without manual exports.
API key (Authorization: Bearer opq_...) with scope crm.read or crm.write. POST to /api/v1.php with action and site_key.
crm.contacts.list (search + filter), crm.contacts.detail (by ID), crm.contacts.upsert (create or update), crm.contacts.save.
crm.deals.list, crm.deals.detail, crm.deals.create, crm.deals.update, crm.deals.advance (all through the Trust Layer).
crm.activities.list (timeline for a contact/deal), crm.activities.record (log a new activity).
crm.events.list (durable change feed with since_id cursor), crm.events.catalog (list available event types).
POST /api/v1.php
Authorization: Bearer opq_live_xxx
Content-Type: application/json
{
"action": "crm.deals.create",
"site_key": "<workspace>",
"title": "Acme renewal",
"amount": 12000,
"pipeline_id": 1,
"stage_id": 2
}Fired when a contact is created or updated. This is the contact event to subscribe to; there is no separate created event.
Fired when a contact moves to a different lifecycle stage.
Fired when a contact status changes.
Fired when a conversion is recorded against a contact.
Fired when a tag is added to a contact.
Fired when a contact is erased for a privacy request.
Fired when a deal is created.
Fired when a deal moves to a different stage.
Fired when a deal is closed as won.
Fired when a deal is closed as lost.
Fired when a company is created.
Fired when a new task is created (manual or AI-generated).
Fired when a contact replies to an outreach email.
Fired when an outreach email bounces.
webhooks.events.list for the authoritative set on your install, with the payload of each event. It is generated from the delivery code itself, so it can never disagree with what actually arrives. The full list also appears in the Webhooks section.All webhook events are HMAC-signed and retried on failure. Subscribe a URL in Settings > Webhooks, or poll crm.events.list with since_id for a durable change feed.
You want every new CRM contact to appear in a Google Sheet for your marketing team.
Set up a webhook subscriber for opsiq.contact.upsert. Point it to a Google Apps Script web app or a Zapier webhook URL. The payload includes the contact name, email, company, lead score, and source. Your script appends a row to the Google Sheet for each new contact.
Segments save reusable contact filters for CRM views, outreach, promotions and other audience-aware tools.
A live segment recalculates from current data whenever it is used. A pinned snapshot freezes the current member list, which is useful when an outreach audience must not change after approval.
Choose ALL when every condition must match or ANY when one condition is enough. Review the live count before saving. System segments can be visible but protected from ordinary editing.
Lead-scoring rules turn behaviour and profile signals into a consistent score that sales and automation can use.
The AI rule builder can turn a plain-English instruction into a structured rule. Every rule should still be reviewed before activation: confirm the activity or keyword, minimum count, rolling window and score change.
Positive and negative rules can coexist. Use Rescore workspace after material rule changes so existing contacts are evaluated under the new model. Scores can feed segments, routing, prospecting and workflow conditions.
The leaderboard compares representatives using quota attainment, won revenue, commission and open pipeline for the selected month.
Quota attainment is meaningful only when each representative has a current quota and deals have the correct owner, amount, currency and close status. Use the leaderboard for coaching and recognition, not as the only quality measure; pair it with deal health, activity and forecast accuracy.
Deal approvals require manager sign-off before high-value deals can be marked won.
Enable the policy and set Level 1 and Level 2 thresholds. A threshold of 0 disables that tier. When a non-manager tries to win a deal at or above the threshold, OpsIQ creates an approval request instead of silently changing the stage.
Managers and full administrators are not blocked by the policy. Every decision should retain the requester, approver, time and reason for auditability.
Lifecycle rules automatically move contacts between stages when their current data matches a saved condition.
Each rule has a source stage, destination stage, active flag, priority and segment-style filter. The scheduled lifecycle job evaluates higher priorities first and stops after the first match for a contact.
Rules should be mutually understandable. Avoid two active rules that can move the same contact in opposite directions during the same run. Test the filter against a segment before activating it.
The workspace activity stream combines customer and operational events so teams can investigate what happened without opening every module.
Filter by event type, date, contact or customer state (including paying customers). The feed is a read model of recorded activity; it does not replace the source ticket, conversation, deal or connector record. Open the linked record before taking a sensitive action.
Workflows respond to an event and run an ordered series of actions, including delayed steps resumed by cron.
Create a workflow by choosing the trigger, adding steps in order and enabling it. Delays are stored, not held by a browser request; the unified cron resumes due workflow runs.
Built-in starting templates include welcome after signup, post-purchase thank-you and demo confirmation. Clone a template, replace its recipients/content, then test with a controlled record before broad activation.
Design actions to be idempotent. A retry must not send duplicate money-moving requests or create duplicate records.
Tickets are your formal support channel. They have departments, priorities, SLA targets, attachments, internal notes, and full conversation threading. Tickets can arrive from the OpsIQ admin, ticket form/embed, email ingestion, chat escalation, connector, or API.
A customer sends a message via email, chat escalation, ticket embed, or the admin creates one. The ticket gets a unique ID (e.g., T-12345).
AI reads the subject and body, assigns priority (Low/Normal/High/Urgent), suggests a department, and detects sentiment. This happens automatically if triage is enabled.
An agent opens the ticket, reads the context (customer profile, platform data from connectors, previous tickets), and writes a reply. AI can draft the reply, and the agent edits before sending.
When the issue is resolved, the agent closes the ticket. The customer is notified. If the customer replies after closing, the ticket reopens automatically.
Move the ticket to a different department (e.g., from General to Billing). Useful when the initial routing was wrong.
Assign the ticket to a specific team member. The assigned agent sees the ticket in their "My tickets" view.
Write a note visible only to staff. Use for: investigation findings, refund reasons, engineering context, previous commitments. Internal notes never appear to customers.
Combine duplicate tickets from the same customer. The merged ticket subject gets a [MERGED] tag. All messages from both tickets are preserved in the surviving ticket.
Insert a pre-written reply template. Variables like {{customer_name}} and {{ticket_id}} are automatically replaced.
Let AI improve your draft reply: adjust tone, shorten/lengthen, fix grammar, or translate. You review the result before sending.
Set to Low, Normal, High, or Urgent. Priority affects SLA timers and sort order.
Set to Open, Pending, Waiting on Customer, Resolved, or Closed.
Subject: Double charge on my account Body: Hi, I just checked my bank statement and I see two charges of $49.99 from your company dated June 3. I only have one subscription. Can you please refund the duplicate charge? This is really frustrating.
Step 1: AI triage assigns Priority: High, Department: Billing, Sentiment: Frustrated. Step 2: Agent opens the ticket. The connector panel shows the customer's Stripe charges, confirmed two charges on June 3. Step 3: Agent adds an internal note: "Confirmed duplicate charge in Stripe. Transaction IDs: ch_xxx and ch_yyy." Step 4: Agent drafts a reply: "Hi [Name], I can see the duplicate charge and I'm processing a refund for the second transaction right now. You should see $49.99 back in your account within 3-5 business days. I'm sorry for the inconvenience." Step 5: Agent triggers the refund action through the Stripe connector (with confirmation). Step 6: Agent sends the reply and sets status to Resolved.
Create departments in Settings > Tickets > Departments. Common departments: General, Billing, Technical, Sales, Abuse, Onboarding. Each department can have different auto-reply rules, AI knowledge, and team assignments.
Create reusable reply templates in Settings > Tickets > Canned Responses. Good canned responses include:
Hi {{customer_name}},
Thanks for reaching out. I checked the details and here is what I found:
{{response_details}}
If you need anything else, just reply to this ticket and I will be happy to help.
Best regards,
{{agent_name}}
{{department_signature}}When a customer sends the same question multiple times (via email and chat, or two separate emails), you can merge the duplicates. Go to the ticket, click Merge, select the other ticket to merge. The surviving ticket gets all messages from both tickets. The merged ticket's subject gets a [MERGED] tag to indicate it was combined.
Non-urgent questions, feature requests, general feedback. Target first response: 24 hours.
Standard support questions. Target first response: 8 hours.
Impacting the customer's business. Target first response: 4 hours.
Service down, security incident, data loss, billing error. Target first response: 1 hour.
SLA timers start when the ticket is created and pause when the status is "Waiting on Customer." If the SLA target is missed, the ticket is highlighted and optionally escalated.
Never. Internal notes are strictly staff-only. They do not appear in the customer ticket portal, email notifications, or any customer-facing surface.
The ticket automatically reopens and returns to the active queue. The team is notified of the new reply.
Yes. Use the Lock Thread option to prevent both customer and AI from adding new replies. Useful for resolved disputes or closed investigations.
The control room for how your support operation behaves: SLA policies with escalation ladders, business-hours calendars, an enforced status flow, CSAT settings and the enterprise feature switches. Open it from the Tickets page (the Service Studio button in the operations bar).
Every new ticket gets a first-reply and a resolution deadline from the most specific active policy: department + priority beats department, beats priority, beats the default. Deadlines pause automatically while a ticket sits in Pending or On hold.
Instead of one breach action, a policy can define up to six steps: for example warn the assignee at 75% of the window, alert managers at 100%, reassign to a named agent at 150%. Each step fires exactly once per ticket.
With business hours on, SLA clocks only burn during working time, so a ticket opened Friday evening is not breached by Saturday. Named calendars (timezone, days, hours, holidays) can be attached to individual policies for teams in different regions.
A from/to matrix restricting which status changes admins may make, with a Zendesk-style preset. Automation, inbound email and customer-originated ticket replies are always exempt, so a strict matrix can never jam the pipeline. Optionally require an approved sign-off before closing.
Agents request sign-off on a ticket (refunds over a threshold, policy exceptions). A named approver or any Full Administrator decides with a note; requesters can never approve their own request. Pending approvals surface as a banner on the inbox.
Link tickets as related, duplicate, parent/child or blocking; split replies out to a new linked ticket (the reverse of merge, without emailing the customer); follow tickets for in-app notifications, and optionally CC follower email addresses on outbound replies.
With the real-time inbox enabled, new tickets and replies appear for agents within seconds through the existing notification stream. On a ticket, agents see who else is viewing and get a warning banner when a teammate is already writing a reply. A one-click Claim button assigns the ticket to yourself.
Routing rules can match on AI triage signals: priority, category, sentiment and escalation risk, plus typed custom-field values from your portal request form. Rules using these conditions stay dormant until the feature is enabled.
The matrix only governs ADMIN actions. Customer-originated replies, email replies and automation are deliberately exempt so a strict policy can never lock customers out or break the pipeline.
No. Policies saved with a single breach action keep working unchanged. A ladder replaces the single action only on policies where you define steps.
Auto-reply lets the AI respond to new tickets automatically. Escalation moves tickets to a different department when the AI detects specialized needs. Both features work across native tickets and email-created tickets.
A new ticket is created from any source (email, chat, portal, API).
OpsIQ waits for the configured delay (default: 2 minutes). This gives human agents a chance to respond first.
If a human agent replies during the delay, auto-reply is cancelled. If not, the AI generates a reply.
The AI reads the ticket, checks knowledge base, connector context, and customer history, then writes a reply. The reply is sent (or queued as a draft for review, depending on settings).
Set which departments can receive escalations (e.g., Billing can be escalated from General, Technical can be escalated from General).
Before auto-replying, the AI classifies the ticket intent: billing, technical, refund, abuse, etc.
If the ticket intent matches an escalation department, the ticket is moved. An internal note explains why.
The reply is generated using the destination department's knowledge and AI training.
Master switch. Turn on to enable AI auto-reply for tickets.
Which departments can receive auto-replies. Start with low-risk departments (General, Sales) before enabling billing.
How long to wait before the AI replies (in seconds). Default: 120 seconds (2 minutes). Set to 0 for instant replies.
Optionally set different delays for business hours vs. after hours.
If a human agent replies first, cancel the auto-reply. Default: on.
Enable automatic department routing based on ticket intent.
Which departments tickets can be escalated to.
What status to set when escalating (e.g., Open, Pending).
Whether to add an internal note explaining the escalation reason.
Tickets created from email (via mailbox polling or MX-piped delivery) follow the same auto-reply and escalation rules. The AI reply is sent as an email response to the customer. Email drafts go to the drafts queue for review if configured.
Only if you enable auto-reply for the Billing department. We recommend starting with auto-reply off for billing and enabling it only after you have trained the AI with comprehensive billing knowledge and tested thoroughly.
If a customer replies saying the answer was wrong, a human agent should intervene. Review AI History to understand why the AI gave the wrong answer, then update the knowledge base or AI training to prevent it from happening again.
Yes. Set the delivery mode to "Draft" instead of "Auto-send." Auto-reply drafts will appear in the Drafts queue for human review before sending.
The ticket portal embed lets you add a ticket management interface to any website. Customers can view their tickets, create new ones, and reply, all without entering the OpsIQ admin.
Renders the ticket portal inside a div on your page. The portal takes the full width of its container.
Shows a floating button that opens the ticket portal in a panel. Similar to a chat widget.
Requires a signed identity token. Customers see only their own tickets.
<script src="https://your-opsiq-domain.com/widget.php" data-site-key="site_abc123" data-mode="tickets" data-identity-token="SERVER_GENERATED_TOKEN" async></script>
For authenticated mode, your server must generate a signed identity token. This token tells OpsIQ who the customer is so they see only their own tickets.
<?php
// Generate identity token (PHP)
$site_secret = "opsiq_whsec_your_secret";
$payload = json_encode([
"site_key" => "site_abc123",
"customer" => [
"id" => "cust_1001",
"email" => "[email protected]",
"name" => "Ada Lovelace",
],
"iat" => time(),
"exp" => time() + 900, // 15 minutes
]);
$token = base64_encode($payload) . "." . hash_hmac("sha256", $payload, $site_secret);
// Pass $token to the frontend// WHMCS hook — auto-generate identity token
add_hook("ClientAreaPage", 1, function($vars) {
if (!isset($vars["loggedinuser"])) return;
$payload = json_encode([
"site_key" => "site_abc123",
"customer" => [
"id" => $vars["loggedinuser"]["id"],
"email" => $vars["loggedinuser"]["email"],
"name" => $vars["loggedinuser"]["firstname"]." ".$vars["loggedinuser"]["lastname"],
],
"iat" => time(),
"exp" => time() + 900,
]);
$token = base64_encode($payload).".".hash_hmac("sha256", $payload, "opsiq_whsec_xxx");
// Inject into page
});// Node.js / Express — generate identity token
const crypto = require("crypto");
function generateOpsIQToken(customer) {
const payload = JSON.stringify({
site_key: "site_abc123",
customer: {
id: customer.id,
email: customer.email,
name: customer.name,
},
iat: Math.floor(Date.now() / 1000),
exp: Math.floor(Date.now() / 1000) + 900,
});
const sig = crypto.createHmac("sha256", "opsiq_whsec_xxx")
.update(payload).digest("hex");
return Buffer.from(payload).toString("base64") + "." + sig;
}Searchable, status-filtered list. An "Awaiting you" highlight flags tickets the team has answered.
Full conversation view with rich text, attachments, and timestamps.
Customer draft replies are auto-saved so they do not lose work if they navigate away.
The widget polls for new replies every ~12 seconds.
Customers can resolve or reopen their own tickets with one click.
The Chat Inbox is where your team manages live customer conversations. It shows active chats, assigned conversations, AI-handled chats, and archived history.
Conversations currently in progress. Green dot = customer is typing or recently active.
Conversations where the AI is responding. You can take over at any time by clicking "Join."
Conversations assigned to you specifically.
Conversations where the customer is waiting for a response.
Completed conversations. Searchable by keyword, date, and customer.
When you take over a conversation from the AI, follow these three rules:
Introduce yourself by name. "Hi, this is Sarah from the support team."
Show you read the conversation. "I can see you asked about your order status."
Tell the customer what happens next. "I am looking into this now and will have an answer for you in a few minutes."
Use the AI toggle at the top of each conversation. When AI is on, the AI generates responses. When off, only human agents can reply. The AI remembers the conversation context even when turned off and back on.
Configure business hours in Settings. Outside business hours, the AI can: (1) Continue responding to customers, (2) Show an "away" message and create a ticket for follow-up, or (3) Disable chat completely and show the ticket form. Choose the behavior that fits your support model.
Do not match the customer's emotional intensity. Acknowledge their frustration without being defensive.
Before responding, gather the relevant information: order details, account status, previous tickets.
If the situation involves refunds, legal threats, abuse, or security, escalate to a senior team member rather than trying to handle it alone.
Yes. Use internal notes within a conversation to communicate with other agents. These notes are never visible to the customer.
The conversation moves to the Archive. If the customer sends a new message later, a new conversation is created.
Connect WhatsApp, Facebook Messenger, Instagram DM, Telegram and LINE so the messages customers already send you arrive in the same inbox as your website chat, answered by the same AI assistant.
Every channel behaves identically once connected: a customer message becomes a conversation in the Chat Inbox, your AI assistant answers it using the same knowledge and instructions as your website chat, and any agent can take over. Nothing about your AI needs configuring per channel.
One click. Open Connectors → Facebook Messenger & Instagram DM, click Connect, sign in with the Facebook account that manages your Page, and choose the Page. Instagram comes with it when your Page has an Instagram professional account linked.
One click where your provider offers it: open the Messaging Hub connector and use Connect WhatsApp, then follow Meta's guided sign-up to pick or create your WhatsApp Business number. Otherwise paste credentials from any of 20 gateways.
Two minutes. Message @BotFather in Telegram, send /newbot, choose a name and a username ending in "bot", and paste the token it gives you into the Telegram connector. OpsIQ registers the webhook for you.
Create a Messaging API channel at developers.line.biz, paste the Channel secret and access token, then copy the webhook URL shown in OpsIQ into LINE and switch its own auto-replies off.
Add a provider (Twilio, Vonage, Termii and others) in the Messaging Hub with its credentials and sender number.
Connecting a channel does not start it. Go to Settings → Client Chat → Advanced → Messaging Channels, switch on the master toggle and then the individual channel. Each channel has its own AI auto-reply switch, so you can pilot on one before opening the rest.
In Connectors, using the instructions in that connector's drawer.
Click Test. It makes a real call to the provider and tells you what is wrong if anything is.
Settings → Client Chat → Advanced. Turn on the master switch, then the channel.
From another account, message your Page, number or bot. It should appear in the Chat Inbox within seconds and get an AI reply.
Messaging platforms limit how long a business may reply after a customer writes. OpsIQ shows the remaining time on each conversation and enforces the rule for you.
24 hours from the customer's last message. After that you may only send an approved template, which you configure in the same Advanced tab.
24 hours for normal replies; agents may answer up to 7 days later under Meta's human-agent allowance.
No platform-imposed window.
Only if you tell them. The reply comes from your Page, number or bot exactly as a human reply would. Your AI instructions control the tone and whether it identifies itself.
Yes. Open the conversation in the Chat Inbox and click Join. The AI stops, you type, and the customer sees a continuous thread on their side.
Use Disconnect on the connector. Message history is kept; new messages simply stop arriving, and the platform is told to stop sending them.
No. A Page belongs to one workspace at a time. Connecting it somewhere else moves it, and the first workspace stops receiving messages, so disconnect deliberately rather than reconnecting elsewhere.
These examples show how a well-trained Customer AI should handle common scenarios. Use them to test your AI training and identify gaps.
Customer: Hi, I placed an order 3 days ago and haven't received any shipping notification yet. Order #ORD-5523.
The AI should: (1) Look up order #ORD-5523 through the connector. (2) Report the current status and tracking info if available. (3) If the order is delayed, acknowledge the delay and provide an estimated timeline. (4) Do NOT invent a shipping status if the connector does not have one.
Customer: How much does your Pro plan cost? Do you offer annual billing?
The AI should: (1) Answer from the knowledge base with current pricing. (2) Explain the difference between monthly and annual billing. (3) If the answer is not in the knowledge base, say so and offer to connect them with sales. (4) Do NOT invent pricing that is not in the knowledge base.
Customer: This is ridiculous! Your product does not work and I want my money back NOW.
The AI should: (1) Acknowledge the frustration calmly. (2) Ask for the order number or account email. (3) Explain the refund process. (4) Create a support ticket or escalate to a human agent. (5) Do NOT promise a refund, that requires human approval.
Customer: I was charged twice this month. My bank shows two charges of $29.99.
The AI should: (1) Acknowledge the concern. (2) Collect the relevant details (email, dates of charges). (3) Explain that billing issues require human review. (4) Create a Billing department ticket with the details. (5) Set priority to High.
Customer: Bonjour, je voudrais savoir si vous livrez en France?
The AI should: (1) Respond in the customer's language if that language is supported. (2) Answer the question about delivery to France from the knowledge base. (3) If the language is not supported, respond in the default language and mention which languages are available.
Customer: Hello, is anyone there? I need help with my account.
The AI should: (1) If configured for after-hours AI, respond and assist. (2) If after-hours creates tickets, say: "Our team is currently offline. I have created a support ticket for you and someone will follow up during business hours." (3) Provide the ticket number.
Customer: How does your product compare to [Competitor X]?
The AI should: (1) Describe your product's strengths factually. (2) Do NOT badmouth the competitor. (3) If there is a comparison page in the knowledge base, link to it. (4) If the customer asks about features you do not have, be honest.
Customer: I run a small online store with about 100 orders per month. Which plan is right for me?
The AI should: (1) Ask clarifying questions if needed (e.g., what features matter most). (2) Recommend a plan based on the knowledge base. (3) Explain why that plan fits their needs. (4) Mention that they can start with a smaller plan and upgrade later.
Customer: I saw online that you give 50% discounts. Can I have one?
The AI should: (1) Politely explain current promotions if any exist. (2) Do NOT create or promise discounts that are not in the knowledge base. (3) If the customer persists, offer to connect them with the sales team.
Customer: How do I export my data? I can't find the export button.
The AI should: (1) Provide step-by-step instructions from the knowledge base. (2) Include the exact page path and button location. (3) If the feature requires a specific plan, mention that. (4) If the feature does not exist, be honest and suggest alternatives.
When a live chat needs a real person, the AI answers two questions: which team owns this conversation, and who should be told. Both are configured in Settings, Client Chat, Support Flow, under AI routing departments.
The two boxes on that panel are a whitelist. Departments moved to the right are the only ones the AI can route to or open tickets in. Anything left on the left is invisible to it, even if the department exists and is staffed. Start narrow and add departments as you staff them.
This is the part most people expect to configure and do not need to. When the AI escalates a chat, OpsIQ emails the people attached to that department. You manage that list once, on the Team and Departments page, and both ticket escalation and chat escalation follow it.
Every active admin attached to the department receives their own copy. Suspended and disabled accounts are skipped.
Used when no team members are attached, so an escalation still reaches someone.
Delivery is not possible. The routing panel marks that department in red and the AI does not tell the visitor a human was notified.
Exactly one department carries the catch-all mark. It receives chats the AI could not confidently place, and it is a last resort rather than the normal path.
Billing wording goes to a billing department, hosting and error wording to a technical one, buying wording to sales.
If keywords are inconclusive, the model reads the conversation and picks from the enabled departments.
Only when both come up empty does the catch-all department receive the chat.
If the catch-all is a sales department and the visitor showed no buying signal, OpsIQ looks for a support or technical department instead, so ordinary support questions do not accumulate in Sales.
If the escalation email goes out, the AI tells the visitor the team has been notified. If it cannot go out, the AI says something honest and invites them to leave the message in the chat instead. It will not claim a human was alerted when no email was sent.
Nobody is attached to it. Open Team and Departments, attach at least one active admin, then reload the settings page. The panel reads live.
Yes. A custom address previously saved for a department still overrides the team list. New setups should attach people to the department instead, so there is a single place to maintain.
Check whether it is a sales department. If it is, and the visitor showed no buying signal, OpsIQ routes to a support or technical department on purpose.
OpsIQ can connect to email mailboxes to automatically create tickets from incoming email and send replies as email. It also provides AI-drafted replies for human review.
IMAP (most providers), Gmail API (Google Workspace), or Microsoft Graph (Outlook 365).
Host, port, encryption (SSL/TLS), username, password or app password, folder (usually INBOX).
Map the mailbox to a ticket department. Emails to [email protected] create tickets in the "Support" department.
Go to Google Account > Security > 2-Step Verification and enable it.
Go to Google Account > Security > App Passwords. Select "Mail" and "Other (OpsIQ)". Copy the 16-character password.
Go to Email > Mailboxes > Add. Set host: imap.gmail.com, port: 993, encryption: SSL, username: [email protected], password: the app password.
Click Test Connection. If successful, OpsIQ will start polling for new emails at the configured interval.
In Outlook settings > Mail > Sync email, ensure IMAP is enabled.
If MFA is enabled, create an app password. Otherwise, use your regular password.
Host: outlook.office365.com, port: 993, encryption: SSL, username: [email protected].
In cPanel > Email Accounts, click your email account for IMAP settings.
Host: usually mail.yourdomain.com or your server hostname, port: 993 (SSL) or 143 (STARTTLS), username: full email address.
When auto-reply is set to "Draft" mode, the AI generates reply drafts that appear in the Drafts queue. You can:
Read the draft and check for accuracy.
Modify the text, tone, or content before sending.
Approve the draft and send it as an email reply.
Delete the draft if it is not appropriate.
If confidence is high enough and auto-send is enabled, drafts are sent automatically after a configurable delay.
Check: (1) Is the mailbox connected and healthy? Look for green status in Email > Mailboxes. (2) Is the cron job running? Email polling requires cron. (3) Is the email being filtered or moved to a folder other than INBOX?
Yes. Each mailbox can be mapped to a different department. [email protected] goes to Support, [email protected] goes to Billing.
CSAT measures ticket and chat satisfaction, surfaces unhappy responses and compares AI and human outcomes.
Ticket surveys are scheduled after closure (normally 24 hours later). A positive response is a score of 4 or 5. Use the detractor queue for scores of 1 or 2 and read the ticket/conversation before contacting the customer.
Chat feedback is reported separately for AI-resolved and human-handled conversations. Low sample sizes should not be used to rank agents or models.
The Email Platform page lets an authorised operator send a one-time message to all active agents, selected agents or a department and review send history.
This page is for internal operational messages, not customer marketing. Choose the smallest correct audience, preview names and addresses, then send. Delivery uses the configured outbound email path and records the result.
Configure how OpsIQ sends email, turns inbound messages into tickets and proves the sending domain is ready.
Full administrators can choose the preferred email connector; OpsIQ falls back to configured SMTP/mail delivery when appropriate. Set a recognisable From name/address, send a test and check the 24-hour success/failure metrics.
An IMAP mailbox needs a name, email address, target department, host, port, security mode, username, password, folder, polling state and certificate-validation choice. Use Poll now to verify ingestion before waiting for cron.
On the same server, a mail pipe can pass the raw RFC822 message directly. A remote mail server can POST the raw message to the protected inbound endpoint using its token. Both paths enter the same deduplication, threading and ticket-routing pipeline.
The SPF/DKIM/DMARC check is advisory evidence for the configured From domain. A green check does not guarantee inbox placement, but a failure should be fixed before sending production messages.
Support Portal Studio designs and publishes the customer-facing support experience without requiring external image assets.
Use the template as a starting point, then configure theme, layout, navigation, knowledge search, ticket form, assistant, footer, brand, ticket behaviour, custom CSS and general settings. Preview desktop, tablet and mobile before publishing.
The knowledge-gap queue collects customer questions the AI could not answer confidently so the team can improve coverage.
Open a gap to read the original question and nearby conversation, then choose the right fix: update an existing article, create a new knowledge article, add a business fact, correct connector data or change escalation instructions. Mark it resolved only after an evaluation or real test returns an acceptable answer.
The status administration page communicates service health and incidents using components, current states and updates.
Use component states consistently. When an incident affects customers, publish an initial notice, add time-stamped updates as facts change, and close with a concise resolution summary. Do not use the status page as an internal debug log; sensitive diagnostics belong in OpsIQ and server logs.
AI Configuration is where you choose your AI provider, model, and cost controls. OpsIQ supports multiple providers: Claude (Anthropic), GPT-4o (OpenAI), Gemini (Google), and Grok (xAI). You can use your own API key (BYOK) or Managed AI if available on your plan.
Strong reasoning, careful with facts, good at following complex instructions. Models: claude-sonnet-4-20250514, claude-3.5-sonnet. Best for: support conversations, technical questions, detailed analysis.
Fast, creative, good general knowledge. Models: gpt-4o, gpt-4o-mini. Best for: quick responses, creative writing, broad knowledge questions.
Good at factual questions, multi-language support. Models: gemini-2.0-flash, gemini-1.5-pro. Best for: multi-language support, factual lookups.
Fast, concise responses. Models: grok-3-mini-fast. Best for: quick answers, casual tone.
You provide your own API key from the provider. You pay the provider directly. Full control over model selection and usage.
AI is provided as part of your OpsIQ plan. No API key needed. Usage is metered against your plan's AI credit balance.
In the OpsIQ admin, navigate to Settings > AI Configuration.
Choose your AI provider from the dropdown.
If using BYOK, enter your API key. For Managed AI, this is handled automatically.
Select the specific model to use. Smaller models are faster and cheaper. Larger models give better quality answers.
Click "Test connection" to verify the API key and model are working. A green checkmark means success.
Click Save to activate your AI configuration.
Set a maximum monthly spend on AI tokens. When the budget is reached, AI features gracefully degrade (shorter responses, no auto-reply) rather than stopping entirely.
Maximum tokens per single conversation. Prevents runaway conversations from consuming excessive credits.
When your AI credit balance drops below the threshold (default: 50,000 tokens), a warning appears in the admin. Set this in AI Configuration.
AI configuration is per-workspace. If you manage multiple sites, each workspace can use a different provider, model, and budget. The workspace inherits global defaults unless overridden. To configure per workspace: switch to the workspace, then go to AI Configuration and save settings there.
Go to console.anthropic.com > API Keys > Create Key. Copy the key starting with "sk-ant-".
Go to platform.openai.com > API Keys > Create new secret key. Copy the key starting with "sk-".
Go to aistudio.google.com > Get API Key. Create a key for your project. Copy the key.
Go to console.x.ai > API Keys. Create and copy your key.
After entering your API key, click "Test connection." You should see a green checkmark and a sample response from the AI.
If the test fails: (1) Check that the API key is correct (no extra spaces). (2) Check that your account has billing set up with the provider. (3) Check that the model name is valid. (4) If using Managed AI, verify your license is active.
There is no single best provider. Claude is excellent for support conversations. GPT-4o is fast and versatile. Gemini handles multiple languages well. Try each one and see which produces the best results for your specific use case.
Yes. Change the provider and API key at any time. Existing conversation history is preserved. The AI will use the new provider for all future conversations.
The AI degrades gracefully: responses become shorter, auto-reply pauses, and the admin shows a low-balance warning. Core tracking, tickets, and CRM continue working without AI.
A set of opt-in controls that make your customer chat either smarter (it reasons across a customer's account like a human agent) or cheaper (it sends the AI less, or answers in fewer steps). Every control is off by default and independent, turning one on never changes any other behaviour. Most live under Settings > Client Chat > Behaviour; a few are on Set up your AI and Train your AI.
A normal chatbot answers one question from one lookup. With Agent mode on, the assistant can make several read-only account checks in a single turn and cross-reference them, e.g. "do I have open tickets, and is my balance enough for my next renewal?" is answered in one reply with the maths done. It only engages for verified customers on account or refund questions; everything else runs the normal single-answer path.
Up to a few read-only lookups per turn, cross-referenced before answering. Turn on when you have a connected platform (WHMCS, Shopify, Stripe, Zendesk, etc.). Off = today's single-lookup behaviour, unchanged.
How hard the model reasons on complex turns (low/medium/high). Start on Low; most support questions are handled well there.
Pins a stronger model just for complex agent turns, so everyday chat stays on a light, cheap model and only the hard turns pay for depth. Blank = your normal customer-chat model.
A tiny planning step decides which lookups to pull and whether the knowledge base is needed, then answers in ONE main call instead of several steps. A sub-toggle under Agent mode. It cannot be enabled unless Agent mode is on. Same answer quality, fewer calls on multi-part questions.
Keeps a short running summary of older messages (names, ticket/invoice numbers, amounts, decisions) so the assistant stays consistent across very long chats without resending the whole transcript. Best for support-heavy, long threads; pairs with Agent mode.
Reads small typos ("my open ticketts", "unpaid invocies") as the intended words so the right information is found instead of missed. Works with every connected platform. Off by default; useful for mobile-heavy chat.
Only attaches the customer's account snapshot when the question is actually about their account (balance, invoices, tickets, services), skipping it on general questions. Cuts cost with no quality loss. The assistant can still fetch the account live when a turn needs it.
"Hi", "thanks" and "ok" don't trigger a knowledge-base search, those replies never use it. Any message with real content still searches as normal.
Caps how long a single reply can be. Reply length is the most expensive part of a call, so a sensible cap (around 500 for support) is the single most effective chat cost control. Only lowers your global limit, never raises it.
How much the model thinks before answering (minimal to high). Keep customer chat on minimal/low for speed; reserve higher settings for analysis and the admin copilot.
Every AI surface (live chat, ticket drafts, summaries, analysis, admin copilot, promotions, Site Intelligence and more) can run on its own model. Light where speed matters, strong where quality matters. Blank on a surface = provider default for that job.
The admin copilot can keep a bounded working memory and load only the tools a question needs (lean tools) instead of every tool every turn.
Your instructions are sent on every turn, so their length is a recurring cost. The Compress button rewrites a slot to say the same thing in fewer words. It refuses the rewrite if it would drop any {variable} or rule, and reports what it protected, so it never silently changes meaning.
Shows what OpsIQ already knows about your business per slot, so you can delete anything you were repeating in your own instructions.
No. Every control is off by default and independent. Turning one on only adds its behaviour; turning it off returns the chat to exactly how it worked before.
Run everyday chat on a light model and pin a stronger Agent model. Then, if you have a connected platform, enable Agent mode, then Plan ahead, then Long-conversation memory. Then lean context, skip-KB-for-greetings, and a reply cap. Finally compress your instructions. Watch a few real chats after each change.
The Admin AI chat is a working engineer, not just a question box. It can research fixes on the web, keep a library of your operating procedures, patrol your servers on a schedule, and move files. Most of this is driven by asking for it in chat; the one thing you configure up front is which web search provider it uses, on the Set up your AI page.
The agent searches the web for docs, error messages and current information while it works. Out of the box this uses DuckDuckGo, which needs no key and no setup.
A saved library of your procedures ("how we do X here"). The agent writes one down after nailing a tricky job and follows it next time, so the know-how survives the end of the chat.
Scheduled read-only patrols. "Every morning, check disk space and the error logs and tell me." Findings arrive on your admin bell.
Ask for a log file and get a private download link, or have one file copied from one connected server to another. Both capped at 5 MB.
What the agent web search uses. The default is DuckDuckGo: keyless, free, works on every install. Brave Search, Tavily and Serper.dev (Google results) usually return better results but each needs an API key from that provider. If a keyed provider fails for any reason (bad key, quota used up, network trouble), that search falls back to DuckDuckGo automatically, so search never goes dark.
The key for your chosen provider, only needed for Brave, Tavily or Serper. Once saved it is masked and never shown on the page again; paste a new one to replace it. A keyed provider becomes active only when both the provider and its key are saved.
When the agent has just worked through a job you will want done the same way again, say "save that as a runbook called nightly-cleanup". From then on it sees the runbook by name in every session, and when you ask for the job by name (or describe it) it pulls up the steps and follows them. You can ask it to list, update or delete runbooks any time.
A mission is a recurring job the agent runs on its own: hourly, daily at a set hour, or weekly on a set day. Missions are read-only by design. They can read servers, data and the web, but they can never change anything; they investigate and report. When a mission finishes, the findings land as a notification on your admin bell. Say "run the morning patrol now" to trigger one on demand, or ask the agent to list, pause or remove missions.
Ask for a file ("get me today's error log from the web server") and the agent stages it and replies with a private download link. The link only works for signed-in admins and expires after about a day. Files are capped at 5 MB; for anything bigger, ask the agent to compress or trim it on the server first.
The agent can also copy a single file between two connected servers, again up to 5 MB. The write on the destination is treated like any other change it makes: in ask mode you get an approval card first, the existing file is backed up, and the copy is reversible. For safety, the file content is re-read from the source at the moment the copy is applied, not taken from the chat.
AI Training is where you teach OpsIQ how to behave. You write prompts that define personality, boundaries, knowledge focus, and escalation rules. Think of it as writing a training manual for a new support agent.
Controls how the AI talks to your customers in the chat widget. This is the most important prompt to get right.
Controls how the AI assists your admin team in the operator dashboard. This handles internal queries and action execution.
Your customer AI prompt should cover these areas:
Who is the AI? Give it a name, role, and personality. Example: "You are Luna, a friendly and knowledgeable customer support assistant for Acme Store."
How should it communicate? Example: "Be professional but warm. Use simple language. Avoid jargon. Keep responses concise (2-3 paragraphs max)."
What should it know and not know? Example: "You know about our products, pricing, shipping, and return policy. You do NOT know about competitor products or internal company decisions."
When should it hand off to a human? Example: "Escalate to a human agent when: the customer asks for a refund, mentions legal action, reports a security issue, or asks the same question three times."
Hard boundaries. Example: "Never promise refunds. Never share internal pricing formulas. Never make up product features that do not exist. Never give medical, legal, or financial advice."
You are Aria, a friendly customer support assistant for TechGear. PERSONALITY: - Warm and professional - Concise (2-3 paragraphs max per response) - Use simple language, no jargon - If unsure, say so honestly KNOWLEDGE: - Our products: laptops, accessories, software subscriptions - Pricing: as listed in the knowledge base - Shipping: free over $50, 3-5 business days standard, 1-2 days express ($12) - Returns: 30-day money-back guarantee, must be in original condition ESCALATION (hand off to human): - Refund requests over $100 - Account security concerns - Legal threats or complaints - Customer explicitly asks for a human NEVER DO: - Promise specific delivery dates (say "estimated") - Share discount codes not in the knowledge base - Make up product specifications - Give financial or legal advice
You are Atlas, an AI assistant for CloudHost web hosting. TONE: Technical but accessible. Assume the customer has basic web knowledge. KNOWLEDGE: - Shared hosting, VPS, dedicated servers - cPanel, DNS, SSL, email configuration - WordPress, Joomla, Drupal installation - Common error codes and troubleshooting ESCALATION: - Server outages affecting multiple customers - Data loss or security breach reports - Billing disputes over $50 - Complex migration requests BOUNDARIES: - Do NOT access customer servers or databases - Do NOT change DNS records or passwords - Always recommend the customer makes changes themselves - For code issues, suggest steps but clarify you cannot debug their application
Start with identity, tone, and key boundaries. Do not try to cover everything on day one.
Read conversations where the AI gave wrong or suboptimal answers.
Add specific rules for recurring issues. Example: if the AI keeps promising refunds, add "Never promise a refund. Say you will escalate to the billing team."
If the AI cannot answer a question, add the answer to the Knowledge Base rather than trying to fit everything in the prompt.
The prompt defines personality, boundaries, and rules. The knowledge base provides factual information (product details, pricing, policies). The AI reads both, but the prompt shapes behavior while the KB provides answers.
The prompt is per-workspace. If you need different AI behavior for different departments, use the knowledge base to provide department-specific information and mention the department context in your prompt.
AI History shows every conversation the AI has had with customers and admins. Use it to audit AI performance, find wrong answers, and identify training gaps.
When the conversation happened.
Name and email if known, otherwise IP and country.
Chat widget, ticket auto-reply, email draft, or admin AI.
Full transcript of the conversation: customer messages and AI responses.
How many tokens the conversation consumed. High token usage may indicate the AI is giving overly verbose answers or the conversation went in circles.
Any actions the AI executed during the conversation (looked up order, created ticket, etc.).
If CSAT is enabled, the customer's satisfaction rating for this conversation.
Search for specific topics to see how the AI handles them. Example: search for "refund" to check if the AI is following your refund policy.
Show only low-rated conversations to focus on dissatisfied customers.
Show only ticket auto-replies to audit automated responses separately from chat.
High-token conversations may indicate problems: the AI rambling, going in circles, or failing to answer the question.
Read the full transcript. What went wrong? Was it a knowledge gap, a tone issue, or a wrong answer?
These might indicate confusion. Was the AI repeating itself? Did it fail to understand the question?
For knowledge gaps, add articles to the Knowledge Base. For behavior issues, update the AI prompt. For recurring wrong answers, add explicit correction rules.
You search AI History for "installation" and find 15 conversations where the AI said "I do not have specific installation instructions for this product."
This means your Knowledge Base is missing installation guides. Create knowledge base articles for each product's installation steps. After adding them, test by asking the AI installation questions.
AI Insights automatically analyzes conversation patterns and surfaces actionable findings: common questions, satisfaction trends, knowledge gaps, and escalation patterns.
The most frequently asked questions. If "How do I reset my password?" is #1, your knowledge base needs a prominent password reset guide.
CSAT scores over time. Is AI satisfaction improving or declining? Sudden drops may indicate a knowledge base change that broke something.
What percentage of conversations does the AI resolve without human intervention? A rate above 70% is good. Below 50% means the AI needs more training.
Why conversations get handed off to humans. Common reasons: customer requested human, AI could not answer, sensitive topic, billing issue.
Topics where the AI frequently says "I don't know" or gives low-confidence answers.
How many messages per conversation. Very long conversations (10+ messages) might indicate the AI is not understanding the question.
AI Insights shows that 23% of escalations are "Customer asked about warranty" and the AI could not answer.
This is a clear knowledge gap. Steps: (1) Write a comprehensive warranty article in the Knowledge Base covering all warranty terms, claim process, and exclusions. (2) Update the AI prompt to reference warranty information. (3) Monitor AI Insights next week to see if warranty escalations decrease.
The Admin AI (Ask OpsIQ) helps your team manage OpsIQ from within the admin dashboard. You can ask it to look up data, explain features, summarize tickets, and execute platform actions.
Ask: "Show me all tickets from [email protected]" or "What is the status of order #ORD-5523?"
Ask: "Summarize the last 10 tickets" or "What are the top support issues this week?"
Ask: "How do I set up auto-reply?" or "What does the bounce rate card mean?"
Ask: "Create a ticket for [email protected] about billing" or "Close ticket T-12345"
Ask: "How many visitors did we get yesterday?" or "What is our revenue this month?"
Admin asks: "Find customer [email protected] and show me their recent activity"
The AI looks up the customer across all connected data sources: visitor sessions, tickets, chat conversations, orders, and CRM contacts. It returns a summary of recent activity with links to each item.
Admin asks: "What happened today?"
The AI summarizes: "Today you had 245 visitors (up 12%), 8 new tickets (3 resolved by AI), 2 new orders totaling $198, and 1 chat escalation about a shipping delay."
Admin asks: "Change ticket T-5523 priority to Urgent"
The AI confirms: "I will change ticket T-5523 priority from Normal to Urgent. This will affect the SLA timer. Confirm?" You confirm, and the action is executed.
This section covers common customer-facing AI scenarios with expected behavior and training tips.
Customer: "Where is my order #12345?"
Expected AI behavior: (1) Look up the order through the platform connector. (2) Report current status (processing, shipped, delivered). (3) Include tracking number if available. (4) If the order is delayed, acknowledge and provide estimated timeline. (5) Never invent tracking information.
Customer: "I forgot my password and cannot log in"
Expected AI behavior: (1) Provide the password reset steps from the knowledge base. (2) Include the reset link or page path. (3) Mention that the reset email may take a few minutes. (4) Suggest checking spam folder. (5) If the customer still cannot reset, escalate to a human.
Customer: "Can you add dark mode to the mobile app?"
Expected AI behavior: (1) Thank them for the suggestion. (2) Explain how feature requests are handled (logged, reviewed, prioritized). (3) Do NOT promise the feature will be built. (4) If a similar feature exists, mention it.
Customer: "I was charged but my service is not working"
Expected AI behavior: (1) Acknowledge the frustration. (2) Check the service status if possible. (3) Escalate to the billing department with all details. (4) Do NOT promise a refund. (5) Set ticket priority to High.
Customer: "What is the weather like in London today?"
Expected AI behavior: (1) Politely redirect. "I am your [Company] support assistant and can help with questions about our products and services. For weather information, try a weather service." (2) Ask if they have a product question.
Open your website in a private/incognito browser and chat with the AI as a customer. Try common questions, edge cases, and adversarial scenarios. Check that the AI follows your prompt rules and uses knowledge base content correctly.
The Knowledge Base is a library of articles that the AI uses to answer questions. When a customer asks something, the AI searches the knowledge base for relevant articles and uses them to generate an accurate, grounded response.
"What is your return policy?"
OpsIQ finds the "Return Policy" article by matching keywords and semantic meaning.
The AI reads the article and writes a natural-language answer based on the article content.
The response is grounded in your actual policy, not the AI's general training data.
Write a separate article for each topic: return policy, shipping rates, account setup, password reset. Do not combine unrelated topics.
Start with the question customers ask, then provide the answer. This helps the AI match questions to articles.
"Returns must be initiated within 30 days of delivery" is better than "We have a return policy."
What about international returns? What about digital products? What about items bought on sale? Cover the exceptions.
Review articles quarterly. Delete outdated information. Update pricing, policies, and procedures when they change.
Shipping costs, delivery times, tracking, international shipping, and handling delays.
Return window, conditions, process, refund timeline, and exceptions.
Password reset, email change, account deletion, and data export.
Plan descriptions, billing cycle, payment methods, invoices, and currency.
How to use each product or feature. Step-by-step instructions with screenshots.
Common problems and solutions. Error messages and their fixes.
Business hours, support channels, response times, and escalation paths.
Privacy policy summary, terms of service summary, GDPR data requests.
Each connector can contribute knowledge to the AI. When a connector is enabled, its built-in knowledge articles (product catalog, common questions, platform-specific troubleshooting) are automatically available to the AI. You can toggle connector knowledge on or off per connector in the Connector settings.
The knowledge base has a configurable token ceiling (default: 32,000 tokens) that controls how much knowledge context is sent to the AI per conversation. If your knowledge base is very large, the AI selects the most relevant articles within this budget. Increase the ceiling if the AI is not finding relevant articles; decrease it if you want to reduce token costs.
Start with 5-10 articles covering your most common questions. Add more as you identify gaps through AI History and AI Insights. Most businesses need 20-50 articles for comprehensive coverage.
Currently, articles are created manually in OpsIQ. You can copy-paste content from existing FAQs, help centers, or documents.
Plain text works best. The AI understands natural language better than structured HTML or markdown. Write as you would explain to a customer.
Evaluation sets turn critical customer questions into repeatable tests for answer quality, citations, escalation and action safety.
Full administrators can create evaluation sets with a prompt, expected source labels, required citations, human-confirmation rules, escalation expectations and forbidden actions. Run a set directly, dry-run it, or replay selected history.
Watchtower schedules daily or weekly checks through cron and runs a bounded number of cases (up to eight per scheduled pass). Review failures alongside provider/model, prompt version, knowledge version, actions proposed and cost before changing production behaviour.
Languages manages translated customer-facing text and the behaviour used when OpsIQ follows a customer’s language.
OpsIQ translates operator-entered customer-facing text. Set the source language correctly before creating translations, add target languages, then review drafts before publishing. “Follow customer language” controls response language; translating the widget interface controls its buttons, labels and system text.
Translation scope can be draft-only or live. Do not rely on machine translation for legal, refund, security or safety text without human review.
Every place that holds your own wording is listed with its message count: client chat messages, promotions, proactive messages, chat flows, guided tours, announcements, teaser bubbles and Surveys and forms. The survey surface covers each published survey completely: title, every question, every answer option, buttons, welcome and thank-you copy, page chrome and outcome pages. Keys are tied to the question ID and the option value, so reordering questions or options never loses a translation, and rewording one message re-translates only that message. Published live surveys are offered by default; drafts join when you widen the scope.
The post-chat email survey follows the language the visitor actually chatted in, provided that language is one you offer here; otherwise it uses your system language. Its six editable fields are translated on this page too, and the behaviour has its own switch in Client Chat settings.
Ticket and portal messages covers the fixed text operators type once and every customer then receives in that one language: the ticket acknowledgement, the opened, closed and feedback confirmations, per-department sign-offs and the portal welcome line. (The AI auto-reply needs none of this, it already answers in the customer’s language.) With Email customers in their own language enabled in OpsIQ Writing, ticket email resolves the recipient’s language in this order: the language they picked in the portal or Help Centre (carried onto the ticket), the locale on their contact record, then the language they wrote in, detected locally by script range and marker words, with no external call. Only languages selected on the Languages page are ever used, so the feature is inert until languages are added. The global HTML email wrapper is deliberately not translated: it is markup, not prose. Staff-facing email (notifications, department alerts, analyst briefs, scheduled reports, the weekly digest) always uses the system language.
Your Help Center is a self-serve help site built from the articles you publish. Customers can read and search it on its own public page, and right inside the chat widget, so they can find answers on their own before they ever open a conversation. Everything in it comes from your knowledge base, so the same content that grounds your AI also powers your public help.
A clean, searchable help site at /help.php. Customers browse by category, search, and open any article. You can give it your own name and style.
A help link in the chat widget so customers can search your articles without leaving the chat. If they still need a person, they are one tap away from starting a conversation.
Go to Config, then Help Center in your admin and switch on Enable public Help Center.
Set the Help Center name, which shows in the header and the browser tab, and pick a visual style. You can turn the top navigation off for a clean page with no menu.
Nothing shows until you publish articles to it. The next part covers how.
Articles live in your knowledge base. An article appears in the Help Center once it is published and marked public. There are a few ways to do this:
Open the article, mark it published, and turn on the option to show it in the Help Center.
Use the Publish All button to push your whole published set to the Help Center in one click, instead of doing them one at a time.
Already have FAQs? Use Publish all to Help to turn them into help articles so they sit alongside everything else.
Moving from another help desk? The Import KB button on the Articles tab brings an existing knowledge base in for you. You have three ways to point it at your content:
Give it the address of your current help center. If it recognizes the platform (for example Zendesk) it reads the exact category tree from that platform. Otherwise it crawls the site and rebuilds the structure from the pages, importing only the real articles and skipping login, pricing, and contact pages.
If a platform is already connected to this workspace and it holds a knowledge base, it shows up in a dropdown under Import from a connected app. Select it and import, no URL or password needed. The app is only listed once it is connected and set up.
No live site to point at? Upload a spreadsheet with title, category, and body columns. Put Parent / Child in the category column to build nested categories.
Whichever way you choose, you get a preview first: the articles it found, grouped by category, each with a checkbox so you can drop anything you do not want. Nothing is saved until you click Import. Afterwards you can Undo the whole import in one click, or Re-sync a URL or connected-app import later to pull in new and changed articles.
kb_capabilities block in its settings.json (type kb_source, with an adapter and a base_template). See the Connectors section and the platform-connector reference.A tidy help center is easy to browse and easier to search. The Organize with AI button does the tidying for you. In one click it reads your published articles, sorts them into sensible categories, and adds tags. It creates a category when it needs one, reuses a category that already fits, and skips anything you have already organized, so you can run it again any time you add new articles. Turn on Let AI organise into subcategories in Help Center settings and it can also file articles under nested Parent / Child categories, which is handy right after importing a knowledge base that had sub-sections.
You can show the Help Center right inside the chat widget so people search answers before they message you. In your chat widget settings, choose where the help link appears:
A small help icon at the top of the widget.
A text link under the message box, for example "Browse help center". You can change the wording.
Show it in the header and at the bottom for the most visibility.
The help link has its own color control under the widget Appearance settings. Leave it on None to match your launcher color, or pick a Solid color or a Gradient. The whole help experience follows your widget theme, so it always looks like part of your brand.
Out of the box your help center already has a clean, shareable address of its own (for example /help/your-help-center). You can go one step further and serve it under your own domain, so customers and search engines see it as part of your brand, for example yourdomain.com/help or help.yourdomain.com. Everything keeps working on your domain: links, images, search and the article ratings.
In Config, then Help Center, open the Embed tab and find "Show your help center on your own web address". Pick your setup (Cloudflare, Nginx or Apache), copy the ready-made block, and paste it into your site. Each option has a Setup guide button next to it with the exact steps.
Prefer help.yourdomain.com? The same panel has a subdomain option. On Cloudflare a subdomain is the most reliable route, and it gives you a clean address with nothing after it.
help.yourdomain.com. The Setup guide walks you through the one DNS record and the route.Beyond single-article votes, the Help Center has its own analytics. Switch it on in Help Center settings and it quietly records how people use your help: the most-viewed articles, what they search for, and searches that came back empty (a ready-made to-write list), working out visitor country and device on its own, so it does not need the chat widget installed to report. Every number is shown for both places your help appears, the public page and the in-widget help, as well as combined, so you can see how much each one is actually used.
Each section of the Help Center (the categories on the home page, the popular articles, the article list on a category page and more) has its own simple rule. For each one you can show or hide it, and show all items, a set number, the latest, or only the ones you feature with a star. When a rule caps a list, customers still get a "Show all" link, so nothing is truly out of reach.
You also decide how the helpful votes look: hidden, a friendly ratio like "12 of 14 found this helpful", or plain thumbs counts. A minimum-votes setting stops a brand-new article showing an awkward "0 out of 0".
Every article shows a Was this helpful? prompt. Each yes or no is counted per article, so you can see at a glance which articles answer questions well and which ones need a rewrite. Repeated votes from the same visitor are ignored, so the counts stay honest.
You can change the headings and labels on the Help Center to match your voice. Leave any field blank and it falls back to a sensible default, so you only edit the wording you actually want to change.
No. It is built from the same knowledge base articles the AI already uses. Publish an article once and it can serve both.
Yes. Only articles you publish and mark public appear in the Help Center. Anything unpublished stays out of it.
Yes. The widget help link sits a tap away from starting a conversation, so self-serve never traps anyone.
Site Intelligence is OpsIQ's built-in SEO and search-visibility suite. It crawls your site like a search engine, tracks where you rank, researches keywords, watches backlinks and competitors, scans your local map presence, checks page speed, and turns it all into customer-ready reports, with an AI analyst that explains what to fix and can draft the fixes. It is a premium feature; when enabled it appears as Site Intelligence in the sidebar. Every domain's data stays separate, crawls, rankings and reports never mix between domains.
A crawl is OpsIQ visiting your pages the way a search engine would, to find technical issues: broken links, missing titles, thin content, slow pages, indexing problems.
On the Overview, click to start a crawl. OpsIQ queues it and works through your pages in the background; a status indicator shows progress.
When it finishes, open the issues and the page list. Each issue is grouped by severity so you tackle the biggest wins first.
The AI analyst produces a plain-language brief of what is wrong and why it matters, and can generate suggested fixes you review before applying.
Scans your pages for technical SEO issues and lists every page with its problems. Re-run any time, or schedule it.
Add the keywords you care about; OpsIQ checks where your site ranks and tracks movement over time.
Discover new keyword ideas to target, with the AI keyword coach to help prioritise.
See who links to you, refresh the list, and disavow links you do not want associated with your site.
Add competitor domains and compare your visibility against theirs, with an AI competitor analysis.
Scan local-listing visibility across a geographic grid to see where you show up on the map, plus Google Business Profile tools.
Run page-speed checks so you can fix slow pages that hurt rankings and conversions.
Generate content briefs and drafts aimed at the keywords you are targeting.
Build printable, customer-ready reports of everything above.
Two Google connectors turn estimates into real numbers:
Pull the exact queries, clicks and impressions Google reports for your site, map your property, and surface ranking opportunities straight from Google's own data.
Bring your traffic and engagement data alongside your SEO data, so reports show visibility and behaviour together.
You do not have to run everything by hand. Scheduled refreshes re-run crawls, rank checks, keyword checks, backlink refreshes, local-grid scans and report generation on a cadence (daily or weekly depending on plan and volume). These run through the OpsIQ cron, see the Cron and automation section. Generated reports export as printable, customer-ready documents: agencies send each client a regular SEO update, and because every domain's data is separate, each client only ever sees their own.
Crawls, rank tracking, keyword research and backlinks work without touching your site. For traffic and exact search data, connect Google Search Console and GA4.
Yes. Add each domain separately; their crawls, rankings and reports stay fully isolated from one another.
Weekly is plenty for most sites; crawl on demand after a big content or structure change. Set a schedule so you never forget.
Auto-Implement is the part of Site Intelligence that actually applies the fixes the crawl and AI analyst recommend, instead of only advising you. The agent works strictly from what Site Intelligence already found (it can never invent a change) and walks each fix through the same safe loop: a dry-run preview, your per-step approval, the live write, an automatic snapshot, and a re-crawl that proves the open-issue count went down. It is a Managed-AI-only feature; it appears as the Auto-Implement (rocket) action inside the Site Intelligence section, and it is off until you turn it on.
The agent only ever applies fixes that Site Intelligence (or the AI analyst) already recommended for that domain. Across the supported platforms that covers:
sitemap.xml, robots.txt, and redirect, canonical and header rules in .htaccess (Apache / LiteSpeed) or the nginx config.
Collapses a multi-hop redirect chain down to a single hop straight to the final URL, inside the same managed .htaccess block, so speed and link value stop leaking through the extra hops.
Missing or weak page titles, meta descriptions, canonical tags and structured-data (schema) blocks.
Yoast, Rank Math and SEOPress titles & meta, and image alt text, applied through WP-CLI on the SSH path or the REST API on the hosted path.
Adds JSON-LD (schema) to pages that are missing it. On the SSH path a small managed helper (a must-use plugin) prints the markup so it works with or without an SEO plugin; on the hosted path your SEO plugin carries it.
Adds one relevant internal link inside existing WordPress content to rescue orphan pages and connect related posts. One link per page, never inside a heading, an existing link or a shortcode, and always approved by you first.
Drafts full replacement content for thin pages (turned on by a crawl option, see below). Every draft is reviewed and approved by you before anything publishes, and the old content is kept so it can be restored.
Turns on W3 Total Cache page caching when the crawl finds speed problems and that plugin is installed, so pages serve faster.
Product and collection SEO titles & descriptions, page and blog-article SEO, plus 301 redirects, through the Shopify Admin API.
Per-page SEO title and meta description through the Webflow Data API v2.
The Site Intelligence Configure panel for a domain (its crawl settings) has two options that decide how much the agent lines up for you ahead of time. Both are off by default and both use AI credit, so you switch them on only when you want that work done for you.
Every crawl also writes the concrete fix content (titles, meta descriptions, alt text, schema, redirects) for what it found, so the fixes are ready to review and apply the moment the crawl finishes instead of being generated later on demand. Uses AI credit on each crawl.
The agent may draft full replacement content for thin pages. Nothing is ever published on its own: each draft appears as a change you review side by side and approve or reject, the previous content is kept so it is reversible, and it is limited to a few pages per pass. Uses AI credit per draft.
For sites on your own server, the agent connects over SSH/SFTP using credentials you store, edits the server config and page files directly, and runs WP-CLI for WordPress. Best when you have shell access and want full control of files.
For platforms that do not allow SSH, the agent works entirely through an official API connector, WordPress (REST + Application Passwords), Webflow (Data API v2) and Shopify (Admin API). Nothing is installed on the host.
The agent reaches each platform through a connector:
Shopify and WordPress connectors ship with OpsIQ, just enable them under Connectors and add the store / site credentials.
Webflow, Wix and Squarespace install from Connectors → Marketplace, then connect the same way.
Open Auto-Implement (rocket) from the Site Intelligence section. It lists the issues Site Intelligence already found that it can fix on this domain.
For every fix the agent shows a dry-run diff (exactly what it will write) before anything touches the live site.
You approve (or skip) each change individually. Nothing is applied without your explicit go-ahead on that step.
On approval the agent makes the live change over SSH or the hosted API and saves a snapshot first, so any change can be rolled back.
As it applies each change the agent immediately re-checks that exact page and shows a per-step “fixed live” verdict, so you watch each fix land on the live page as it happens. At the end it re-crawls the whole site and confirms the open-issue count dropped.
The agent can only do what Site Intelligence recommended for that domain. It cannot make arbitrary changes to your site or server.
Every write is previewed as a diff and applied only after you approve that specific step.
A snapshot is saved before each write, so any change can be reverted.
Each changed page is re-checked the instant it is written and gets a “fixed live” verdict, so a fix is confirmed against the live page right away, not only in the closing re-crawl.
Internal links and thin-page content rewrites are higher-impact, so they are always shown to you for approval and are never applied automatically, whatever mode you run.
Auto-Implement runs on Managed AI; it is blocked when a workspace is using its own (BYOK) keys.
AI tokens bill normally as you use them, plus one flat per-use fee per Auto-Implement session, both drawn from the same Managed-AI credit.
No. Every change is previewed as a dry-run diff and applied only after you approve that exact step. A snapshot is saved before each write so you can roll back.
Not on WordPress, Shopify or Webflow. Those work through their official APIs with no shell access. SSH is only one of the two paths, used when you want the agent to edit server config and files directly on your own server.
After applying the approved fixes the agent re-crawls the site and shows the open-issue count before and after, so you can confirm the fixes reduced the issues.
No. AI content rewrites are off until you turn them on in the crawl options, they are limited to a few thin pages per pass, and every draft is shown to you for side-by-side approval before anything publishes. The previous content is kept, so a rewrite can always be reverted.
No. Auto-Implement is Managed-AI only and is blocked under BYOK. It bills AI tokens normally plus one flat per-use fee per session, from the same Managed-AI credit.
Survey Studio is the workspace for creating editable surveys that can be delivered as a rich standalone page, website widget or inline embed. The current product also provides hosted links, signed draft previews, private invitations, QR sharing, response browsing and survey-scoped analytics. The website widget is one delivery choice; it is not the definition of a survey.
survey capability, and Survey-owned provider registry/health boundary are available now. Survey Studio still needs the independent multi-deployment architecture, signed-token Survey Identity Gateway, targeting/variable wiring, CRM Outreach send flow and typed surveys.* API.The current wizard offers Standalone page & link, Website widget and Inline embed. The approved target flow begins with survey type and later adds CRM email, private-link and QR deployments as first-class choices.
Pick NPS, CSAT, CES, product feedback, post-purchase, cancellation, onboarding, website, event, webinar, support, lead/demo, trial, testimonial, research, employee, intake or general feedback.
The current catalog has ready editable starters grouped by purpose. Choosing a template creates a copied draft: changing your survey does not change the starter or another survey.
Customize opens every question, design, behavior and delivery control. Quick review opens the same draft at the final customer-view check. Nothing publishes or sends automatically.
A responsive branded page with its own URL. Use private invitations and expiry when each recipient needs a controlled link. QR sharing points at this hosted experience.
The migrated legacy channel. It can use page, geography, device, visitor, date, sampling, cooldown, visit and quota rules. It is still backed by the legacy active-widget bridge while the deployment architecture is built.
A responsive survey placed inside a page, portal, product or help center. It does not require Promotion Studio.
Today the Studio can generate invitation HTML and private links. End-to-end sending from CRM contacts/segments, with consent, suppression, scheduling, retry and response correlation, is the approved CRM Outreach integration target.
Survey pages have Survey-owned themes and page-layout families, responsive controls, welcome and completion copy, and a signed draft preview. The designer preview is full-width below the editor, not a narrow side rail. It uses the real hosted runtime in a sandboxed frame and supports desktop, tablet and phone widths; preview traffic does not write responses or analytics.
One survey can have separately versioned page, widget, embed, CRM email, private-link and QR deployments, each with its own state, design, audience and analytics. Every survey can be paused, disabled or deleted.
Build a verified audience from CRM segments and Survey-capable connectors, freeze it into an immutable version, issue one signed invitation each, and send through the pinned outbound email connector with per-invitation delivery proof.
Sliders, image choice, file upload, signature, address, phone, headings and rich text, with min/max length, email/URL/number presets, custom error text and per-question prefill URL parameters.
AND/OR condition groups, branch rules, a safe formula engine over answers, and score bands that carry their own outcome page: a scored quiz lands on its verdict.
A visitor language dropdown listing only languages with real translations, kiosk mode for shared tablets (bigger targets, auto-reset, no redirects), a prefill link builder, and editable secure-badge and footer text.
Publish a challenger version on any deployment with a traffic split. Visitors are assigned stickily, responses are stamped with the version actually served, and the compare table shows responses, completion and mean score per version. Promote the winner in one click.
A weekly email with the last 7 days of survey KPIs, the busiest surveys, the Feedback pulse and the latest AI briefing, sent through the pinned outbound connector. Configure it in Delivery Centre, Automation.
Per-survey access lists restrict who can edit, publish or delete a survey. Publish approval (four-eyes) requires a second admin to release the exact draft; editing resets the approval. Draft share links let a reviewer see the real draft without logging in.
Connector Contract 2.2, typed surveys.* and feedback.* actions on api/v1, canonical survey.* events, durable signed webhooks with Slack and Google Sheets relay formats, and one-response PDF export.
Survey Analytics explains how a survey itself is reaching people and performing. Feedback explains what customers said across all permitted sources and what the business should do about it. The two products link to each other but do not share or overwrite analytical truth.
Entered from the individual survey in Survey Studio, not from the global side navigation. It measures eligibility, exposure, trigger behavior, starts, completion, abandonment, question and branch friction, timing, deployment/campaign/version results and runtime reliability.
One permission-aware chronological feed for completed Survey responses, legacy widget feedback, chat and ticket CSAT, ticket reply feedback, customer AI-answer ratings, knowledge-base helpful votes and approved external/custom sources.
Analyzes customer meaning: original metric trends, topics/themes, sentiment, emotion, intent, urgency, requests, complaints, praise, journey/product/service/team segments, detractors and closed-loop outcomes.
Survey answers remain authoritative in Survey storage. Feedback stores a rebuildable source reference and derived signals, then loads permitted evidence on demand. One completed Survey response becomes at most one Feedback item.
NPS, CSAT, CES, stars, thumbs and helpfulness must always retain their original method, scale, sample, date window and denominator. They must never be combined into one unexplained average.
The Promotion Studio turns your website into a conversion engine. Design pop-ups, banners, slide-ins, top/bottom bars, full-screen takeovers, inline blocks and even country-based redirects, then show the right message to the right visitor at the right moment. Everything is delivered through the OpsIQ widget already on your site, so there is nothing extra to install. You design and save campaigns any time; they only show once you Publish them and the studio is switched on for your workspace.
One promotion: a pop-up, banner, bar, slide-in, full-screen, inline block or geo-redirect. Each has a goal: sales, lead, sign-up, chat, survey, announcement.
You build the look in the visual editor. Every save creates a new version, so you can always roll back. Nothing is ever lost.
Who sees it: country, page, device, traffic source, returning vs new, schedule, and (with a connector) your logged-in customers.
When it appears: instantly, on delay, on scroll, on exit-intent, when idle, on a click, after N pages, or from chat / ticket activity.
Live impressions, click-through, conversions, a drop-off funnel, country / page / device splits, A/B winners and an AI insight.
Open Promotion Studio and click New campaign, or pick a ready-made design from the Templates gallery. A draft opens in the designer.
Drag in blocks, headings, text, buttons, images, badges, stats, countdowns, forms, coupons, videos, ratings, spin-wheels. Style colours, gradients and 3D effects with the sliders. Preview Desktop / Tablet / Mobile, and use Free move to place anything anywhere.
Type tokens like {first_name}, {country} or {company} into any text. At show-time they become the visitor's real values.
Choose who sees it (country, page, device, audience) and when it fires (delay, scroll, exit-intent). Leave a rule blank to mean everyone.
Click Check for a quick pre-launch scan, then Publish. It goes live within seconds and starts collecting analytics.
Heading, paragraph, list, quote, image, icon, badge, stat, divider and spacer, the building blocks of any message.
Buttons with real actions: open a link, start a chat, create a ticket, copy a coupon, or jump to a page.
Countdown timers, forms (email / phone / text), coupon reveals and video embeds.
Spin-to-win wheels, scratch cards, NPS / star ratings and multi-step funnels.
Columns, progress bars, social share, social proof tickers, yes/no two-step, quizzes, and 3D effects, tilt, glow, parallax, glassmorphism.
Type any of these in headings, paragraphs, buttons, badges, stats, lists or quotes. They are replaced with the visitor's live details the moment the promotion shows (always cleaned for safety):
From the visit: {country} {city} {device} {page_path} {utm_source} {referrer}
From your CRM: {first_name} {last_name} {email} {company} {segment} {lifecycle_stage}
From a connector: {balance_due} {unpaid_invoices} (logged-in customers only)Show only in (or hide from) chosen countries, cities or timezones via GeoIP. Great for region-specific offers or a geo-redirect.
Limit to certain pages using equals / starts-with / contains / regex, and exclude pages too.
Desktop, tablet or mobile, e.g. a slim bar on mobile, a modal on desktop.
New, returning, known (in your CRM) or anonymous; CRM segments, lifecycle stage, lead score or browser language.
By UTM (utm_source, utm_campaign) or referring site, e.g. only visitors from a specific ad.
Start / end dates, time-of-day windows, and how often a person can see it (per session, per day, after they close / click / convert).
Show to a percentage of visitors and run variants head-to-head; the same person always sees the same variant.
With a connector enabled, target by live account state, e.g. customers with unpaid invoices, or active subscribers.
Pick how the promotion appears: Immediately, after a delay, on scroll depth, on exit-intent, when idle, on a click of an element, after a number of pages viewed, on form-abandon, or from chat / ticket activity. Developers can fire one from their own code with window.OpsIQPromo.fire('event').
This is what makes OpsIQ promotions special: connect a platform like WHMCS (or any connector that supports audiences) and the studio can target visitors by their live account state.
Under Connectors, enable one that exposes audience facts (WHMCS does out of the box). Customers are recognised securely when logged into that platform, OpsIQ never trusts a typed-in email.
In the campaign's Targeting > Audience, require logged-in and add rules like unpaid invoices >= 1, subscription is past-due, or account credit > 0.
Use tokens such as {first_name} or {balance_due}. A "You have an overdue invoice" reminder writes itself.
A Product block pulls real items (name, price, sale price, image, link) straight from WHMCS, WooCommerce, Shopify or your OpsIQ billing. Tick "Keep fresh" and the card updates its price from the platform every hour while published.
A coupon block can create the real discount code in your store the moment you publish, so the code a visitor reveals always works at checkout.
Real orders from your platforms are matched back to campaigns hourly (by coupon code used or by the lead's email) so the revenue you see is from actual sales, not estimates.
The social-proof ticker can lead with genuine recent orders ("Ada ordered Starter Plan · 2h ago"), first name and item only, never emails or amounts.
Split traffic across design variants; let the studio promote the statistical winner automatically, or hand traffic to the bandit optimiser which shifts visitors toward what converts as evidence comes in.
Reserve a slice of visitors who see nothing, so you can prove the campaign itself causes the lift.
Different content per audience on the SAME campaign (mobile visitors, big carts, returning customers), each segment gets its own version.
Variants can also test WHEN to appear: immediate vs delayed vs exit-intent, measured head-to-head.
Target by what someone did with another campaign ("saw campaign A but didn't convert") to build multi-step promotion sequences.
A small pill visitors can reopen after closing the campaign, so a closed pop-up is never gone for good.
In the designer, toggle the heatmap to paint real visitor clicks over every block of your design.
Multi-step campaigns show exactly where people drop off, screen by screen.
Put up to four campaigns side by side (impressions, clicks, conversions), best value highlighted.
Every Monday a digest lands in your notifications; the 📖 Weekly story button writes a plain-language summary with next steps whenever you want one.
Chat with the design copilot to edit the canvas ("make the headline urgent, add a countdown"), get campaign ideas from your own traffic data, translate a campaign per country, or auto-fix a low design score.
One command reads your website and proposes your real brand colours and fonts; save and every picker leads with them.
Steps blocks get true per-screen editing: tabs for each screen, add or reorder screens, and the preview follows along.
Name important versions ("Launch candidate"), restore any of them, and see a warning when a teammate is editing the same campaign.
See desktop, tablet and mobile side by side in one view; toggle pixel rulers for precise placement.
Every campaign can also be a standalone hosted page for bios and QR codes, an email drip sequence for captured leads, or a one-click web-push draft.
Publish freeze windows (change-freeze periods), an emergency pause-all switch, approvals, audit trail and version rollback.
No. Promotions are delivered by the same OpsIQ widget you already installed. Design, publish, done.
No. Set frequency caps (per session / per day, or stop after someone closes, clicks or converts). Sensible defaults are applied.
Publishing, pausing, archiving and rolling back are limited to workspace owners and full administrators. Any team member can create and design drafts.
Promotion Designer is a responsive block editor for building, reviewing, versioning and publishing a campaign experience.
Use blocks to compose the experience, preview each supported viewport and insert approved personalisation variables. Review comments and AI-media provenance before launch. Saving creates versions so a previous design can be inspected or restored.
Templates provide a searchable, categorised starting gallery for Promotion Studio campaigns.
Search or filter by category, load additional results, preview the complete experience, then choose Use template. The new campaign remains a draft and can be changed in Promotion Designer before publication.
Promotion analytics connects impressions and clicks to conversions, audience context, connector action outcomes and campaign learning.
Read impressions, click-through rate and conversions together. Break results down by country, page, trigger and device; export captured leads when necessary. Connector action outcomes show whether the promotion’s promised follow-up actually ran. AI insight and learning summaries should be treated as hypotheses to validate, not automatic proof.
Announcements publish a message in the widget notification area with optional targeting, schedule and call to action.
Choose all visitors, signed-in visitors or new visitors; optionally narrow the audience with a contact segment and page rule. Set active-from/active-to dates and an active flag. Premium style presets and colours change presentation but do not replace clear content.
Push campaigns send browser notifications to subscribed visitors after they have left the site.
Configure Web Push keys first under the Web Push settings. A campaign can include title, body, icon, hero image, badge, CTA and up to two action buttons; a persistent notification remains until the visitor interacts.
Target by audience, optional contact segment and page rule. Save a draft, schedule it or send immediately. Use the subscription and click metrics to judge reach. HTTPS and a correctly hosted service worker are required on embedded third-party sites; see Web Push on third-party sites.
The Cookie Consent studio designs the cookie banner your visitors see, defines what counts as essential for your business, applies the right behaviour for each visitor's region, and (crucially) actually enforces consent so analytics and marketing tags do not run until the visitor agrees. The banner is delivered through the OpsIQ widget already on your site. It is a premium design studio; the banner shows only once you switch consent on for your workspace.
Pick from a large library of banner designs and a full colour system (transparent, solid or gradient) to match your brand.
Fine-tune wording, button labels, policy links, banner position, and how long a choice is remembered.
Define your own cookie categories and the wording visitors see. You decide what is essential. Essential is always on; everything else is theirs to allow or refuse.
Scan your site and let OpsIQ AI auto-detect every cookie and tracker, categorise it, and write a plain-language purpose. This powers the preferences table and auto-blocking.
Choose how consent behaves by law (below), and turn on group-domain sharing, Google Consent Mode v2, and re-consent intervals.
See live consent stats from real visitor choices (accept rates, by category) scoped to your workspace.
EU/UK visitors get opt-in (nothing non-essential runs until they accept); US visitors get opt-out with a "Do Not Sell or Share" option. OpsIQ decides per visitor by location. Recommended.
Strict GDPR for all visitors, nothing non-essential until they accept.
Tags run unless the visitor opts out.
Browser Global Privacy Control (GPC) and Do-Not-Track (DNT) signals are honoured whichever mode you pick.
Consent here is not just a banner. It controls what runs:
<!-- This tag stays dormant until the visitor grants the "marketing" category -->
<script type="text/plain" data-opsiq-consent="marketing"
src="https://example.com/ads-pixel.js"></script>Turn on group-domain sharing so a visitor who accepts on one of your sites is not asked again on the others in this workspace group. Their choice carries across for the number of days you set. Turn it off for strict per-domain consent. Cookie Consent pairs with the Privacy & Compliance page, which keeps the consent ledger (proof of every grant and revoke).
Yes. Per-category enforcement stops the matching capture at the source. It is not a cosmetic banner.
No for the banner. It ships through the widget. Only auto-blocking your own third-party tags needs a one-time markup change on those tags (shown above).
On the Privacy & Compliance page: a searchable consent ledger of every grant and revoke by contact, channel, action and date.
Proactive Messages reach out automatically the moment a visitor's behaviour matches a rule, before they ask. You build each as a rule with three parts: what should happen, when it should fire, and how often. Everything is delivered through the OpsIQ widget already on your site.
Show a chat bubble or on-page banner, start a Guided Tour, send a web push or email, assign to a department, or fire a webhook. Tokens like {{visitor_name}} and {{page_title}} become real values.
Narrow who triggers it: page/URL, time on page, scroll depth, lead score, returning vs new, idle. With no conditions, the rule fires for every visitor. Add at least one to target it. Conditions combine with AND.
Set a cooldown so the same person is not pestered, e.g. once per session or once per day. Each rule has an on/off status.
Only if you add no conditions. Add at least one condition (page, lead score, returning…) to target the right visitors.
They work together: a proactive rule can start a Guided Tour, and a Chatbot Flow can be triggered by a proactive rule. Start with a single chat-message rule, then layer the others on.
Chatbot Flows script branching conversations inside your chat widget (greetings, keyword answers, guided paths) with no code. A flow is a set of connected steps (nodes): you ask a question, the visitor picks an option, and the flow sends them down the matching branch. Only Active flows run on your site.
When the path is predictable and you want it identical every time: booking steps, a returns wizard, a "which plan?" chooser, collecting an email before handoff. Flows never improvise.
When questions are open-ended, "does this work with my setup?". The Customer Chat AI answers from your trained knowledge. A flow can hand off to the AI (or a human) at any step.
Runs as the opening message when a visitor first opens the chat.
Runs when the visitor types a word you listed (e.g. refund, pricing, cancel).
Starts once contact details are shared, or a set time into the conversation.
Runs as the chat wraps up (e.g. a rating), or is started by a Proactive Message rule.
Click New Flow, name it, pick a trigger type (and keywords if Keyword), save. It starts switched off.
Click Edit Canvas. The visual builder where you add steps (messages, questions with buttons, branches) and connect them.
For each choice, draw a branch to the next step. End paths by resolving, handing to the AI, or transferring to a human.
Click Enable. The flow goes live in your widget immediately. Disable any time without losing the design.
No. They run side by side. Use flows for predictable paths and the AI for open-ended questions; a flow can always hand off to either.
Guided Tours are step-by-step walkthroughs that point at parts of your page with speech bubbles and a spotlight, guiding a visitor through onboarding or a new feature. They are fully themed and built in a visual designer with a live preview. A tour runs only when it is marked Active.
Each step targets an element and shows a bubble with your text. Add as many stops as the walkthrough needs and order them.
Start from a preset or design your own bubble (colours, gradients, spotlight) with a live preview on the right.
Optionally link a Proactive Rule so the tour auto-starts when that rule fires (e.g. a returning visitor's first dashboard visit).
A tour is eligible to run only while Active is ticked. Untick to take it down without deleting it.
Click New Guided Tour, name it, and optionally link a Proactive Rule so it starts automatically.
Add each stop: choose the element it points to and write the bubble text. Reorder until the path flows.
Pick a preset or style the bubble yourself. The live preview shows exactly what visitors see.
Tick Active and save. The tour can now run, on its own trigger, or started by a Proactive Message rule.
On their own trigger, or via a Proactive Message rule's "Guided tour" action, so you decide which visitors see which tour and when.
Conversion Goals turn an activity you care about (an inbound webhook event, a chat message, a ticket resolution) into a recorded conversion with full attribution. When the activity fires, OpsIQ logs a conversion against the contact and ties it back to the campaigns, segments and sources that led there.
Click New conversion goal. Choose the activity type that counts as a conversion, or use a Quick-start preset, Stripe purchase, Demo booked, Newsletter signup or Subscription started.
Give the conversion a name (purchase, demo_booked, signup) and optionally a fixed value and an attribution window.
Save and enable. From then on, whenever the activity fires, OpsIQ records a conversion against the contact with attribution to the preceding touches.
Any recorded activity: an inbound webhook event (payment.succeeded), a chat email capture, a ticket resolution, anything on the contact timeline.
Custom Dashboards let you build your own view of the metrics that matter, instead of relying only on the standard Overview. Add the widgets you want, drag and resize them into the layout you like, save it, and share it with your team.
Click Add Widget and pick the metric or chart you want to track. Repeat for everything you want on the board.
Drag widgets to reposition and drag their edges to resize. KPIs across the top, charts below. Whatever reads best.
Save the dashboard and share it with your team so everyone watches the same numbers.
Outreach is OpsIQ's 1:1 and bulk email engine: compose a personalised message or run a campaign to a CRM segment, with reply detection, send-time control, open/click tracking, a tracking pixel and one-click unsubscribe. It is consent-gated and CAN-SPAM / CASL compliant.
Write a personalised 1:1 email with {tokens} from the contact and CRM.
Send to a CRM segment, scheduled or now, with caps and send-time control.
Reusable message templates for repeated outreach.
Reply detection records responses and auto-stops follow-ups to anyone who replied.
Choose a CRM segment (or upload a list). Suppression and consent are applied automatically.
Write the message with personalisation tokens; preview against a real contact.
Send now or at the best time. A tracking pixel records opens; clicks and replies are attributed.
Scheduled Reports email a chosen metric set to chosen recipients on a schedule (daily, weekly or monthly) as a printable, white-label PDF. Set it once and the report lands in inboxes automatically through the OpsIQ cron.
Pick the metric set (traffic, SEO, sales, support…) and a date range.
Daily, weekly or monthly, at a time you choose, to one or more email recipients.
Save and enable. The report generates and emails itself on schedule, no manual step.
The Privacy & Compliance page is the single place to show an auditor you handle personal data responsibly: the consent ledger, the admin access log, your data residency and retention policy, and a ready-to-print DPA, in one tabbed view. Only full administrators can open it.
A searchable record of every consent grant and revoke, by contact, channel (email, push, SMS, in-widget), action, source and date. Your proof a contact agreed (or withdrew).
Who on your team viewed, edited, exported, erased or messaged a contact's data, with the admin, contact, action, stated reason and IP. Exactly what a regulator asks for.
Declare where this workspace's data lives, set how many days activity rows are kept (0 = forever), and record your data controller and DPO.
A printable Data Processing Addendum that fills in your controller, address, DPO, residency and retention. Print or save as PDF.
Connectors link OpsIQ to external platforms: e-commerce stores, billing systems, payment processors, email providers, and custom APIs. Once connected, the AI can look up orders, customer data, subscriptions, and more, and take actions with your approval.
These are present the moment you install and need only their credentials.
Web hosting billing: clients, services, tickets, invoices, domains, servers.
E-commerce: orders, customers, products, inventory, payments, webhooks.
WordPress e-commerce: orders, customers, products, coupons, shipping.
Content and users on a WordPress site.
Payments and point of sale: orders, customers, catalogue.
Legacy e-commerce: orders, customers, products.
A Botble CMS hotel site through the signed OpsIQ bridge. The reference implementation for a platform with no API.
Helpdesk: tickets, users, organizations, comments.
Local business: reviews, posts, Q&A, insights. Uses OAuth.
Calendars and events. Uses OAuth.
Mailboxes: inbound and outbound mail, address-book sync.
Email delivery: send emails and manage templates.
Email delivery: send emails via Mailgun.
Messaging channels for inbound and outbound conversations.
Facebook Messenger, Instagram DM and WhatsApp.
Analytics and search data for the SEO suite.
Company enrichment and bulk customer import.
These are published packages, not part of the install. Install one from Connectors, Marketplace and it is copied into the live connectors folder, after which it behaves exactly like the ones above.
Payments: charges, customers, invoices, subscriptions, payouts, disputes.
E-commerce: orders, customers, products, categories, brands.
E-commerce: orders, customers, products, categories, inventory.
E-commerce: orders, customers, products, cart rules, carriers.
E-commerce: orders, customers, products, categories.
Transactional email delivery.
Issue and project tracking.
Meetings, calendars and mail.
Signature, prospecting, search and analytics data.
Website platforms.
Navigate to Connectors in the admin sidebar.
Browse the list or search. Connectors are grouped by category.
Click the connector and toggle Enable.
Fill in the required fields: API key, URL, tokens, etc. Each connector has specific requirements documented in its settings panel.
Click "Test Connection." A green result means the connector can reach the external platform. A red result shows the error.
Choose which features to enable: knowledge sync, webhook sync, AI actions. Not all connectors support all features.
The AI can look up customer data, orders, subscriptions, and more through the connector. When a customer chats, the AI has real platform data to reference.
Your connector's ContextProvider feeds the ticket-AI a read-only account summary of the ticket owner. Resolve the customer by customer_id when known; otherwise, on ticket auto-replies, where the ctx flag customer_trust_email is true, look the account up by customer_email (the verified ticket sender). Remote platforms expose a /context/customer-by-email endpoint and the connector calls it. This is what makes the AI quote a real balance/invoice instead of saying “please log in.” Honour the operator's data-class toggles (customer_sections, customer_allow_credit) and stay strictly read-only, never emit secrets.
Your connector's IdentityProvider feeds three universal ticket lookups: lookupCustomerById() (customer card), lookupCustomerServices() (product/service table), and listCustomers($query,$limit): the "Search customer or type email" picker on the native Compose-New-Ticket form. Return rows of {id, external_id, name, email, company, phone, platform, platform_label}. Remote rule: if your customers live in another database or service, fetch them over your platform's API inside these methods, never read the other system's tables directly (in the OpsIQ DB they're empty placeholders, which is why a local read returns an empty picker). Gate the remote path on your configured API URL; keep a local read only as a same-DB fallback.
When inbound email becomes a native ticket, OpsIQ detects the sender by calling lookupCustomerById(0, ['email'=>$sender]) across every connector; the first match "owns" the customer and its platform slug is stamped on the ticket.created event as _pipe_owner_platform (empty = guest). So a WHMCS-customer email opens a ticket in WHMCS (WHMCS numbering, mirrored as one), while an unknown sender stays a native guest. If your connector mirrors native tickets onto its own platform, your ticket.created handler must gate on this: if (array_key_exists('_pipe_owner_platform',$payload) && $payload['_pipe_owner_platform'] !== '<your-slug>') return;. The key is absent on non-piped (chat/manual/AI) tickets, so those mirror as before. Per-department control lives under Team & Departments → Open tickets via email (Anyone / Customers only / Off).
The AI can perform actions through the connector: create tickets, update orders, cancel subscriptions, all with your approval through the Trust Layer.
Connectors contribute platform-specific knowledge articles to the AI. Shopify connector adds e-commerce troubleshooting; WHMCS connector adds hosting knowledge.
If your platform hosts a knowledge base, declare a kb_capabilities block in settings.json (type kb_source) and your connector appears in the Help Center editor's Import KB → Import from a connected app dropdown whenever it is enabled and configured in the workspace. It is declarative, no method to implement: name a built-in adapter (zendesk for the exact-tree Help Center API, or crawl for any KB site) and a base_template such as https://{subdomain}.zendesk.com, which OpsIQ fills from your connector's stored settings. Credentials never leave the server; the browser only sends the connector slug. To support a new platform, add an opsiq_kb_<platform>_manifest() adapter and reference it by name. Full reference: connectors/PLATFORM_CONNECTORS.md §5.
Some connectors register webhooks with the external platform for real-time event notifications (new orders, ticket updates, etc.).
E-commerce connectors feed revenue data into the Sales dashboard for attribution and analytics.
Yes. You can have Shopify for orders and Stripe for payments in the same workspace. The AI merges data from all enabled connectors.
Use the Connector Builder to create a custom connector for any platform with a REST API. Or check the Marketplace for community-built connectors.
Yes. Connectors work identically in both cloud and self-hosted editions.
Every commerce connector uses the same platform-neutral event contract. WHMCS is the reference implementation, but SaaS Bridge, stores, payment providers, marketplace connectors and Connector Builder packages must obey the same rules.
Publish realised economic events to opsiq_sales_events through CommerceEventRegistry::normalize(). Do not build a connector-specific Sales table or make core analytics query a remote platform directly.
platform is the connector registry slug, such as whmcs, shopify or opsiq_saas. traffic_source contains verified acquisition attribution when supplied; otherwise use that same slug as the fallback. Store identifiers, not display labels. OpsIQ resolves the friendly connector name in the UI.
event_id must be deterministic. Map at least one immutable order_ref, invoice_ref or subscription_ref so webhook retries and backfills update the same event instead of creating duplicate sales. service_ref identifies the affected product or service instance when one exists.
occurred_at is the payment or economic-event time reported by the source platform. Never replace historical payment dates with the import time.
Send the source amount and a valid three-letter ISO currency. If the connector setting enables OpsIQ FX conversion, reporting converts to the workspace reporting currency; otherwise reports preserve the store or billing platform currency. Connector code must not hardcode a reporting currency or exchange rate.
Use new, renewal, upgrade, refund, credit or unknown. Classify from invoice reason, subscription or service relationship, line-item type, or another authoritative source field. A repeat purchase by the same customer is not automatically a renewal.
Only positive paid new, renewal, upgrade, or legitimately unknown commerce receipts belong in Sales & Conversions. Refunds are reported by refund and net-revenue analytics. Account credit, wallet top-ups, token top-ups and Add Funds remain billing-ledger events and never count as sales, conversions, order volume, or sales revenue.
CRM deals represent pipeline and deal activity. They are not commerce-platform sales unless a connected billing or store platform emits the realised paid order or invoice through this contract.
opsiq_conversions and dashboard summaries are compatibility projections rebuilt from the ledger. Connectors must not treat a projection as the financial source of truth. Contract revisions can re-evaluate derived rows without deleting the underlying billing history.
A remote connector reads its platform through the configured authenticated API. It must never depend on same-server database tables. The exact authenticated domain site_key is supplied by ConnectorRegistry and must be applied to every ledger write and backfill. Workspace or group scope is read-time aggregation only; it must never broaden stored event ownership.
{
"event_id": "acme_store:invoice:INV-1042",
"event_name": "invoice.paid",
"platform": "acme_store",
"order_ref": "ORDER-884",
"invoice_ref": "INV-1042",
"subscription_ref": "SUB-28",
"service_ref": "SERVICE-91",
"status": "paid",
"lifecycle_type": "renewal",
"amount": 129.00,
"currency": "USD",
"traffic_source": "acme_store",
"occurred_at": "2026-07-23 08:30:27"
}When Sales and billing is enabled in Connector Builder, map amount, currency, source status and source date, plus at least one order, invoice or subscription reference. Map lifecycle_type when the API exposes authoritative lifecycle evidence. The generated SalesIngest passes every row through the same CommerceEventRegistry normalizer used by built-in and marketplace connectors.
lifecycle_type is not an analytics label. OpsIQ reads it to decide whether a sale enters the CRM pipeline, so every sales connector is making a pipeline decision whether it intends to or not.
Opens a closed-won deal (new business).
Recorded as recurring revenue. No new-business deal — renewals convert on a different probability curve and mixing them corrupts both forecasts.
Never opens a deal, in any mode. Money returned to a customer is not a win.
Revenue only. The sale is recorded but never reaches the pipeline.
Do not match on event_id and insert yourself. event_id is platform:eventName:externalId, which answers “did we already process this delivery” and cannot answer “have we already recorded this sale”. A platform that announces one payment twice — as invoice.paid and again as payment.completed — mints two ids and lands the same money twice, with nothing to collide and nothing to warn.
Call the shared write instead. Core computes the sale’s business identity (sale_fingerprint), matches an existing row on it, preserves the original event_id on update, and filters to real columns:
\OpsIQ\Commerce\CommerceEventContract::upsertSaleRow('opsiq_sales_events', $row);invoice.paid, payment.completed and sale.completed for one invoice share one fingerprint and update one row.
Money going out is a different fact from money coming in. A refund of an invoice keeps its own identity, so it can never overwrite the payment it reverses.
A row carrying no order, invoice, subscription or service reference gets no fingerprint at all, so two unrelated rows never collide just because both are missing an id.
invoice_ref, then order_ref, then subscription_ref, then service_ref — strongest first, so one sale keeps a stable identity.
A refund, a cancellation or a correction is a new dated entry. Never mutate the row it corrects. Rewriting a payment into a refund looks tidy and breaks three things at once:
Gross sales and refund rate stop being separable — and refund rate is the metric the reversal exists to inform.
A March refund of a January sale must reduce March. Rewriting the January row silently restates a closed period.
A ledger entry records what happened at a point in time. Corrections are contra-entries, which is how double-entry bookkeeping has worked for five centuries.
So a connector reports the reversal rather than applying it: return refunded_at and refund_amount alongside the sale’s own lifecycle, and let the caller write the refund as its own row dated when the refund happened. The two can never collide, because the sale fingerprint separates a return from a sale.
OpsIQ decides the lifecycle once, in \OpsIQ\Commerce\SaleLifecycleClassifier. A connector declares only which of its own platform's words mean what, by implementing \OpsIQ\Connectors\SalesLifecycleConnectorInterface::salesLifecycleVocabulary(), and then calls the shared classifier. Do not re-implement the reasoning.
public static function salesLifecycleVocabulary(): array
{
return [
'credit' => ['addfunds'], // adds balance, sells nothing
'upgrade' => ['upgrade'], // resizes an existing commitment
'recurring' => ['hosting', 'domainrenew'], // continues something owned
'acquisition' => ['domainregister'], // obtains something new
'recurring_prefixes' => ['domainaddon'], // families that grow over releases
];
}
$lifecycle = \OpsIQ\Commerce\SaleLifecycleClassifier::classify([
'explicit' => $platformSaidSo, // wins outright when present
'line_types' => $types, // your platform's own line/item types
'vocabulary' => self::salesLifecycleVocabulary(),
'is_order' => $cameFromANewOrder,
'is_refunded' => $moneyWentBack,
]);This is the failure that costs the most and looks the least wrong. The WHMCS connector matched ['hosting','addon','domain'] — a list that reads as complete. WHMCS does not emit a bare Domain type for real domain lines; it emits DomainRegister, DomainRenew, DomainTransfer, PromoHosting, PromoDomain, DomainAddon* and Upgrade. All of them fell past the list to unknown: 1,288 invoices, three years, no error and no log line.
Every new customer imports their history through a connector backfill, so a classification bug does not affect one workspace — it affects every workspace that ever onboards through that connector, at the moment they first look at their pipeline. Take the vocabulary from the platform’s documentation or a census of live data, and match growing families by prefix so a sibling nobody has seen yet classifies with its relatives instead of vanishing.
Every shipped OpsIQ sales connector implements this — WHMCS, Shopify, WooCommerce, osCommerce, SaaS Bridge, Stripe, BigCommerce and Magento 2. Treat it as expected, not optional: a customer imports their old records on day one, so a classification fix that cannot reach that history only helps people who signed up afterwards. Implement \OpsIQ\Connectors\SalesLifecycleRepairInterface::reclassifySale() using whatever per-record fetch your connector already has. tools/crm_backfill_sales_lifecycle.php then repairs your connector’s imported history with no per-connector code: dry run by default, backs itself up and verifies the row count before writing, reversible through an undo ledger, and it never writes a failed read as an answer.
Journey Intelligence accepts one platform-neutral event envelope from the browser widget, built-in connectors, SaaS Bridge, marketplace packages and Connector Builder output. Platform-specific names are translated at the edge; funnel, attribution and Site Intelligence code consumes only canonical events.
Every event is bound to the authenticated domain site_key. A connector must take that key from ConnectorRegistry or its authenticated endpoint, never from an untrusted request body. Domains keep separate records; a domain group is a read-time aggregate only.
event_id is required for connectors and must be deterministic for the same native event. Retries, webhooks and backfills update one event rather than duplicate a journey or sale.
Preserve source_event_name for evidence and troubleshooting, then map it to event_name_canonical. Core analytics must never branch on a connector slug.
Browser observation can start or infer a journey. Authenticated connector events confirm signup, login, payment, purchase, renewal, refund and other terminal outcomes. A valid site-bound correlation token is the strongest join; an invalid token is rejected and its embedded IDs are not trusted.
Send only identifiers and fields needed for the declared journey. Respect consent, masking and retention settings. Never place credentials, card data, authentication secrets or private message bodies in properties.
{
"contract_version": 1,
"event_id": "myshop:order:884:paid",
"source": "myshop",
"source_event_name": "order.paid",
"event_name_canonical": "commerce.purchase.completed",
"site_key": "exact_domain_site_key",
"occurred_at": "2026-07-23T08:30:27Z",
"visitor_id": "optional-browser-visitor",
"session_id": "optional-browser-session",
"journey_id": "optional-journey",
"attempt_id": "optional-attempt",
"correlation_token": "optional-signed-token",
"customer_ref": "C-42",
"user_email": "[email protected]",
"object_type": "order",
"object_ref": "884",
"order_ref": "884",
"outcome": "succeeded",
"evidence_level": "server_confirmed",
"confidence": 1,
"properties": {"amount": 129, "currency": "USD"}
}Use the narrowest truthful name. Supported families include engagement page/CTA events; account signup, login, MFA and password reset; lead and form stages; product, cart, checkout, payment, purchase, subscription, renewal and refund; promotion impressions and conversions; help-centre, chat and ticket events; security events; and namespaced custom events. Typical terminal names are account.signup.succeeded, account.login.succeeded, lead.form.succeeded, commerce.payment.succeeded, commerce.purchase.completed, commerce.subscription.renewed and commerce.refund.completed.
The widget can work without a connector by observing page structure, form actions, DOM outcomes and the visitor journey log. That evidence remains explicitly graded as observed or inferred. A connector adds authoritative server confirmation and can correlate it to the same browser attempt. Abandonment is first stored as a candidate; it becomes abandoned only after the inactivity window set in the UI and only when no later recovery or success exists.
Attribution prefers a valid signed correlation token, then an exact journey, attempt, session or commerce reference, then the consented identity graph, and finally a bounded behavioural match. Unmatched sales remain unattributed. Multi-touch ledger weights must total 1. Site Intelligence attributed revenue reads this ledger; credits, wallet top-ups, token top-ups and Add Funds are never purchase conversions. Connector FX behaviour remains controlled by that connector setting.
{
"capabilities": ["sales", "journey_events"],
"journey_capabilities": {
"journey_events": true,
"payments": true,
"subscriptions": false,
"correlation_token": false,
"backfill": true
},
"journey_event_mappings": [{
"source_event_name": "order.paid",
"event_name_canonical": "commerce.purchase.completed",
"field_map": {
"order_ref": "order.id",
"customer_ref": "order.customer_id",
"amount": "order.total",
"currency": "order.currency",
"occurred_at": "order.paid_at"
}
}]
}Declare only capabilities the package really delivers. Connector Builder validates the mapping and generates the same platform-neutral adapter used by first-party packages. Journey ingestion accepts one event or a bounded batch of 100 through the generated authenticated integration endpoint.
Every connector declares a set of actions: things the AI can do through the external platform. Actions are the bridge between "the AI says" and "the AI does."
"Cancel my subscription." The AI identifies this requires the "cancel_subscription" action.
Is this action allowed? Is it enabled? Does the current user have the right role?
The action needs a subscription ID. The AI looks it up from the customer context or asks the customer.
For destructive or high-impact actions, the AI asks for confirmation before executing.
The action calls the external platform API.
The AI reports the result to the customer.
Look up data without changing anything. Examples: list_orders, get_customer. Safe, no confirmation needed.
Create or modify data. Examples: create_ticket, update_order. May require confirmation.
Remove data. Examples: cancel_subscription. Always require confirmation.
Declared in actions.json, generic API calls defined declaratively.
Optional per-action "capability" field in actions.json, a connector-neutral class tag (e.g. "tickets" for a ticket read/lookup, "ticket_create" for opening a ticket). OpsIQ gates the whole class uniformly across every connector: ticket reads drop out of the AI when the operator turns off AI Ticket Awareness, and ticket creation is reserved for OpsIQ's own composer (so a connector's create tool can't duplicate it). Declare it and your connector conforms. OpsIQ never needs to know your action names. The Connector Builder exposes it as a Capability dropdown per action.
Implemented in PHP in the connector class. Full control over logic.
{
"lookup_order": {
"label": "Look up an order",
"description": "Find an order by ID or email",
"method": "GET",
"endpoint": "/admin/api/2024-01/orders.json",
"params": {
"order_id": { "type": "string", "label": "Order ID" },
"email": { "type": "email", "label": "Customer email" }
}
}
}The Connector Builder lets you create a complete connector for any platform with a REST API. No coding required for basic connectors.
Each generated API connector can expose separate Native API Read and Native API Write actions. Curated actions remain preferred; native actions cover provider endpoints added later. The runtime supports REST, GraphQL, JSON, form, XML, raw and multipart bodies, bounded pagination, API-version headers and idempotency while keeping credentials inside the workspace connector settings.
The wizard has six steps, shown as tabs across the top. You can jump between them freely, and Save draft in the footer keeps your work at any point.
Name, slug, description and icon, then choose a contract profile: Standard API, Commerce, Helpdesk, Mailbox, Site Intelligence, SaaS Bridge, Local PHP Platform, or Platform with no API when the platform serves nothing callable and OpsIQ has to install a bridge. The profile selects a complete capability starting point; you can still adjust individual capabilities.
Pick the authentication pattern the platform uses and fill in its fields. Enter real test credentials here as well: they are used for the connection test on the next step, and they are not stored after you publish.
Enter the API base URL and a verify endpoint, then run a live connection test using the credentials from step 2. Do this before you define any actions, if the auth or the base URL is wrong, every action you write afterwards would fail for the same reason and you would be debugging the wrong thing.
Define each operation: name, HTTP method, endpoint path, parameters, response field mapping, and the reliability settings described below. You can run each action individually against the live API from this step.
Map the webhook events your platform sends onto OpsIQ events, so things that happen on your platform can start work in OpsIQ.
Review every action, trigger and capability. Enterprise profiles expose the generated queue, worker, hook, migration, ticket-mirror, attachment and conflict contract before publishing. Publishing writes the package into /connectors/<slug>/.
Five behaviours of the generator surprise people. None is a bug; all of them will cost you an afternoon if you meet them by accident.
Answer it in step 1 by picking the data-access mode (or the "Platform with no API" profile). API mode declares native_api and emits the <slug>_api_call passthrough. Bridge mode declares platform_bridge instead and STRIPS native_api even if an older spec carried it, so the manifest, the generated class and the expertise docs cannot disagree. ai_brain_aware is added either way.
The Builder follows your answer; it does not work the truth out for itself, and the default when nothing is said is API mode. So a no-API platform must ACTIVELY say so — pick the "Platform with no API" profile, set data access to bridge, or tick platform_bridge; any one of the three is enough and they cannot contradict each other. Skip the question on a platform with no API and you are back to the old failure: a dead <slug>_api_call the model keeps reaching for. This used to be stamped unconditionally, so the trap is now escapable rather than gone.
If you leave the verify path empty, the Builder writes /ping into the generated connector and into profile.json's test block. Almost no real platform serves that route, so Test Connection fails with HTTP 404 on every install and reads like a customer misconfiguration rather than a package defect. Set a verify path that your platform actually answers. For a bridge connector, point it at your own diagnostics endpoint — it proves the whole chain in one call: the bridge is deployed, the key matches, and the bridge can reach the database.
Capabilities now follow the data-access answer, so those no longer drift. Everything else generated still does: edit ContextProvider.php or any other emitted file and the next publish replaces it. The one protected exception is the bridge file — the wizard only overwrites a bridge carrying its own marker, so a hand-written one is left alone.
Un-tick a capability and the next publish removes its provider file. Hand-edits to any generated file — ContextProvider.php above all — are overwritten without warning. Copy customisations out first, or take ownership of the package by deleting .opsiq-builder.json (after which the wizard will no longer manage it).
The wizard has no control for it. A package meant to ship as production must have release_status changed by hand in settings.json — and that edit breaks the signature, so re-sign afterwards.
Builder packages are signed with this install's own symmetric key. That detects tampering. It does not prove who wrote the package, and any install holding the same key can produce the same signature. Treat a locally signed package as self-signed.
Publishing refuses a slug that already exists under /connectors/. It does not look at /marketplace_connectors/, so a hand-authored first-party package with the same slug can end up shadowed.
Every action has the following settings. Only the first four are required; the rest control who may run it and how carefully.
The key is what the AI calls; the label is what a human reads. Keys are namespaced with your connector slug automatically, so two connectors can both have a "list_orders" without colliding.
GET, POST, PUT, PATCH or DELETE.
Appended to the base URL. Use {name} for placeholders, for example /opportunities/{id}/stage
For each parameter you also choose where it goes: body, path, query or header. A path parameter fills a {placeholder}; a query parameter is appended to the URL.
Say which field in the JSON response means what, which is the customer name, which is the email, which is the order total. This is what lets the AI read your platform's data rather than guess at it.
Your team (admin AI), signed-in customers (customer chat), both, or the writing assistant. Customer actions run only for the signed-in customer, and identity fields are locked to them automatically so one customer cannot ask about another.
A human must approve before the action runs.
Marks the action as deleting or changing state. Used to warn before it runs.
The admin must hold this permission for the AI to run the action on their behalf; full administrators always pass. Choose from manage_integrations, manage_general, manage_billing, manage_sales_bridge, manage_knowledge, manage_appearance, manage_behavior, manage_permissions, manage_dangerzone, reply_to_chats, escalate_to_ticket, send_agent_email, or none, meaning any authenticated admin.
Optional, but worth writing. It tells the AI when to reach for this action, for example "Use this when the admin asks to change a deal stage". A good hint is the difference between an action the AI uses correctly and one it ignores.
Optional class tag, either tickets (a ticket read or lookup) or ticket_create (opens a ticket). Tagging lets OpsIQ gate the whole class at once, for example, hiding ticket reads when an operator turns AI ticket awareness off.
Optional. For endpoints that return a list, the dotted path to the array, for example data or data.items
Optional. A body field whose presence means the call failed, for example error.message, useful for APIs that return HTTP 200 on failure.
Each action can be run against the live API from this step, so you can fix a wrong path or field name before anyone else uses it.
The Triggers step gives you a webhook URL to register with your platform, and verifies every request that arrives on it.
The header your platform signs with, for example X-Hub-Signature-256.
HMAC-SHA1, HMAC-SHA256 or HMAC-SHA512.
Simple, a plain hex or base64 digest. Or Stripe-style, the t=…,v1=… format used by Stripe and several platforms that copied it.
Optional. Some platforms prefix the digest, for example sha256=. Leave it empty if yours does not.
Map each event your platform sends onto the OpsIQ event it should raise.
If your platform has an API for managing its own webhooks, you do not have to register the URL by hand. Open Auto-register this webhook on enable and point it at two of the actions you defined in step 4:
Called when an admin enables the connector. You give the parameter name that carries the URL, optionally the one that carries the event list, and the path in the response that holds the new webhook's id.
Called when the connector is disabled, using the id captured above, so disabling the connector also stops your platform sending to a dead endpoint.
Profiles and capabilities are defined by Connector Contract 2.2. Generated and declarative capabilities are emitted directly; enterprise capabilities generate an EnterpriseExtension.php scaffold with runtime lifecycle wiring.
Operations the AI can run on your platform: list orders, find a customer, issue a refund.
Receive webhooks from your platform and turn them into OpsIQ events.
AI Triage and the reply Copilot on tickets that stay on your platform. Pick the endpoint that returns one ticket with its replies and map the fields; OpsIQ reads the thread through it.
Show a customer's mail on their timeline, send from a deal, and sync your address book into the OpsIQ CRM.
Page through your customer list and import each one as an OpsIQ contact. This is what the Import button runs.
Push live data from your platform into every AI conversation.
Work out which of your customers a visitor is, and show their profile and purchases on a ticket.
Feed revenue events and MRR figures into the OpsIQ dashboards.
Turn tickets and emails your platform delivers by webhook into OpsIQ support threads.
Post OpsIQ staff replies back to the platform the thread originated on.
Import your staff accounts into OpsIQ admin users.
Import your support departments into OpsIQ.
Let Promotion Studio target on facts you know about a person, and render your real products inside a promotion.
Expose server-verified Survey facts, escaped variables and bounded CRM Outreach recipient pages through a dedicated SurveyProvider.php. This does not reuse the Promotion runtime.
When OpsIQ blocks an IP, call your platform's own block API so the block is enforced there too.
Receive blocked-IP threat signals from OpsIQ.
Every connector you build ships a short reference describing what your platform is and what its actions do. The OpsIQ admin AI reads it whenever your connector is enabled, so it understands your platform rather than just seeing a list of action names. This is generated for you.
Your connector always gets a general-purpose call so the AI can reach an endpoint you did not define a typed action for. Use typed actions where you can; this is the escape hatch.
Contract version: 2.2 · 55 capabilities · 8 profiles.
Actions, triggers, OAuth/API-key authentication and optional context/identity mappings. Capabilities: actions, triggers, native_api, ai_brain_aware.
Customers, orders, sales, subscriptions, billing, promotions and journey events. Capabilities: actions, triggers, journey_events, sales, billing, sync_orders, customer_import, survey, promo_audience, promo_feed, context, identity.
Inbound tickets, outbound replies/notes, customer roster, AI triage and bidirectional ticket mirroring. Capabilities: actions, triggers, inbound_ticket, outbound_reply, outbound_note, ai_tickets, customer_import, survey, context, identity, ticket_mirror, attachment_bridge, conflict_resolution.
Inbound/outbound mail, address-book sync, multi-account OAuth and CRM timeline integration. Capabilities: inbound_email, outbound_email, mailbox, email_mailbox, oauth, actions, customer_import, ai_reply.
SEO, analytics, search-console, local-search or monitoring provider with scheduled sync. Capabilities: actions, triggers, site_intelligence, seo, scheduled_workers, durable_queue.
Deep two-way SaaS integration with customers, billing, identity, tickets, webhooks, queues, attachments and workers. Capabilities: actions, triggers, webhook, context, identity, customer_import, survey, journey_events, sales, billing, inbound_ticket, outbound_reply, ticket_mirror, attachment_bridge, durable_queue, scheduled_workers, database_migrations, conflict_resolution, enterprise_hooks, admin_assets.
For a self-hosted PHP application that serves no callable API. The wizard generates a signed bridge file the operator drops into their own site, plus the typed actions that read and write through it. Capabilities: actions, platform_bridge, ai_brain_aware.
WHMCS-style local hooks, database access, two-way tickets, billing/customer sync, queues and migrations. Capabilities: actions, native_data, context, identity, customer_import, survey, journey_events, sales, billing, inbound_ticket, outbound_reply, ticket_mirror, attachment_bridge, durable_queue, scheduled_workers, database_migrations, conflict_resolution, enterprise_hooks, admin_assets.
Universal actions. Capability version: 1.0. Mode: generated. Runtime methods: registerActions. Package files: actions.json.
Inbound event triggers. Capability version: 1.0. Mode: generated. Runtime methods: handleWebhook. Package files: actions.json.
Inbound webhook endpoint. Capability version: 1.0. Mode: generated. Runtime methods: handleWebhook.
Universal Journey Event Contract mapping. Capability version: 1.1. Mode: generated. Interfaces: OpsIQ\Connectors\JourneyEventConnectorInterface. Package files: settings.json.
AI context providers. Capability version: 1.0. Mode: generated. Runtime methods: contextProviders. Interfaces: OpsIQ\Connectors\ContextConnectorInterface. Package files: ContextProvider.php.
Guest record lookup without login (reference + proof match). Capability version: 1.0. Mode: generated. Runtime methods: contextProviders. Interfaces: OpsIQ\Connectors\ContextConnectorInterface. Package files: GuestLookupProvider.php.
Admin/customer identity providers. Capability version: 1.0. Mode: generated. Runtime methods: identityProviders, detectAdmin, detectCustomer. Interfaces: OpsIQ\Connectors\IdentityConnectorInterface. Package files: IdentityProvider.php.
Sales and revenue ingestion. Capability version: 1.1. Mode: generated. Interfaces: OpsIQ\Connectors\CommerceConnectorInterface. Package files: SalesIngest.php.
Cross-platform billing snapshot. Capability version: 1.0. Mode: generated. Runtime methods: billingProviders. Interfaces: OpsIQ\Connectors\BillingConnectorInterface. Package files: BillingProvider.php.
Payment-provider capability bus. Capability version: 1.0. Mode: generated. Runtime methods: paymentsCapabilities.
Sell through chat: canonical commerce role map. Capability version: 1.0. Mode: declarative. Package files: commerce_roles.json.
External ticket/email to OpsIQ ticket ingestion. Capability version: 1.0. Mode: generated. Runtime methods: handleWebhook. Interfaces: OpsIQ\Connectors\TicketMirrorConnectorInterface.
Reply mirroring to the external platform. Capability version: 1.0. Mode: generated. Runtime methods: pushReply. Interfaces: OpsIQ\Connectors\TicketMirrorConnectorInterface.
Staff/customer synchronisation. Capability version: 2.0. Mode: generated. Runtime methods: listCustomers. Interfaces: OpsIQ\Connectors\CustomerImportConnectorInterface. Package files: SyncImport.php.
Department/team synchronisation. Capability version: 1.0. Mode: generated. Package files: SyncImport.php.
Order roster and order-event synchronisation. Capability version: 1.0. Mode: declarative. Interfaces: OpsIQ\Connectors\CommerceConnectorInterface.
Product, catalog and inventory synchronisation. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
Project, issue and workspace synchronisation. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
CRM customer roster import. Capability version: 2.0. Mode: generated. Runtime methods: listCustomers, backfillChunk. Interfaces: OpsIQ\Connectors\CustomerImportConnectorInterface.
Receive and emit security events. Capability version: 1.1. Mode: generated. Runtime methods: securityCapabilities, syncBlockedIp, removeBlockedIp. Interfaces: OpsIQ\Connectors\SecuritySyncConnectorInterface.
Native remote IP/CIDR blocking. Capability version: 1.0. Mode: generated. Runtime methods: syncBlockedIp, removeBlockedIp. Interfaces: OpsIQ\Connectors\SecuritySyncConnectorInterface.
Survey identity, audiences, recipients and variables. Capability version: 1.0. Mode: generated. Runtime methods: surveyAudienceCatalog, surveyAudienceFacts, surveyVariableCatalog, surveyVariables, surveyRecipientPage. Interfaces: OpsIQ\Connectors\SurveyConnectorInterface. Package files: SurveyProvider.php.
Ticket reply feedback mirror (platform reply ratings land via the portal write method). Capability version: 1.0. Mode: generated. Runtime methods: replyFeedbackCatalog, pullReplyFeedback. Interfaces: OpsIQ\Connectors\ReplyFeedbackConnectorInterface.
Promotion targeting facts. Capability version: 1.0. Mode: generated. Runtime methods: subscribers. Interfaces: OpsIQ\Connectors\PromotionConnectorInterface.
Promotion product/content feed. Capability version: 1.0. Mode: generated. Interfaces: OpsIQ\Connectors\PromotionConnectorInterface.
Mailbox bus, outbound mail and address-book sync. Capability version: 1.0. Mode: generated. Runtime methods: emailAccounts. Interfaces: OpsIQ\Connectors\MailboxConnectorInterface.
Receive inbound email. Capability version: 1.0. Mode: declarative. Runtime methods: poll, handleWebhook. Interfaces: OpsIQ\Connectors\MailboxConnectorInterface.
Send outbound email. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions. Interfaces: OpsIQ\Connectors\MailboxConnectorInterface.
Mailbox connector. Capability version: 1.0. Mode: declarative. Runtime methods: emailAccounts. Interfaces: OpsIQ\Connectors\MailboxConnectorInterface.
AI triage and Inbox Copilot for remote tickets. Capability version: 1.0. Mode: generated. Runtime methods: loadTriageContext. Package files: AiOperations.php.
AI-assisted reply drafting. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
Connector expertise supplied to Admin AI. Capability version: 1.0. Mode: generated. Package files: ai_expertise_admin.md, ai_api_reference.md.
Native API passthrough. Capability version: 1.0. Mode: generated. Runtime methods: registerActions.
Signed platform bridge (for platforms with no API). Capability version: 1.0. Mode: generated. Runtime methods: registerActions. Package files: bridge/.
Local database/platform data adapter. Capability version: 1.0. Mode: declarative. Runtime methods: nativeDataProviders. Interfaces: OpsIQ\Connectors\NativeDataConnectorInterface.
CRM capability provider (calendar, enrichment, telephony or customer data). Capability version: 1.0. Mode: declarative. Runtime methods: crmCapabilities. Interfaces: OpsIQ\Connectors\CrmCapabilityConnectorInterface.
Remote sender block-registry synchronisation. Capability version: 1.0. Mode: declarative. Runtime methods: blockSender, unblockSender, isSenderBlocked. Interfaces: OpsIQ\Platform\BlockRegistryInterface.
Inbound comment ingestion. Capability version: 1.0. Mode: declarative. Runtime methods: handleWebhook.
Outbound private note. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
Outbound notification delivery. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
OAuth 2.0 authorisation. Capability version: 1.0. Mode: generated.
Review ingestion and response. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
Local search/location data. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
SEO data and actions. Capability version: 1.0. Mode: declarative. Runtime methods: registerActions.
Site Intelligence provider. Capability version: 1.0. Mode: declarative. Runtime methods: siteIntelligenceProviders. Interfaces: OpsIQ\Connectors\SiteIntelligenceConnectorInterface.
Analytics data provider. Capability version: 1.0. Mode: declarative. Runtime methods: analyticsCapabilities.
Communications/video-meeting provider. Capability version: 1.0. Mode: declarative. Runtime methods: commsCapabilities.
Connector-provided admin/account/public browser assets. Capability version: 1.0. Mode: generated. Runtime methods: adminAssets. Interfaces: OpsIQ\Connectors\AdminAssetConnectorInterface.
Platform-native hooks and lifecycle callbacks. Capability version: 1.0. Mode: extension. Package files: EnterpriseExtension.php.
Durable outbox/inbox queue and retry policy. Capability version: 2.0. Mode: extension. Package files: EnterpriseExtension.php.
Bidirectional ticket mirror with conflict handling. Capability version: 2.0. Mode: extension. Interfaces: OpsIQ\Connectors\TicketMirrorConnectorInterface. Package files: EnterpriseExtension.php.
Attachment upload/download transfer. Capability version: 2.0. Mode: extension. Package files: EnterpriseExtension.php.
Connector-owned schema migrations. Capability version: 1.0. Mode: extension. Package files: EnterpriseExtension.php.
Connector-owned scheduled/background workers. Capability version: 1.0. Mode: extension. Package files: EnterpriseExtension.php.
Two-way sync conflict strategy. Capability version: 1.0. Mode: extension. Package files: EnterpriseExtension.php.
How many times to retry a failed call, with a backoff that doubles each attempt. Only timeouts, 429s and 5xx errors are retried; a 4xx is your request's fault and repeating it would just burn your rate limit.
A per-minute ceiling for this action, so a busy trigger cannot hammer your platform. Leave it at 0 for no limit.
How long to wait for your platform before giving up.
Require a human to approve before the action runs. Use it for anything destructive.
Step 2 offers seven patterns. Pick the one that matches your platform's API documentation, the generator emits the right HTTP client for it.
A static key sent as a fixed header, for example X-API-Key. You give the header name and the label the admin form should show. This sends the key as a header only; if your API expects the key as a query parameter instead, use Custom headers or a full-code connector.
Token sent as Authorization: Bearer <token>. Common for modern APIs.
Username and password, base64-encoded into the Authorization header. You choose the labels both fields show on the admin form.
A public key plus a secret, with the request body signed. You give the signature header, the key header and the timestamp header your platform expects.
Server-to-server, with no user interaction and no redirect. You give the token URL and an optional scope; the admin supplies a client ID and secret. Use this when your platform issues credentials to an application rather than to a person.
The authorization-code flow with PKCE, for Stripe, Shopify, Slack and QuickBooks-style apps. You give the authorization URL, the token URL and the scope. After publishing, the admin clicks Connect on the connector, authorizes on your platform, and OpsIQ stores the refresh token and mints access tokens on demand. The redirect URI to register in your OAuth app is shown on the connector's settings page.
A free-form JSON header map for anything the patterns above do not cover, for example {"X-API-Key":"{api_key}","X-Tenant":"{tenant_id}"}. Each placeholder becomes a field on the admin form.
Uses offset and limit parameters. Example: ?offset=100&limit=50.
Uses page number. Example: ?page=3&per_page=50.
Uses a cursor token from the previous response.
Uses the Link response header with rel="next".
connector.php RETURNS an instance. It does not declare a named class that OpsIQ hunts for. The method names below are the ones ConnectorInterface requires; getting one wrong is a fatal at load, not a warning.
<?php
/* connectors/myplatform/connector.php */
declare(strict_types=1);
use OpsIQ\Connectors\AbstractConnector;
require_once __DIR__ . '/Client.php';
return new class extends AbstractConnector {
/* ── the three identity methods. NOT identifier()/label(). ── */
public function slug(): string { return 'myplatform'; }
public function name(): string { return 'My Platform'; }
public function description(): string { return 'Orders and customers from My Platform.'; }
public function capabilities(): array { return ['actions', 'context']; }
public function settingsSchema(): array
{
$f = __DIR__ . '/settings.json';
if (!is_file($f)) return [];
$j = json_decode((string)file_get_contents($f), true);
return is_array($j['settings'] ?? null) ? $j['settings'] : [];
}
/* ── NOTE THE ARGUMENT. testConnection() with no parameter is a fatal. ── */
public function testConnection(array $settings): array
{
try {
$resp = \OpsIQ\Connectors\MyPlatform\Client::callWithSettings($settings, 'GET', '/me', [], []);
$code = (int)($resp['http_code'] ?? 0);
return ($code >= 200 && $code < 300)
? ['success' => true, 'info' => ['message' => 'Connection OK', 'http_code' => $code]]
: ['success' => false, 'error' => "Verify endpoint returned HTTP $code"];
} catch (\Throwable $e) {
return ['success' => false, 'error' => 'Test failed: ' . $e->getMessage()];
}
}
public function onEnable(array $settings): array { return ['success' => true]; }
public function onDisable(array $settings): array { return ['success' => true]; }
public function handleWebhook(array $payload, array $headers, array $settings): array
{
return ['success' => true, 'note' => 'No triggers declared.'];
}
/* Inherited from AbstractConnector: reads actions.json for you.
* Override only to ADD actions the manifest cannot express. */
public function registerActions(array $settings): array
{
return parent::registerActions($settings);
}
};When your platform owns a ticket, mirror it into OpsIQ from your connector using the ticket ingest helper your connector inherits (create for a new ticket, add-reply for follow-ups). Emit and subscribe to the universal ticket events in your connector's subscribers() method, ticket.created, ticket.replied, ticket.updated, ticket.deleted. Auto-reply, escalation, SLA and CSAT all hook the same events, so you inherit them with no extra code.
A ticket is always for the customer, but the opening message may be written by staff: an agent opening a ticket on the customer's behalf, or reaching out proactively. Every helpdesk supports this, so it is part of the universal ticket.created contract rather than something each connector solves privately.
client (default) or admin. Omit it and the customer is assumed.
The staff id when author_type=admin. Never the customer id.
Agent or department display name. Falls back to "Staff".
The agent address. NEVER the customer one. A staff message under the customer e-mail is a reporting and audit error.
This is not cosmetic. Consumers read author_type to decide whose turn it is. A staff-written opening reported as client leaves auto-reply eligible to answer a message your own agent wrote, and makes your platform's echo of that opening look like a fresh customer message, which then lands as a duplicate and flips the ticket to answered. Map your platform's signal onto it in your connector's event normaliser, never in the consumers.
When an agent blocks a sender, that applies across every channel immediately (e-mail, chat, portal, widget and every connector twin) because the block is enforced centrally, before any connector sees the message. Your connector inherits it by doing nothing. There is no inbound work to implement and no way to get it wrong.
The optional half is outbound: telling your platform a customer was blocked here. Implement it only if your platform can express something equivalent.
Must include block_registry AND the class must implement BlockRegistryInterface. The flag is a claim; the interface is the guarantee. The registry requires both.
Receives kind (email|domain|ip), value, reason, admin_id, expires_at, site_key. Returns [result, detail?, remote_ref?].
Same payload, reversed. Must be idempotent. Unblocking something never blocked is noop, not an error.
For reconciliation, so drift is reported rather than discovered by a customer. Returns [result, blocked?].
Applied on your platform. Include remote_ref when you have an id worth recording.
Already in the requested state.
Your platform has no equivalent concept. NOT an error.
You could have done it and it went wrong. Include detail; it lands in the audit trail.
Declining is a correct answer. Many platforms have no "block this sender" concept and offer only ACCOUNT suspension, which stops billing, logins and services rather than just support mail. Mapping "an agent blocked a spam address" onto "close this client's account" would let one mis-clicked block terminate a paying customer's services. If that is the only lever you have, return unsupported and leave it alone.
Declining also covers the case where the platform can do it but will not let you. Check for an API, not a feature: a lever that exists only in the platform's admin UI is a lever your connector does not have.
Read connectors/zendesk/connector.php alongside this. It is short, and every branch below is a decision you will face too.
PUT /api/v2/users/{id} with suspended=true. A suspended end user's new requests divert to Suspended Tickets instead of opening one, genuinely the same idea as blocking a sender, and it stops no billing because Zendesk end users have none. Returns the user id as remote_ref.
Zendesk CAN suspend a whole domain, but only through the suspend: keyword in the Admin Center blocklist textarea, and no API writes that field. The feature exists; the lever does not.
No ticket-level IP block exists.
Zendesk cannot pre-suspend an address it has never seen. Nothing to do is not a failure, and the local block still stops the ticket.
REFUSED. Suspending staff would lock a colleague out of the helpdesk. A staff address reaching a blocklist is far more likely to be a mistake than an instruction, check the role before you act on it.
That last row is the one worth copying. The contract cannot stop you mapping a block onto something destructive, so each connector has to decide for itself what it will refuse. Refusing loudly, with a detail an operator can read, beats obeying.
Report honestly. Notice how few of those rows are ok. That is the correct outcome, not a gap: a domain block still works (it is enforced in core the moment it is written); it simply cannot be mirrored outward. Returning ok for something you did not do would tell an operator the block reached your platform when it never left OpsIQ.
It is written BEFORE you are called and stands whatever you return. You cannot prevent an operator blocking someone.
A throw is treated as unsupported and recorded. Return failed with a detail instead so the reason survives.
The same block may be announced more than once.
Fan-out is synchronous with the operator click. Queue slow work rather than holding the request open.
Never re-block into OpsIQ from your handler. The registry skips the originating connector, but a second hop would loop.
Every announcement is written to opsiq_block_registry_log (operation, kind, value, reason, admin, origin, connector slug, result, detail and timestamp) so an operator can see a block arrived from your platform rather than from an agent, and what each connector did about it.
Hand an attachments array to create()/addReply(). Each item carries the file in one of three shapes:
Base64 of the RAW file bytes, use for files behind auth (most inbound cases). OpsIQ decodes it and re-hosts the file for you. The most portable shape.
A public https URL (e.g. a Zendesk content_url). Must be https; passes an SSRF / allowlist check before it is stored.
A stored file reference you already wrote (what the native composer uploader produces).
Items also accept filename, mime_type and size_bytes. Caps: 12 MB/file, ~24 MB total, 10 files per call. Most platform read APIs return attachment filenames only (not bytes), so the reliable inbound pattern is: read the bytes where your code already runs (inside the platform, or from the webhook payload), base64 them, and ship them as content_b64 on the event.
Outbound (OpsIQ → your platform). When an agent attaches a file, the ticket.replied payload gives you the reply's files as stored_path items under the OpsIQ file store. Read them and push in your platform's own format, and check the platform docs, the encoding matters: WHMCS wants base64_encode(json_encode([[name,data]])) (JSON, not serialize); Zendesk uploads raw bytes to /uploads.json for a token then sets comment.uploads; Gmail sends a multipart/mixed RFC-822 message base64url-encoded in raw; Amazon SES inbound attachments need the S3 receive action (the SNS path caps at 150 KB).
If your platform is a separate app or database (a hosted SaaS, a remote WHMCS, a different DB on the same server), never write its tables directly: a cross-database write lands on whatever connection is active and silently misses the real rows. Always: outbound = call the platform's signed REST API (replies, status, department, deletes); inbound = the platform POSTs a signed webhook, your handleWebhook() verifies it and fires the matching ticket.* event. To stop a mirror loop, tag what you push with an origin marker (e.g. mirror_origin:'opsiq'); the platform echoes it on the webhook and your inbound handler skips its own echoes. Check OpsIQEvents::isMirroredEvent() at the top of every handler.
A reply moves status automatically, an agent reply → answered, a customer reply → customer_reply; mirror that the same way. For explicit changes subscribe to ticket.updated and read payload['changes'] (e.g. {status:'closed'}).
Status: OpsIQ's canonical set is open, customer_reply, answered, in_progress, pending, closed. Keep a small two-way map to your platform's vocabulary, and make sure your column actually accepts the values you write (an ENUM missing a value gets silently dropped to empty by some databases). Department: the OpsIQ department id is meaningless on your side, never send it. Send the descriptor (name, email and slug) and resolve it against your own departments by e-mail → name → slug, so “Billing Department” lands in your Billing department instead of general. Trigger on both ticket.escalated and a department_id change in ticket.updated.
If the customer chose a specific product when opening the ticket, stamp a hint so the agent sees a focused service card (with a one-click "view other products" modal for the rest). Pass any of these to create():
Preferred: the service id exactly as it appears in your IdentityProvider::lookupCustomerServices() list (each service's id). Unambiguous match.
A platform service-code, e.g. WHMCS S396 (service 396) / D11 (domain 11). OpsIQ decomposes the optional type-letter + id and matches your service list, with a type guard so a domain code never matches a product of the same id. Expose a matching ref on each service for an exact match.
A domain name; matched as a substring against each service's detail / domain.
You do not have to fill the six steps in by hand. Describe the connector in your own words and OpsIQ's AI drafts the whole specification, runs it through the same validator the wizard uses, and shows you the plan before anything is written to disk. There are two places to do it, and they produce the same package.
Open Connectors → + Add connector → Build connector. On step 1 you will see ✨ Build it for me. Type what the connector is for — the platform, what OpsIQ should read and what it should write, and who uses it — add the API root if you know it, and press it. The wizard fills every step from the draft, and you review and edit exactly as if you had typed it. On step 6 the same panel appears as ✨ Refine with AI, so you can ask for a change ("also read invoices") instead of editing fields.
Open the Ask OpsIQ copilot anywhere in the admin and say what you want. You never need to name an action or know the wizard exists.
For example: "Build me a connector for Trello. It should list my boards and lists, read cards, and create a card on a board. Trello uses an API key plus token." The copilot answers in a sentence and shows a Draft this connector card. Your message is the brief, so put the platform, the reads and the writes in it.
Nothing is written yet. The copilot drafts the specification, validates it, and replies with the plan: what the connector does, the actions it will expose (writes marked), the assumptions it made, and the questions you still have to answer — usually which credentials to supply. The draft is parked under an id and stays available for 24 hours.
The copilot shows a Build card naming the connector and its slug. This one writes: it publishes the package into /connectors/<slug>/. Confirm it and you get the path back, together with the setting you still have to fill.
The new connector is published but NOT enabled, and it holds no secrets. Open its settings, enter the API key or token, press Test, then Enable. Until you do, it does nothing.
A drafted specification goes through exactly the same validate() the wizard's Publish button uses. If it does not pass, the AI is given the errors and tries again, up to three times, and then refuses in the validator's own words. A draft that fails never becomes a package.
The draft names the authentication pattern and the settings fields; it never invents a key, token or secret. You fill those in afterwards on the connector's settings page.
Anything it could not know — your account id, which region, which of two endpoints your plan exposes — comes back as a question on the plan rather than a silent assumption.
The AI is told never to invent paths, but no model is perfect. A wrong path publishes as an action that fails its live test on the Actions step or the first time it runs — it is never a silent success.
What it produces is a normal Builder package: same generated files, same contract, same signature, editable in the wizard, deletable from the Connectors page. There is no separate "AI connector" kind.
Quality follows the model you configured under Settings → AI. A small, cheap model drafts a correct but plain connector and asks more questions; a stronger model gets more of the endpoints right first time. Change it under AI configuration; nothing else has to change.
manage_connectors — the copilot says so rather than offering a card that would fail when clicked.A connector that can sell — a store platform, a booking system, a payment gateway — declares which of its OWN operations answer OpsIQ's canonical commerce roles. Declare it and the connector appears under Settings → Client Chat → Selling through chat automatically; stop declaring and it disappears. There is no list to register on.
commerce_roles.jsonThe declaration lives in its own file at the package root — the presence of the file is the claim. It cannot live in connector_contract.json: that file is regenerated by the packaging tools and its schema rejects unknown keys, so a hand-added block would fail validation and then be overwritten.
{
"commerce": {
"roles": {
"catalog_search": { "operation": "acme_search_products", "transport": "http" },
"customer_lookup": { "operation": "acme_customer_lookup", "transport": "http" },
"quote": { "operation": "acme_quote_order", "transport": "http" },
"payment_methods": { "operation": "acme_payment_methods", "transport": "http" },
"order_get": { "operation": "acme_get_order", "transport": "http" },
"order_create": { "operation": "acme_create_order", "transport": "http",
"recovery": "acme_get_order" }
},
"customer_ordering": {
"enabled": true,
"version": 1,
"mode": "direct_order",
"audience": "clients_only",
"account_flow": "existing_client",
"payment_flow": "connector_methods",
"identity_parameter": "external_customer_id",
"quantity_parameter": "quantity",
"label": "Acme Store",
"checkout_hosts": [],
"transaction_kind": "purchase",
"decision_mode": "immediate",
"payment_timing": "on_confirmation",
"reversibility": "reversible",
"cancellation_flow": "platform_only",
"fulfilment_presence": "remote_delivery",
"notify_flow": "platform_automatic",
"customer_fields": {"name": "required", "email": "required", "address": "required", "phone": "optional"},
"client_tools": ["catalog_search", "catalog_get", "quote"],
"account_timing": "before_quote"
}
}
}OpsIQ never infers a role from an action's name. A role that is not declared does not exist — declaring is the whole contract.
Every mapped operation must exist in your actions.json. A typo declares a capability that cannot run, and it surfaces to a customer as "I can check that for you" followed by nothing.
Read roles (catalog, availability, quote, order lookup) must map to operations that change nothing on your platform.
Mapping order_create to a raw table insert — record.create, db.insert, recordCreate, any spelling, any separator — is rejected structurally. A row written directly bypasses your platform's pricing, stock locking and confirmation mail, producing an order your own system does not fully believe in.
An idempotent lookup that answers "did my write land?". The most dangerous timeout is the one after your platform may already have created the order; without a recovery lookup the only options are to retry blind or to lose it.
A package that talks directly to a payment provider must also declare payment_profile (currencies, countries, methods and environment — an unstated environment is how a test integration takes a live payment), webhook_verify (the provider's real signature scheme; a generic secret-compare is refused) and event_map (provider events onto canonical ones). A merchant connector that only implements record_payment receives already verified canonical payment evidence; it must not pretend to be the gateway.
A merchant connector and a payment-gateway connector are different contracts. Under Connected store customer ordering, choose the deepest mode the platform can prove. The choice is packaged inside signed commerce_roles.json; Store and Client Chat re-read it at execution time. Removing a role or disabling/uninstalling the connector therefore invalidates a previously rendered proposal instead of leaving stale authority behind.
catalog_onlyMaps catalog_search or catalog_get. OpsIQ may search and explain products, but it cannot show an executable order or checkout confirmation. Every package remains at this truthful default until its own typed quote and checkout/order actions pass the deeper contract and Marketplace certification; never infer transactional support from a platform name.
platform_checkoutAlso maps quote and platform_checkout. The merchant action—not OpsIQ core—returns checkout_url, checkout_reference and the canonical quote. The URL must be HTTPS, its hostname must match customer_ordering.checkout_hosts or the HTTPS host derived from checkout_host_setting, and the quote may live for no more than 15 minutes. A product permalink, locally assembled cart URL or return URL is not a merchant-issued checkout capability.
direct_orderAlso maps quote, order_create and order_get, with order_create.recovery. Core refreshes the quote immediately before execution, supplies the idempotency key, and asks the recovery operation after every unknown outcome before any retry. When payment_flow=opsiq_gateway, it must additionally map record_payment with an authoritative recovery/read-back operation. OpsIQ actively verifies the gateway transaction, matches amount, currency, merchant and order reference, writes the provider reference once, then reads the merchant invoice/order back. A mark_invoice_paid status toggle is rejected because it carries no payment evidence. The create action must invoke the platform's own pricing, stock and order business logic; raw database writes are refused.
When OpsIQ owns the payment, a chat customer must reach email_otp before an order is created — OpsIQ emails a 6-digit code and asks for it. This is not something a connector opts out of; it is the assurance floor the execution kernel demands for order_create.
An operator may accept an unverified address ONLY where your connector declares fulfilment_presence: customer_present. A hotel guest must arrive, so a wrong address misdirects a receipt and the room is still there. Declare remote_delivery — shipped, provisioned, downloaded — and verification is required whatever the operator sets, because value leaves on the strength of that address alone. Setting minimum_assurance or reversibility: irreversible also removes the operator's ability to skip it.
Thirty minutes by default, operator-configurable from 5 minutes to 24 hours. The customer sees a live countdown rendered in their own timezone, not the operator's. An expired code says so plainly and offers a new one rather than reporting an invalid code — a customer typing a correct-but-old code has made no mistake, and telling them they have sends them round the same loop.
Name and email are always required and are collected first. Declare address, phone and company as required or optional to fit the business: a shop that ships parcels declares address required; a hotel declares phone required, since a guest it cannot call has no booking contact. The assistant asks for them in the conversation before quoting, and OpsIQ refuses to place an order that lacks a required field. The builder writes the normalised map out, baseline included, so the contract on disk is explicit.
at_order (default) lets the order write create a first-time buyer’s account. Declare before_quote when your platform prices per account — WHMCS taxes by the client’s own profile and quotes in the client’s currency — and OpsIQ creates the account through your customer_create action as soon as the required fields are known, then asks the quote for that account, so the confirmation card carries the total you will actually invoice. Needs account_flow: connector_signup.
With Create orders on, the assistant never reads a pasted catalog. It calls three tools — commerce_catalog_search (an empty query is an overview of the product families; results beyond the limit are listed by name), commerce_catalog_get for one item in full, and commerce_quote, which mints the signed confirmation card server-side through the same walls the connector path has always had. One tool per verb, your connector as a parameter, so a store with six connectors gets three tools rather than eighteen. client_tools restricts the default; absent means every mapped one, and a catalog_only connector never quotes. Confirmation is never a tool: the card’s button on the web, the exact CONFIRM command on a channel, and nothing a model says spends money.
id, name, a customer-safe summary, a category or product family (this is how a customer’s word finds an item whose name is a code), currency, unit_amount_minor, available, and input_schema naming the fields an order needs. Search scores the customer’s words against name, family, cycle and summary.
Return {"success":false,"error":"…","missing":["domain"],"retryable":true} when a value is wrong or missing. A refusal that names missing or retryable reaches the customer verbatim; a bare failure stays generic so nothing internal leaks.
When the operator turns on Geo currency (Client Chat → Behaviour), the customer reads prices in their own currency on every surface — chat text, the web card, the channel text card and the storefront’s opening currency — using the platform’s own FX store. Your price is never substituted: the card shows the visitor’s figure beside the store total, and the gateway processes exactly the amount it displays. Pause all selling (Settings → Commerce) is the kill switch: catalog, quotes and look-ups stay open; proposing and confirming stop on every channel.
The package’s seal is broken: a file was edited after signing. Re-publish the package. An installed marketplace copy is never edited in place; update it from the marketplace panel.
The kill switch is on. Settings → Commerce → Pause all selling.
The channel is not ticked under Where customers can buy. The server log names the channel.
The quote tool refused. Every call is logged as [opsiq][commerce][client_tool] with the reason: a wrong item id, a field the item does not declare, a taken domain, or the merchant’s own refusal. Read the log before trusting the assistant’s paraphrase.
The page belongs to another workspace. Each website widget belongs to one workspace, and the store connector must be enabled there.
“Tell me a little more about what you need” means the AI provider call itself failed; AI History shows the exact error under that turn, and the tools were never reached.
The worker recycles on code change within a minute, but a conversation replays its last card. Start a new conversation to test.
Check that the geo-IP database is configured (Client Chat → Geo) and that the visitor’s currency has an FX rate; with no rate OpsIQ shows the store price rather than a wrong number.
A quote carries unit_amount_minor, quantity and total_amount_minor, and it is tempting to treat the third as derivable from the first two. It is not, and assuming it is has already cost a customer real money.
quantity is what the CUSTOMER chose — one room, one licence, one policy. Your multiplier can be something OpsIQ never sees: nights, seats, billing cycles, distance, weight, tiers. A hotel quotes one room for three nights as quantity 1, unit 105,000, total 315,000. OpsIQ multiplied unit by quantity to price a confirmation card, showed a guest 105,000, and then charged the 315,000 the merchant actually returned. Agreeing to one figure and being charged another is the worst thing this contract can do.
total_amount_minor is the only figure OpsIQ shows, signs, charges and reconciles against. unit_amount_minor is a display detail on the line. If your total is not exactly what you want charged, your quote is wrong — OpsIQ will not correct it, because a total that has been helpfully adjusted is one you never agreed to honour.
Return the all-in figure. Apply your own nights, tiers, discounts, taxes and fees before you answer. If your line does not reconcile — unit times some whole number never equals your total — OpsIQ treats the whole thing as one line at its real price rather than inventing a breakdown that reconciles to nothing.
The declaration above began as a shop's declaration: buy a thing, pay now, it is yours, you may cancel. Every one of those four is an assumption some real business does not share. A bank moving money cannot undo it. An insurer cannot say "confirmed" until an underwriter has looked. A tradesman invoices afterwards. A clinic bills someone who is not the patient. With no way to say so, those businesses either misrepresent their own process to their own customers or cannot connect at all.
So a transactional connector answers six more questions. Every one defaults to the strict reading — saying nothing is always safe and never permissive, because saying nothing is what an author does when they have not considered the question.
transaction_kindpurchase, booking, subscription, bill_payment, transfer, application, top_up, renewal. Vocabulary rather than behaviour: it decides the word your customer reads. Calling a wire transfer an "order" makes the assistant sound like it does not understand the business it speaks for, and no amount of correct plumbing recovers from that. Defaults to purchase.
decision_modeimmediate or deferred. Choose deferred for anything that goes to underwriting, credit assessment, references, admissions or a committee. OpsIQ then says submitted rather than confirmed, and hands over the reference to ask about it. Telling someone their application is confirmed while it sits with a human is the most damaging thing a chat assistant can do for a regulated business, and it is the default behaviour of every retail-shaped flow. Defaults to immediate.
payment_timingon_confirmation, deposit_then_balance, invoice_later or no_payment. This decides whether OpsIQ opens a payment page at all, so it cannot be inferred from payment_flow — that says who takes the money, this says whether and when. Work you invoice afterwards, and applications that cost nothing to submit, end at the confirmation instead of reaching a gateway list that is empty or wrong.
reversibilityreversible or irreversible. The most important thing a financial connector says. A room can be released and a parcel can come back; a completed transfer cannot — there is no undo, the money is at the other end, and the only remedy is asking a stranger to return it. Declaring irreversible automatically forces cancellation_flow to none and forbids any operator setting from skipping identity verification, whatever else this declaration says. Two fields disagreeing is not a state to resolve at runtime by whichever is read first. Defaults to reversible.
cancellation_flownone, platform_only or connector_cancel. The cancel roles already existed with no rule about who could reach them, and the two wrong guesses fail in opposite directions: guess open and a chat message cancels a paid booking with no fee quoted; guess closed and a customer who wants to cancel is told to phone. connector_cancel additionally requires cancellation_quote and order_cancel with a recovery — OpsIQ never cancels before saying what it costs. Defaults to none.
fulfilment_presencecustomer_present or remote_delivery. Whether an unverified email address can cost anybody anything. A hotel guest must arrive, so a wrong address misdirects a receipt and the room is still there; a posted parcel, a provisioned server or a download link leaves on the strength of that address alone. This is what makes an operator’s "skip email verification" setting available at all, and it is declared by you rather than chosen by them — so a hotel’s reasoning can never be inherited by a connector that ships goods. Defaults to remote_delivery.
minimum_assurance and disclosure (optional)minimum_assurance lets you demand more identity proof than OpsIQ requires, never less — a bank requiring a step-up for a transfer is exercising the contract. Setting it also removes an operator’s ability to skip verification for your connector, because a merchant’s own risk decision outranks an operator’s convenience. disclosure is wording shown before the confirm button, for a rate, a fee or a cooling-off right you must present; without it, regulated businesses smuggle required wording into a product name.
notify_flowplatform_automatic, platform_triggered or none. When OpsIQ takes the payment your own checkout never runs, so whatever it normally emails never fires. Recording the payment marks the order paid; it obliges no platform to tell anybody. platform_triggered requires the order_notify role with a recovery, and OpsIQ asks only after the payment read-back proves the money is recorded. Declaring none makes the OpsIQ-side confirmation compulsory, because otherwise a paying customer hears nothing at all. Defaults to none.
None of these were designed around. Each is the contract answering honestly for a different industry, with OpsIQ knowing nothing about any of them.
Hotel booking immediate deposit_then_balance reversible -> payment page, "confirmed", identity may be waived Online shop purchase immediate on_confirmation reversible -> payment page, "confirmed", identity always verified Bank transfer immediate on_confirmation IRREVERSIBLE -> payment page, no cancel route, never waived Insurer application DEFERRED no_payment reversible -> no payment page, "submitted", never "confirmed" Utility bill_payment immediate on_confirmation IRREVERSIBLE -> payment page, nothing to give back Clinic booking immediate invoice_later reversible -> NO payment page, billed afterwards Tradesman booking immediate invoice_later reversible -> NO payment page, invoiced on completion Telecom top_up immediate on_confirmation IRREVERSIBLE -> payment page, final once sent University application DEFERRED no_payment reversible -> no payment page, decision follows
After a native Storefront payment is actively verified and committed, OpsIQ emits payment.completed with order_id, payment_id/provider_ref, gateway, exact amount_minor, ISO currency, customer, line items, channel and paid_at. A merchant connector must persist that evidence through record_payment and read it back; a hosted-checkout connector consumes its own authoritative paid event and must not receive a duplicate payment write.
The model may select a declared product and quantity, but it cannot choose an operation name, mint a checkout URL or create merchant state from text. The customer receives an exact signed card and must press its confirmation button. That confirmation is bound to the workspace, connector, item, quantity, quote, currency, thread and expiry.
WhatsApp, Messenger, Instagram, Telegram, LINE, SMS and X use the provider-verified channel account as the customer identity. The proposal is signed to that channel account and confirmation still runs through the same fresh quote, stock, idempotency, payment and recovery controls. A social customer uses the exact one-time confirmation action rendered in their conversation; ordinary prose such as “yes” is never order authority.
Native orders are indexed by an opaque channel identity, so the AI can answer “where is my order?” without asking for an email or order number. For connected-store history, link the channel identity to the workspace CRM/client record and implement authoritative customer/order lookup in the connector. Customer context providers receive that stored link; they must not choose an account from a display name or an email typed into chat. With one matching order the AI answers directly; with several it summarizes the matches and asks which one; with none it says no history is linked.
Core contains no WHMCS, hotel, SaaS, store, bank, product, route or vendor branch. The quote action’s typed parameters are the customer form and AI slot schema. A booking connector can declare dates and guests; a billing connector can declare a cycle; a future enterprise connector can declare its own safe fields. OpsIQ sanitizes primitive controls and sends the collected values only to the mapped connector action.
{
"action_id": "acme_customer_quote",
"scope": "client",
"is_destructive": false,
"parameters": [
{"name":"external_customer_id","type":"string","required":true},
{"name":"item_id","label":"Product","type":"string","required":true},
{"name":"quantity","label":"Quantity","type":"integer","required":true,"minimum":1},
{"name":"cycle","label":"Billing cycle","type":"select","required":false,
"options":[{"value":"monthly","label":"Monthly"},{"value":"annual","label":"Annual"}]}
]
}For clients_only, set customer_ordering.identity_parameter to the action parameter that receives the connector’s external customer id. This field is never shown to a customer and any caller-supplied value is removed; OpsIQ injects only the id from a verified connector link. Guest checkout leaves it empty. A typed email is proof for a declared guest lookup, not a login and not purchase authority.
Grouped domains: signed-in customer accounts and connector configuration belong to the group-primary portal workspace. However, the identity token must be signed for the exact member site that embeds the widget, using that member’s webhook secret. OpsIQ verifies that surface first and only then resolves commerce and the linked customer through the group primary. Never replace the member site key with the primary key and never copy the primary secret to a member site.
{
"success": true,
"data": {"items":[{
"id":"42", "name":"Example product", "summary":"Customer-safe summary",
"currency":"USD", "unit_amount_minor":2500, "available":true,
"selection":{"item_id":"42"}
}]}
}{
"success": true,
"data": {
"quote_id":"opaque", "currency":"USD",
"unit_amount_minor":2500, "total_amount_minor":5000,
"selection":{"item_id":"42","quantity":2},
"expires_at":"2026-08-31T14:05:00Z"
}
}The platform-checkout response repeats the valid canonical quote and adds an HTTPS checkout_url. Core refreshes the quote at confirmation and compares currency, total and stable selection exactly. The connector translates its platform response into these envelopes; core never translates vendor fields or constructs the merchant URL.
Payment capability alone does not put a gateway in front of customers. Enable the Native Store payment gateway block in Connector Builder. It adds an explicit versioned contract, maps checkout creation and active payment lookup, and allowlists the provider-hosted checkout domains. Once the connector is installed, enabled and selected under Commerce settings, the same gateway appears in the public Store, Store modal, client-chat checkout and autonomous checkout. No provider slug is hardcoded.
{
"commerce": {
"roles": {
"checkout_create": { "operation": "acme_checkout_create", "transport": "http",
"recovery": "acme_payment_status" },
"payment_status": { "operation": "acme_payment_status", "transport": "http" },
"payment_profile": { "operation": "acme_payment_profile", "transport": "http" },
"webhook_verify": { "operation": "acme_webhook_verify", "transport": "http" },
"event_map": { "operation": "acme_event_map", "transport": "http" },
"payment_refund": { "operation": "acme_refund", "transport": "http",
"recovery": "acme_refund_status" }
},
"storefront_gateway": {
"enabled": true, "version": 1, "label": "Acme Pay",
"checkout_hosts": ["checkout.acmepay.com", "*.acmepay.com"]
}
}
}The checkout action maps checkout_url and, when the provider has one, session_id. The URL must be HTTPS, contain no credentials, and match an allowlisted host.
The status action performs a fresh provider API lookup and maps paid as a real boolean, amount_minor as an integer, currency as a three-letter ISO code, and provider_ref. A return URL, query string, client payload, or connector-supplied “confirmed” instruction is never payment truth.
If the gateway supports refunds, map payment_refund and its recovery action. Refund creation returns strict accepted and completed booleans plus provider_ref; recovery performs a provider lookup and returns status. Without both actions, OpsIQ does not advertise connector refunds.
The connector never writes an OpsIQ order status. OpsIQ compares the returned amount and currency exactly and records the provider reference; only then does core perform the provider-verified transition. Manual bank transfer remains the only flow a named agent can approve.
commerce_roles.json. Publishing still uses the normal Marketplace review and signature process; this contract never bypasses package verification or makes a connector non-uninstallable. Verify any package by hand with php tools/verify_commerce_contracts.php.http for a remote API or bridge for a named operation on a deployed bridge (see the NO-API pattern below). Roles are transport-agnostic; the runtime just needs the transport stated so it can version-pair a bridge.The commerce contract above does not require a connector package. If your platform is your own — a custom back office, an internal API, a system nobody ships a connector for — you can reach the same selling machinery with the two tools you already use to integrate anything else: custom Actions (your HTTP endpoints, defined on the Actions page) and Triggers (event webhooks). Same contract, same card, same identity assurance, same payment kernel, same receipts. The only thing missing is the package, because there is no third-party code to sign.
You build one custom action per commerce role — each is a plain HTTPS endpoint on your side, defined under AI & Automation → Actions with its URL, auth header and parameters. Then you save one declaration that maps roles to those actions. From that moment your store appears in chat exactly like a connector-backed one: the AI quotes from your quote action, the confirmation card renders, the customer verifies their email, the order kernel calls your order action with an idempotency key, OpsIQ takes payment through the workspace gateways, and your record-payment action books it. Nothing about the customer experience says "custom".
Save this JSON as the workspace setting commerce_custom_integration (Settings → advanced settings, or via the REST settings API). It is the same shape as a package’s commerce_roles.json commerce node, with action naming your custom action ids:
{
"enabled": true,
"roles": {
"catalog_search": { "action": "acme_catalog" },
"quote": { "action": "acme_quote" },
"order_get": { "action": "acme_order_get" },
"customer_create": { "action": "acme_customer_create",
"recovery": "acme_customer_by_email" },
"order_create": { "action": "acme_order_create",
"recovery": "acme_order_by_key" },
"record_payment": { "action": "acme_record_payment",
"recovery": "acme_payment_by_key" }
},
"customer_ordering": {
"enabled": true, "version": 1,
"mode": "direct_order",
"audience": "guests_and_clients",
"account_flow": "connector_signup",
"payment_flow": "opsiq_gateway",
"label": "Acme Store",
"identity_parameter": "client_identifier",
"quantity_parameter": "quantity",
"transaction_kind": "purchase",
"fulfilment_presence": "remote_delivery",
"notify_flow": "platform_automatic"
}
}Finally, add custom_commerce to the connectors enabled for selling under Settings → Client Chat → Selling through chat. Admission is re-checked on every request, and it refuses with named reasons rather than silently hiding your store: a role your mode requires that maps to nothing, a write role without a recovery action (§15.7 — a write whose outcome cannot be re-asked is refused), an action that has been deleted or disabled since you saved.
Respond {"success": true, "data": { ... }} — or {"success": false, "error": "a sentence a customer may read"}. Your action’s response success path should point at the envelope.
Return quote_id, product_name, quantity, unit_amount_minor, total_amount_minor, currency, selection, selection_summary, expires_at. Everything in the "your total is the only figure that moves money" section above applies verbatim: taxes, fees and multipliers go INTO your total, because your total is what is signed, shown and charged.
You receive idempotency_key, the signed total_minor and currency, the verified customer_email, and your own quote parameters. Store the key with the order; if you have already created an order for it, return that order instead of a second one. Verify the money — if your system prices the order differently than the signed total, refuse retryably rather than under-charging. Return a reference your platform recognises.
order_by_key receives the idempotency key and answers {"found": true, "order": {...}} or {"found": false}. found:false is a promise — OpsIQ may retry the write on the strength of it. A status feed or a recent-orders list is not an answer about one write.
Receives the gateway transaction id as the idempotency key plus your order reference, after OpsIQ has actively verified amount and currency with the gateway. Mark the order paid through your platform’s own logic — fire your own emails, reduce your own stock. Return platform_notified: true if your platform emails the customer itself.
Any parameter you declare on your QUOTE action (beyond the identity parameter) that the AI has not collected is rendered on the confirmation card as an input the customer fills themselves — a domain, a date, a seat. Label them well; the label is what the customer reads.
Two events fire on the shared event bus, so your webhooks and automations hear every chat sale wherever it executed:
commerce.order.createdThe moment the order lands on the merchant side, before payment — reference, connector (or custom_commerce), amount, currency, customer email, thread id.
commerce.payment.confirmedExactly once per order, when the gateway actively verifies the payment. It rides the same claim that prevents duplicate receipts, so it cannot double-fire your webhook.
The custom integration is workspace configuration: it serves YOUR store, on YOUR workspace. The moment you want to distribute the integration — other workspaces, the marketplace, versioning, signing, paid installs — package the same actions and the same declaration as a connector. The contract does not change; only the wrapper does.
Plenty of real platforms ship no REST API at all. A hotel CMS, an old billing system, a bespoke internal tool. You can still write a complete OpsIQ connector for one: the connector ships a single PHP file that the operator drops into their own public webroot, and that file IS the API. This page is the whole pattern, with the rules that make it safe to run and the reason behind each rule.
A normal connector calls someone else's API. A bridge connector brings its own. Nothing else changes: the same actions, the same context providers, the same identity contract, the same package layout.
It lives in your package at bridge/opsiq-<platform>-bridge.php. It talks to the platform's database directly, or boots the platform's framework, or both. It answers JSON.
Next to the platform's own index.php. No platform code is modified, no plugin is installed, nothing to maintain across platform upgrades.
Your settings.json declares webhook_help.snippet_template. The connector page renders it as a copyable file with their live settings already substituted, so there is nothing to hand-edit.
Your Client.php sends GET requests with the shared key in an X-Opsiq-Bridge-Key header. The base URL setting is the platform site root.
api_key when enabled, sends it as X-Opsiq-Bridge-Key, and binds that same saved value into OPSIQ_BRIDGE_KEY in the copyable file. Hand-author only when your platform is none of those, or when you need behaviour the generated bridge does not cover. A hand-written bridge is safe from the wizard: it only overwrites a bridge file carrying its own marker.This file sits in a public webroot behind one shared key. That single fact drives every rule below. Do not relax any of them to make your bridge simpler.
Not a WHERE clause, not an ORDER BY fragment, not a "just this once" raw query parameter. The caller names a table, a column and a value; your file builds the statement. The moment a caller can contribute SQL text, one shared key becomes arbitrary database execution.
Identifiers cannot be bound as parameters, so they have to be checked instead. Read the real table and column list for THIS database and refuse anything not on it. An identifier that is not a real object of this schema then cannot reach a query at all — which is what makes it safe to expose every table.
Without exception, including values inside a search. Validated identifiers plus bound values is the pair that makes the surface total and the injection surface nil.
See the next block. This is the rule people most want to skip.
Match on column NAME: password, remember_token, secret, api_key, private_key, salt, token. Replace the value with a placeholder on the way out. Refuse the write entirely on the way in — writing a raw password hash is not an operation, it is a footgun. Send the operator to the platform's own password flow.
Never a bulk delete, never a delete by filter. A bulk removal is how a database dies. If someone genuinely needs one, they can do it in the platform.
Clamp the limit parameter with a hard ceiling. A runaway query must not be able to dump the database through a chat message.
An unconfigured bridge answers 403 to everything. A bridge that is helpful before it is configured is a bridge that was helpful to a stranger.
hash_equals, never ==. The key goes in X-Opsiq-Bridge-Key, not the query string, so it stays out of access logs, proxy logs and Referer headers.
One method, one shape, nothing to smuggle in a body. Everything the bridge does is expressible as a GET with validated parameters, and OpsIQ is the only caller.
This is the rule that gets argued with, so here is the reasoning in full. The assistant should be able to SEE the whole platform: that is what makes it useful, and a read cannot destroy anything. Writes are different. This file sits in a public webroot behind ONE shared key. If that key leaks, an unrestricted write surface makes the leak equivalent to full database control — a new admin user, an emptied bookings table. An allow-list means a leaked key still cannot reach a table the operator never enabled.
/* ── WRITE ALLOW-LIST — which tables the assistant may CHANGE here. * * READS are unrestricted: the assistant can see every table in the platform. * WRITES are limited to this list, because this file sits in a PUBLIC webroot * behind ONE shared key — an allow-list means that even a leaked key cannot * reach a table you never enabled (no new admin users, no emptied bookings). * * Comma-separated table names. Add tables as you need them — e.g. append * ',pages,posts' to let the assistant edit site content. Set it to '*' to * allow every table, deliberately. Empty falls back to the hotel defaults. ── */ const OPSIQ_WRITE_TABLES = 'ht_bookings,ht_booking_rooms,ht_booking_addresses,ht_rooms,ht_room_types,ht_customers,customers';
Two details in the check below are easy to get wrong. The table name arrives already RESOLVED, carrying the install's table prefix, while an operator writes the allow-list unprefixed because that is what they would naturally type. Compare both ways or a prefixed install silently allows nothing and every write breaks. And the refusal must explain itself, because the person reading it is an admin in a chat window, not a developer with a stack trace.
/** Tables a WRITE may touch. Empty = the built-in defaults. */
$writeAllowed = static function (string $table) use ($prefix): bool {
$raw = trim((string)(defined('OPSIQ_WRITE_TABLES') ? OPSIQ_WRITE_TABLES : ''));
if ($raw === '') $raw = 'ht_bookings,ht_booking_rooms,ht_rooms,ht_customers,customers';
if (trim($raw) === '*') return true; // explicit opt-in to everything
$bare = ($prefix !== '' && stripos($table, $prefix) === 0) ? substr($table, strlen($prefix)) : $table;
foreach (explode(',', $raw) as $t) {
$t = trim($t);
if ($t === '') continue;
if (strcasecmp($t, $table) === 0) return true;
if (strcasecmp($t, $bare) === 0) return true;
if ($prefix !== '' && strcasecmp($prefix . $t, $table) === 0) return true;
}
return false;
};
/** One refusal, one explanation — used by every write op. */
$requireWritable = static function (string $table) use ($writeAllowed): void {
if ($writeAllowed($table)) return;
opsiq_bridge_out(['success' => false, 'error' =>
'write_not_allowed: "' . $table . '" is not in this bridge\'s write allow-list. '
. 'Reads are unrestricted. To permit writes here, add the table to OPSIQ_WRITE_TABLES '
. 'in opsiq-botble-bridge.php (or set it to "*" to allow every table).'], 403);
};Four checks, in this order, before anything touches data. Copy the order as well as the checks.
<?php
declare(strict_types=1);
/* ── EDIT THIS: a long random secret (40+ chars). Empty = bridge OFF. ── */
const OPSIQ_BRIDGE_KEY = '';
header('Content-Type: application/json; charset=utf-8');
header('Cache-Control: no-store');
function opsiq_bridge_out(array $payload, int $code = 200): void
{
http_response_code($code);
echo json_encode($payload, JSON_UNESCAPED_SLASHES);
exit;
}
/* 1. Fail closed. An unconfigured bridge answers nothing to anyone. */
if (OPSIQ_BRIDGE_KEY === '' || strlen(OPSIQ_BRIDGE_KEY) < 24) {
opsiq_bridge_out(['success' => false, 'error' => 'bridge_not_configured'], 403);
}
/* 2. One method. */
if (strtoupper((string)($_SERVER['REQUEST_METHOD'] ?? '')) !== 'GET') {
opsiq_bridge_out(['success' => false, 'error' => 'method_not_allowed'], 405);
}
/* 3. Constant-time key comparison, key from a header (never the query string). */
$given = (string)($_SERVER['HTTP_X_OPSIQ_BRIDGE_KEY'] ?? '');
if ($given === '' || !hash_equals(OPSIQ_BRIDGE_KEY, $given)) {
opsiq_bridge_out(['success' => false, 'error' => 'forbidden'], 403);
}
/* 4. Only now read credentials and connect. */This is the piece that turns "the assistant can reach any table" from reckless into safe. Resolve the caller's table name against the real schema, tolerate a missing or extra table prefix, and return null for anything else. Everything downstream then works with a name that provably exists.
/** Real tables in THIS database — the allow-list, straight from the DB. */
$allTables = static function () use ($pdo, $db): array {
static $cache = null;
if ($cache !== null) return $cache;
$st = $pdo->prepare('SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = ? ORDER BY TABLE_NAME');
$st->execute([$db]);
return $cache = array_map('strval', $st->fetchAll(PDO::FETCH_COLUMN));
};
/** Resolve a caller-supplied table name to a REAL one, or null. */
$resolveTable = static function (string $name) use ($allTables, $prefix): ?string {
$name = trim($name);
if ($name === '' || !preg_match('/^[A-Za-z0-9_]+$/', $name)) return null;
$tables = $allTables();
foreach ($tables as $t) if (strcasecmp($t, $name) === 0) return $t;
/* Tolerate a missing or extra table prefix. */
foreach ($tables as $t) {
if (strcasecmp($t, $prefix . $name) === 0) return $t;
if ($prefix !== '' && strcasecmp($prefix . $t, $name) === 0) return $t;
}
return null;
};
/** Column introspection: table => [column => true]. Cached per request. */
function opsiq_bridge_columns(PDO $pdo, string $db, string $table): array
{
static $cache = [];
if (isset($cache[$table])) return $cache[$table];
$stmt = $pdo->prepare('SELECT COLUMN_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ?');
$stmt->execute([$db, $table]);
$cols = [];
foreach ($stmt->fetchAll(PDO::FETCH_COLUMN) as $c) $cols[strtolower((string)$c)] = true;
return $cache[$table] = $cols;
}
/** Columns whose VALUES must never leave the platform. */
$secretCol = static function (string $c): bool {
return (bool)preg_match('/(^|_)(password|remember_token|secret|api_key|private_key|salt|token)($|_)/i', $c);
};
/** Columns a write may never touch — auth material. */
$writeBanned = static function (string $c): bool {
return (bool)preg_match('/(^|_)(password|remember_token)($|_)/i', $c);
};
/** Strip secret values from a row before it leaves the server. */
$redact = static function (array $row) use ($secretCol): array {
foreach ($row as $k => $v) if ($secretCol((string)$k)) $row[$k] = '[redacted]';
return $row;
};Note what is bound and what is validated. The filter column is checked against the real column list and then interpolated as an identifier; its value is bound. The limit is clamped. Rows are redacted on the way out. The update refuses the primary key and any auth column, and stamps updated_at when the table has one.
case 'query': {
$t = $resolveTable((string)($_GET['table'] ?? ''));
if ($t === null) opsiq_bridge_out(['success' => false, 'error' => 'unknown_table'], 404);
$cols = opsiq_bridge_columns($pdo, $db, $t);
if (!$cols) opsiq_bridge_out(['success' => false, 'error' => 'unknown_table'], 404);
$sql = "SELECT * FROM `$t` WHERE 1=1";
$args = [];
/* Equality filter: column must be REAL, value is bound. */
$wc = strtolower(trim((string)($_GET['where_column'] ?? '')));
if ($wc !== '') {
if (!isset($cols[$wc])) opsiq_bridge_out(['success' => false, 'error' => 'unknown_column: ' . $wc], 400);
$sql .= " AND `$wc` = ?";
$args[] = (string)($_GET['where_value'] ?? '');
}
/* Ordering: column validated, direction from a fixed pair. */
$ob = strtolower(trim((string)($_GET['order_by'] ?? '')));
if ($ob !== '' && isset($cols[$ob])) {
$dir = strtoupper(trim((string)($_GET['order'] ?? 'DESC'))) === 'ASC' ? 'ASC' : 'DESC';
$sql .= " ORDER BY `$ob` $dir";
} elseif (isset($cols['id'])) {
$sql .= " ORDER BY `id` DESC";
}
/* Hard row cap. */
$lim = (int)($_GET['limit'] ?? 25);
if ($lim < 1) $lim = 25;
if ($lim > 200) $lim = 200;
$off = max(0, (int)($_GET['offset'] ?? 0));
$sql .= " LIMIT $lim OFFSET $off";
$st = $pdo->prepare($sql);
$st->execute($args);
$rows = array_map($redact, $st->fetchAll());
opsiq_bridge_out(['success' => true, 'data' => [
'table' => $t, 'returned' => count($rows), 'rows' => $rows,
]]);
}case 'record.update': {
$t = $resolveTable((string)($_GET['table'] ?? ''));
if ($t === null) opsiq_bridge_out(['success' => false, 'error' => 'unknown_table'], 404);
$requireWritable($t); // the allow-list, before anything else
$cols = opsiq_bridge_columns($pdo, $db, $t);
$pk = $primaryKey($t);
$id = (string)($_GET['id'] ?? '');
if ($id === '') opsiq_bridge_out(['success' => false, 'error' => 'id_required'], 400);
$set = json_decode((string)($_GET['set'] ?? ''), true);
if (!is_array($set) || !$set) opsiq_bridge_out(['success' => false, 'error' => 'set_json_required'], 400);
$frag = []; $args = [];
foreach ($set as $col => $val) {
$col = strtolower(trim((string)$col));
if (!isset($cols[$col])) opsiq_bridge_out(['success' => false, 'error' => 'unknown_column: ' . $col], 400);
if ($writeBanned($col)) opsiq_bridge_out(['success' => false, 'error' => 'refused: "' . $col . '" is auth material - change it through the platform own password flow, never by direct write.'], 400);
if ($col === $pk) opsiq_bridge_out(['success' => false, 'error' => 'refused: the primary key cannot be rewritten.'], 400);
if (is_array($val) || is_object($val)) $val = json_encode($val, JSON_UNESCAPED_SLASHES);
$frag[] = "`$col` = ?";
$args[] = ($val === null) ? null : (string)$val;
}
if (isset($cols['updated_at']) && !isset($set['updated_at'])) $frag[] = '`updated_at` = NOW()';
$before = $pdo->prepare("SELECT * FROM `$t` WHERE `$pk` = ? LIMIT 1");
$before->execute([$id]);
$prev = $before->fetch();
if (!$prev) opsiq_bridge_out(['success' => false, 'error' => 'not_found'], 404);
$args[] = $id;
$up = $pdo->prepare("UPDATE `$t` SET " . implode(', ', $frag) . " WHERE `$pk` = ? LIMIT 1");
$up->execute($args);
opsiq_bridge_out(['success' => true, 'data' => [
'table' => $t, 'id' => $id, 'changed' => $up->rowCount(),
'before' => $redact(array_intersect_key($prev, $set)),
]]);
}Platform versions differ. Columns move, get renamed, or are absent. A bridge that assumes one schema works on one install. Introspect and adapt instead: select only the columns that exist here, tolerate the table prefix, and try the plausible spellings of a reference.
/* Only ever select columns that exist on THIS install. */
$pick = static function (array $cols, array $wanted, string $alias = 'b'): string {
$out = [];
foreach ($wanted as $c) if (isset($cols[$c])) $out[] = "`$alias`.`$c`";
return $out ? implode(', ', $out) : "`$alias`.*";
};
/* References vary: stored with or without a leading "#", with or without an
* operator-configured alpha prefix, or only as a numeric id. Try every
* plausible form — the PROOF match is what actually gates disclosure, so
* tolerant matching here is safe. */
$refCandidates = [$ref, '#' . $ref];
$digitsOnly = preg_replace('/\D+/', '', $ref);
if ($digitsOnly !== '' && $digitsOnly !== $ref) {
$refCandidates[] = $digitsOnly;
$refCandidates[] = '#' . $digitsOnly;
}
$refCandidates = array_values(array_unique($refCandidates));Success is {"success":true,"data":{...}}. Failure is {"success":false,"error":"snake_case_reason"}. Your Client.php and every action then have exactly one response shape to handle.
On a lookup surface, a reference that does not exist and a reference whose proof did not match must produce the SAME response. Different answers turn your bridge into an oracle that confirms which references are real, which is a free customer-list export for anyone patient.
The bridge can be precise with OpsIQ. What reaches a visitor is decided by OpsIQ, in one fixed refusal.
The operator never opens your repository. They open the connector's panel in OpsIQ and press Copy. That copy comes from settings.json, and it must be the same program as bridge/*.php.
{
"settings": [
{ "key": "base_url", "label": "API base URL", "type": "text", "required": true },
{ "key": "api_key", "label": "Bridge key", "type": "password", "required": true,
"autogenerate": true,
"help": "Auto-generated the moment you enable the connector. It must match OPSIQ_BRIDGE_KEY inside the bridge file; the copyable file below already carries this value once saved." }
],
"webhook_help": {
"title": "One file, three surfaces",
"body": "This platform has no public REST API, so this ONE file IS the API. Copy it into the site PUBLIC webroot, keeping the filename.",
"snippet_filename": "opsiq-yourplatform-bridge.php (drop next to the site index.php)",
"snippet_template": "<?php\n/* ... the whole bridge file ... */\nconst OPSIQ_BRIDGE_KEY = \u0027{{setting:api_key}}\u0027;\n..."
},
"snippet_bindings": [
{ "assignment": "OPSIQ_BRIDGE_KEY", "setting": "api_key" }
]
}The connector panel substitutes {{setting:<key>}} in the snippet with that connector's saved value, so the copied file already contains the operator's generated bridge key and needs no hand-edit. An empty or unsaved setting leaves the token visible, so the operator can see exactly what is still missing.
Declare every generated secret assignment explicitly. The sync tool rebuilds the panel copy from the shipped bridge and then restores OPSIQ_BRIDGE_KEY = {{setting:api_key}} from this binding. Without it, an upgrade can faithfully copy the keyless package file and silently remove the operator's deployable key placeholder. Connector Builder emits this binding automatically for generated bridge packages.
Independently of that, {webhook_url}, {webhook_path}, {webhook_secret}, {site_key}, {base_url} and {slug} are filled in before the panel ever sees the snippet.
A list gives you several snippets in one panel, e.g. a bridge file and a separate relay hook.
# Regenerate every package's panel snippet from its bridge file php tools/sync_connector_bridge_snippets.php --apply # Show what would change, without writing php tools/sync_connector_bridge_snippets.php
Drift is now a failing conformance check, not a support ticket: the verifier compares the two line by line (ignoring the {{setting:...}} placeholders, which are supposed to differ) and names the first line that differs. Run the sync tool as the last step before every release, right before signing.
Shaped operations and a universal data surface, together. The shaped ones return tidy, purpose-built answers to the questions people actually ask; the universal ones cover everything else so the assistant is never stuck.
stats, the main object list with filters, one object with its related rows, the catalogue of what is sold, customer search with history. These give the AI a good answer in one call instead of five.
The two or three state changes that matter — set status, cancel. Keep the accepted values allow-listed.
For a sellable platform expose purpose-built catalog, quote, checkout/order and payment-evidence operations, then map them in commerce_roles.json with transport: bridge. Never map a commerce write role to the universal record.create/update surface.
tables (with row counts) and describe (columns, types, primary key, plus readable and writable flags per column). This is how the assistant learns a platform you did not anticipate.
query, record.get, record.create, record.update, record.delete. Every one of them validated as shown above.
Identity probes are called by the ADMIN'S BROWSER, same-origin, so they cannot send a custom header. Their authentication is the platform session itself. Put them ahead of the key gate, keep them away from all record data, and never let them return a secret. See the connector identity page.
op=diag, structure only, masked.
{
"commerce": {
"roles": {
"catalog_search": {"operation":"hotel_catalog_search","transport":"bridge"},
"quote": {"operation":"hotel_quote","transport":"bridge"},
"order_create": {"operation":"hotel_order_create","transport":"bridge",
"recovery":"hotel_order_get"},
"order_get": {"operation":"hotel_order_get","transport":"bridge"},
"record_payment": {"operation":"hotel_record_payment","transport":"bridge",
"recovery":"hotel_order_get"}
},
"customer_ordering": {
"enabled":true, "version":1, "mode":"direct_order",
"audience":"guests_and_clients", "account_flow":"guest_checkout",
"payment_flow":"opsiq_gateway"
}
}
}record_payment is not a mark-paid shortcut. Accept only server-verified provider evidence: exact order, merchant, amount, ISO currency, provider reference, fresh verified timestamp and idempotency key. Persist it through the platform's payment/invoice API, then return an authoritative order or invoice read-back. An unknown result must run recovery before any retry.Test it. Rename the constant to empty and confirm every op answers 403.
hash_equals, and the key read from the header only.
And a real table name with a wrong prefix still resolves.
And a write that names one is refused with an explanation.
With the message that tells the operator how to widen it.
php tools/sync_connector_bridge_snippets.php reports it in step.
If your package ships a bridge file, an operator upgrading the connector must ALSO redeploy that file into their webroot. Say so in the panel body and in your CHANGELOG, every release.
A bridge that only reads can talk SQL. A bridge that CREATES things on the platform \u2014 an order, a booking, a paid invoice \u2014 must go through the platform's own application layer, and booting that layer headlessly is where every subtle failure in this pattern lives. Everything below was learned the hard way on a live integration, each rule against a real defect that produced no error anywhere.
The row appears, admin lists it, and it still is not a record the platform believes it created: no native reference number, no model hooks, no events, no invoice, no customer email, no working customer-facing link. The customer quotes a reference the platform never issued to staff who cannot find it. Create through the platform's own service; if it only exposes a post-payment service, create the graph it expects and hand over at the seam it defines.
Two samples of a reference format make it look easy to reproduce, and reproducing it is the same shadow-write one level down: the day the platform changes its scheme, every one of your records is wrong and nothing warns you. Call its generator (reflection reaches a non-static one), and read the stored value back rather than trusting what you sent.
Before you store anything of yours in a platform column, find every reader. A column named like a free slot can be load-bearing: on the reference integration, transaction_id turned out to be the token the customer's emailed "view your booking" link resolves through \u2014 an idempotency digest stored there quietly broke every guest link. Keep your bookkeeping in a bridge-owned table: UNIQUE(operation, idempotency_key) is the replay guard, the constraint refuses the concurrent twin, and the recovery lookup reads the same table the create wrote. Create that table BEFORE beginTransaction \u2014 MySQL DDL commits an open transaction implicitly.
If the platform service you call already dispatches the event, dispatching it yourself sends the customer two confirmation emails and generates two invoices. If nothing is listening, dispatching sends none. Neither failure raises an error. Reflect the method, slice its source lines, and read what it actually does \u2014 a name-based guess and even a regex over the body both got this wrong before the source settled it.
Laravel wraps class listeners in closures, so getListeners() reports [email protected] for everything. getRawListeners() names the actual classes. Never dispatch an event whose listeners you cannot name.
With queue=sync \u2014 the default on plenty of production installs \u2014 a queued listener runs INLINE in your bridge request. Your boot context IS its render context: every registration or URL defect in your boot lands in the customer's inbox. Check config('queue.default') before reasoning about where anything runs, and look in jobs/failed_jobs before assuming a worker was involved.
A service that dispatches unconditionally must be called exactly once. The marker that cannot drift is the platform's own record state (only call while the record is still pending), not a parallel "sent" flag of yours that can disagree with it.
Template variables, module settings, filter hooks \u2014 platform service providers often register them only on a web request. On the reference integration the email handler substitutes only REGISTERED variables: every value was set correctly and the customer's confirmation still rendered with empty name, phone and link, no error anywhere, because registration lives in a runtime registry the headless boot never filled. Find the platform's registration call (for Botble: EmailHandler::addTemplateSettings with the module's email config) and make it in your boot, exactly as the platform's own provider does.
The captured request points at your bridge script, so route(), url() and asset() generate site.com/public/opsiq-bridge.php/checkout/TOKEN \u2014 a customer link through a JSON endpoint. forceRootUrl(config('app.url')) fixes the generator; the STORAGE disk has its own root, so the emailed logo stays broken until filesystems.disks.public.url is set too (it resolves lazily, so setting it at boot works \u2014 and only when empty or script-relative: an operator's CDN URL is not yours to override).
The platform's services read through their own connection and cannot see your open transaction. Called before commit, a post-payment service finds no completed payment, quietly leaves the record unpaid \u2014 and still fires its events, so the customer is emailed about a record the platform thinks is unpaid. Commit the graph, then call.
If the native path is unreachable, refuse with a retryable error BEFORE any money moves. Never invent a reference, never raw-update a status to make a half-integrated record look finished. A verified payment whose native processing failed goes to reconciliation as needs_attention \u2014 the money is real, the state is honestly "paid, not yet processed".
"The service ran" and "the customer was told" are different facts \u2014 the reference integration shipped a complete-looking email with every field blank while the ran-flag said true. Return them separately (processing completed, notification attempted), keep a per-call platform_notified that forces the OpsIQ fallback confirmation whenever the platform did not process, and never claim delivery: an inbox is not observable from a server.
Ship a read-only capabilities probe in the bridge: class existence, method signatures, source slices of the methods you intend to call, raw listeners, queue driver, and \u2014 when a question can be answered by calling a harmless function \u2014 the live call itself. Five theories about one hollow email died against measurements before the source settled it. A probe round costs a file copy; a wrong write on a live platform costs a customer.
The bridge pattern is not a PHP pattern. What OpsIQ calls is an HTTP endpoint, so the file can be Node, Python, Go, Ruby, .NET or Java, and the store behind it can be any SQL engine or MongoDB. What IS PHP-shaped is the packaging pipeline, and that constraint decides how your bridge reaches the operator. Read the delivery section first: it is the part that surprises people.
This is the whole contract. Nothing in it names a language.
HTTPS. One GET request per call. No body, no other method.
A shared secret in the X-Opsiq-Bridge-Key request header, compared in constant time. Not a query parameter, not a cookie, not Basic auth.
Query string. op names the surface, do names the operation, the rest are that operation's arguments.
JSON. {"success":true,"data":{...}} or {"success":false,"error":"snake_case_reason"}. Content-Type application/json, and no caching.
200 on success. 403 unconfigured or wrong key, 404 not found, 405 wrong method, 400 bad argument, 501 unsupported on this schema.
No framework, no runtime, no OpsIQ library on your side. If it can serve that, it can be a bridge.
The signed package covers a fixed list of file extensions, and a file outside that list is left out of the ZIP. A bridge in a language the list does not cover therefore cannot ship inside the package — but it can no longer disappear on you either. Since 26 August 2026 a file in bridge/ that the packager would drop is a hard conformance failure, so the package refuses to pass rather than installing with no bridge in it.
bridge/bridge.php -> SHIPPED, and drift-checked against the panel snippet bridge/server.js -> SHIPPED, and drift-checked against the panel snippet bridge/bridge.py -> REFUSED at conformance: "Bridge files are packaged" FAILS bridge/bridge.rb -> REFUSED at conformance bridge/main.go -> REFUSED at conformance bridge/Bridge.cs -> REFUSED at conformance bridge/Bridge.java -> REFUSED at conformance
The file ships in the signed ZIP, and the snippet verifier holds your panel copy byte-identical to it, whichever of the two it is. The drift check reads every file in bridge/, not just the PHP ones, so an upgraded bridge with a stale panel copy fails the build in either language.
The panel snippet is plain text with no idea what language it holds, so it works for any stack. Put the whole program in webhook_help.snippet_template, name the file in snippet_filename, and do NOT leave a copy in bridge/ — conformance will refuse the package rather than ship it hollow. Say plainly in webhook_help.body that the operator copies this file rather than getting it from the package.
Widen PackageSigner::EXTENSIONS deliberately, then re-sign and re-seed. That is a decision about what executable code Nabtech distributes, so make it on purpose — do not discover it from a missing file.
webhook_help.snippet_filename whenever your package ships more than one bridge. That is how the verifier knows which bridge a panel copy belongs to; without it, an ambiguous pairing is reported as a conformance warning and that snippet is left unchecked.php tools/sync_connector_bridge_snippets.php --apply, then re-sign the package.Same four checks in the same order everywhere: fail closed with no key, one method, constant-time key comparison from the header, then connect. The only real trap is the comparison, and it is a different trap in each language.
// Node.js — no dependencies
const http = require("http"), crypto = require("crypto"), url = require("url");
const BRIDGE_KEY = process.env.OPSIQ_BRIDGE_KEY || ""; // empty = bridge OFF
const sameKey = (a, b) => {
const ha = crypto.createHash("sha256").update(String(a)).digest();
const hb = crypto.createHash("sha256").update(String(b)).digest();
return crypto.timingSafeEqual(ha, hb); // equal lengths, always
};
const out = (res, payload, code = 200) => {
res.writeHead(code, { "Content-Type": "application/json; charset=utf-8",
"Cache-Control": "no-store" });
res.end(JSON.stringify(payload));
};
http.createServer(async (req, res) => {
if (BRIDGE_KEY.length < 24) return out(res, { success: false, error: "bridge_not_configured" }, 403);
if (req.method !== "GET") return out(res, { success: false, error: "method_not_allowed" }, 405);
const given = req.headers["x-opsiq-bridge-key"] || "";
if (!given || !sameKey(BRIDGE_KEY, given))
return out(res, { success: false, error: "forbidden" }, 403);
const q = url.parse(req.url, true).query;
// ... dispatch on q.op / q.do exactly as the PHP bridge does
}).listen(process.env.PORT || 8787);# Python — Flask
import hashlib, hmac, os
from flask import Flask, request, jsonify
app = Flask(__name__)
BRIDGE_KEY = os.environ.get("OPSIQ_BRIDGE_KEY", "") # empty = bridge OFF
def same_key(a: str, b: str) -> bool:
return hmac.compare_digest(
hashlib.sha256(a.encode()).digest(),
hashlib.sha256(b.encode()).digest(),
)
def out(payload, code=200):
resp = jsonify(payload)
resp.status_code = code
resp.headers["Cache-Control"] = "no-store"
return resp
@app.before_request
def gate():
if len(BRIDGE_KEY) < 24:
return out({"success": False, "error": "bridge_not_configured"}, 403)
if request.method != "GET":
return out({"success": False, "error": "method_not_allowed"}, 405)
given = request.headers.get("X-Opsiq-Bridge-Key", "")
if not given or not same_key(BRIDGE_KEY, given):
return out({"success": False, "error": "forbidden"}, 403)// Go
func sameKey(a, b string) bool {
ha := sha256.Sum256([]byte(a))
hb := sha256.Sum256([]byte(b))
return subtle.ConstantTimeCompare(ha[:], hb[:]) == 1
}
func gate(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
w.Header().Set("Cache-Control", "no-store")
key := os.Getenv("OPSIQ_BRIDGE_KEY")
if len(key) < 24 { out(w, 403, "bridge_not_configured"); return }
if r.Method != http.MethodGet { out(w, 405, "method_not_allowed"); return }
given := r.Header.Get("X-Opsiq-Bridge-Key")
if given == "" || !sameKey(key, given) { out(w, 403, "forbidden"); return }
next(w, r)
}
}
// Ruby
def same_key?(a, b)
OpenSSL.secure_compare(Digest::SHA256.digest(a.to_s), Digest::SHA256.digest(b.to_s))
end
// C# / .NET
static bool SameKey(string a, string b) =>
CryptographicOperations.FixedTimeEquals(
SHA256.HashData(Encoding.UTF8.GetBytes(a)),
SHA256.HashData(Encoding.UTF8.GetBytes(b)));
// Java
static boolean sameKey(String a, String b) throws Exception {
MessageDigest d = MessageDigest.getInstance("SHA-256");
return MessageDigest.isEqual(d.digest(a.getBytes(UTF_8)), d.digest(b.getBytes(UTF_8)));
}The safety property does not change: a table or column name the caller supplied must be checked against the real schema before it is interpolated, and every value must be a bound parameter. Only the introspection query, the quoting character and the paging clause differ.
Tables: SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = ?. Columns: the same against information_schema.COLUMNS with AND TABLE_NAME = ?. Quote with backticks, doubling any backtick inside. Page with LIMIT n OFFSET m.
Same information_schema views, lower-case names, WHERE table_schema = $1 (usually public). Quote with double quotes, doubling any double quote inside. Page with LIMIT n OFFSET m. Watch the folding rule: an unquoted identifier is folded to lower case, so compare case-insensitively when you resolve a name.
Same INFORMATION_SCHEMA views. Quote with square brackets, doubling any closing bracket inside. Paging needs an ORDER BY: ORDER BY [id] DESC OFFSET @o ROWS FETCH NEXT @n ROWS ONLY.
Tables: SELECT name FROM sqlite_master WHERE type = 'table' AND name NOT LIKE 'sqlite_%'. Columns: SELECT name FROM pragma_table_info(?) — use that table-valued form, because the bare PRAGMA table_info(x) statement cannot take a bound parameter and inviting string interpolation there is exactly the hole you are trying to close. Quote with double quotes. Page with LIMIT n OFFSET m.
Tables: SELECT TABLE_NAME FROM ALL_TABLES WHERE OWNER = :owner; columns from ALL_TAB_COLUMNS. Quote with double quotes, and remember an unquoted identifier folds to UPPER case, the opposite of PostgreSQL. Page with OFFSET :o ROWS FETCH NEXT :n ROWS ONLY on 12c and later.
No SQL, so no identifier interpolation and no bound parameters — a different discipline for the same goal. See below.
-- MySQL / MariaDB SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = ?; SELECT COLUMN_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ?; -- PostgreSQL SELECT table_name FROM information_schema.tables WHERE table_schema = $1; SELECT column_name FROM information_schema.columns WHERE table_schema = $1 AND table_name = $2; -- SQL Server SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = @schema; SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = @schema AND TABLE_NAME = @table; -- SQLite SELECT name FROM sqlite_master WHERE type = 'table' AND name NOT LIKE 'sqlite_%'; SELECT name FROM pragma_table_info(?); -- Oracle SELECT TABLE_NAME FROM ALL_TABLES WHERE OWNER = :owner; SELECT COLUMN_NAME FROM ALL_TAB_COLUMNS WHERE OWNER = :owner AND TABLE_NAME = :tbl;
There is no query string to inject into, so people assume there is nothing to guard. There is: the filter document. Passing caller-supplied JSON straight into find() lets a caller send {"$ne": null} or {"$gt": ""} where you expected a value, and quietly select every document. Build the filter yourself.
// Node + the official driver
const names = (await db.listCollections({}, { nameOnly: true }).toArray()).map(c => c.name);
function resolveCollection(given) {
if (!/^[A-Za-z0-9_.-]+$/.test(given || "")) return null;
return names.find(n => n.toLowerCase() === String(given).toLowerCase()) || null;
}
const coll = resolveCollection(q.collection);
if (!coll) return out(res, { success: false, error: "unknown_collection" }, 404);
// Build the filter from a validated field and a SCALAR value. Never spread
// caller JSON into it: {"$ne":null} would match every document.
const filter = {};
if (q.where_field) {
if (!/^[A-Za-z0-9_.]+$/.test(q.where_field))
return out(res, { success: false, error: "unknown_field: " + q.where_field }, 400);
filter[q.where_field] = String(q.where_value ?? ""); // String() is the guard
}
// Projection is the redaction allow-list: drop secrets, never return them.
const projection = { password: 0, remember_token: 0, api_key: 0, secret: 0, token: 0 };
const limit = Math.min(Math.max(parseInt(q.limit ?? "25", 10) || 25, 1), 200);
const rows = await db.collection(coll)
.find(filter, { projection })
.limit(limit)
.skip(Math.max(0, parseInt(q.offset ?? "0", 10) || 0))
.toArray();That is your information_schema. Resolve the caller's spelling against it and use the resolved name.
A String() or a Number() around it is the whole defence against operator injection. A document where you expected a value is the NoSQL equivalent of a stray quote.
Exclude secret-shaped fields in the projection so they never leave the server, rather than deleting them from the result afterwards.
deleteOne with a resolved _id. Never deleteMany, and never a filter the caller influenced.
Same reasoning as SQL: name the collections a write may touch, and refuse the rest with an explanation.
The identity probe is the other half of a bridge, and it is HTTP too. The signing block is identical in every language: base64url the payload, HMAC-SHA256 that string, join with a dot.
Those snippets mint a PORTAL handoff token, which is deliberately stricter: it carries jti and single_use:true and lives about 120 seconds because it travels in a URL. A bridge or widget identity token carries neither of those and uses a longer exp, minutes to hours.
site_key, iat, exp and a top-level authenticated:true, plus an admin or customer subject with an id and a username or email. Same claims, same signature, same secret.
A three-part JWT signed HS256 works, and so does the two-part base64url payload plus hex HMAC that the PHP reference emits. Use whichever your language's libraries make natural — a JWT library is usually the shorter path outside PHP.
True in every language. Signing client-side means shipping the site secret to every visitor.
Write the bridge in PHP. It ships in the package, it is drift-checked, and it can boot the platform's own framework to read a live session for the identity probe. Nothing else gives you all three.
A .js bridge ships, signs and is drift-checked exactly like a PHP one. Nothing is given up.
Deliver through the panel snippet and say so in the panel body; do not leave the file in bridge/, where conformance will refuse the package. The connector is otherwise completely normal: actions, context providers, identity and guest lookups all work the same, because none of them care what answers the HTTP call.
Then the bridge pattern is not the right tool. A bridge exists to reach a platform from inside its own host. If you can only reach it from outside, you are writing an ordinary API connector against whatever surface it does expose.
This is the single most common thing missing from a connector that "works but is useless". Actions let the AI DO things. Context sections let it KNOW things. A connector needs both, and most questions an admin asks are answered by context, never by an action. A connector with perfect actions and no context provider will truthfully report that it cannot see anything.
Declared in actions.json or returned by registerActions(). The model picks one, fills its parameters, and OpsIQ executes it. Actions are for verbs: cancel this booking, open that ticket, change this status.
Assembled by a ContextProvider before the model runs. "How many orders this month", "who are my newest customers", "what do we sell" all resolve through a context lookup, and never touch an action at all.
OpsIQ asks for sections by generic name. Your job is to decide what each one means on your platform and answer it. A hotel booking IS the hotel's order; a room IS what the hotel sells. Map, do not invent.
Whatever a transaction is on your platform: orders, bookings, reservations, jobs, shipments. pending_orders is the same list filtered to the unfinished ones.
The customer roster.
What the platform sells: products, rooms, plans, services.
Revenue and money-shaped totals, plus counts by state.
Use these when your platform genuinely has them. Do not force a mapping — an unanswered section is better than a wrong one.
Declare your own. A provider that declares sections(): ['licenses','shipments'] has those merged into the universal lookup's allow-list, so platform-specific lookups become available with no core changes.
A context provider MUST implement the interface. The registry type-checks it, so a class that merely LOOKS right is skipped — with no error, anywhere.
use OpsIQ\Platform\ContextProviderInterface;
/* MUST implement ContextProviderInterface: ContextRegistry::collectAll()
* type-checks it, so a provider that merely LOOKS right is skipped and every
* section answers "No enabled connector supplied this context section" — the
* exact symptom, with no error anywhere. */
final class ContextProvider implements ContextProviderInterface
{
public function slug(): string { return 'yourplatform_context'; }
public function label(): string { return 'Your Platform (orders, customers, products)'; }
public function priority(): int { return 30; } // lower renders earlier
/** ADMIN only. The guest surface has its own provider and its own rules. */
public function surfaces(): array { return ['admin']; }
/** The universal section names this connector can answer. */
public function sections(): array
{
return ['orders', 'pending_orders', 'clients', 'products', 'billing'];
}
public function isAvailable(): bool
{
try {
$s = \OpsIQ\Connectors\ConnectorRegistry::getSettings('yourplatform') ?: [];
return trim((string)($s['base_url'] ?? '')) !== '' && trim((string)($s['api_key'] ?? '')) !== '';
} catch (\Throwable $e) {
return false;
}
}
public function build(array $ctx): string
{
$section = strtolower(trim((string)($ctx['section'] ?? '')));
$limit = max(3, min(50, (int)($ctx['limit'] ?? 20)));
$query = trim((string)($ctx['query'] ?? ''));
try {
switch ($section) {
case 'orders':
case 'pending_orders': return $this->orders($limit, $query, $section === 'pending_orders');
case 'clients': return $this->customers($limit, $query);
case 'products': return $this->products($limit);
case 'billing': return $this->billing();
}
} catch (\Throwable $e) {
return ''; // a provider must NEVER break prompt assembly
}
return '';
}
}Implement ContextConnectorInterface and return your providers from contextProviders(). The connector class may also implement ContextProviderInterface directly and be registered as itself.
build() returns a text block that is concatenated into the prompt. Write it for a reader: a heading, then one line per row.
Catch your own exceptions. A provider that throws is logged and skipped, but returning '' is the contract.
The generated ContextProvider.php ships sections(): array { return []; } and the wizard has no field for it. Fill it in by hand — and remember that republishing from the wizard OVERWRITES the file. Copy your edits out first.
$lines = ['YOUR PLATFORM — ORDERS (live, newest first)'];
$lines[] = 'TOTAL orders on file: ' . (int)$total
. ' (this list shows the newest ' . count($rows) . ' only — never count these rows to answer "how many")'
. ' | by status: ' . $byStatus;
foreach ($rows as $r) {
$lines[] = '#' . (int)$r['id'] . ' ' . $r['reference'] . ' | ' . $r['status']
. ' | amount ' . $r['amount'] . ' | ' . substr((string)$r['created_at'], 0, 16);
}
$lines[] = 'Use yourplatform_get_order (order_id) for the full record.';
return implode("\n", $lines);OpsIQ classifies an action by the WORDS in its action_id, and it is deliberately conservative: anything it cannot recognise is treated as a write and demands an approval card. Get the verb right and a read just runs.
If either is set, the action always needs approval. Declare them honestly — this is what surfaces the admin's approval card.
add, create, open, update, edit, change, modify, delete, remove, destroy, cancel, refund, suspend, terminate, activate, approve, reject, send, mark, reset, capture, void, close, reopen, assign, revoke, grant, set, toggle, enable, disable, issue, generate, apply, charge, pay, provision, renew, upgrade, merge, move, transfer, escalate, flag, register, sync, push, import, run, trigger, start, stop, restart and a few more.
get, list, search, find, view, show, fetch, count, lookup, describe, read, export, preview, test, ping, status, summary, detail, recent, history, check, log, stats, metrics, overview, revenue, breakdown, report, analytics, balance, usage, quota, snapshot, insights, feed, draft, triage, classify, suggest.
GET, HEAD and OPTIONS are reads.
Unrecognised means approval required. That default is intentional.
The native_api capability registers a generic <slug>_api_call passthrough so the model can reach endpoints your typed actions do not cover. On a platform with no API it is worse than useless: the model keeps reaching for a tool that cannot succeed, instead of using the tools that can.
Say the platform has an API and it declares native_api and emits the passthrough. Say it has none (bridge mode, or the "Platform with no API" profile) and it declares platform_bridge instead and strips native_api, so the two can never both be true. You no longer hand-edit this.
If you are writing the manifest yourself, declare exactly one of native_api or platform_bridge. Conformance treats platform_bridge as the escape hatch a bridge connector is expected to have, and the Builder refuses a spec that claims platform_bridge on an API connector.
On a connector that declares native_api the admin brain heads that file with a line naming <slug>_api_call. Without native_api it is headed neutrally instead, so a bridge connector no longer advertises a tool it does not have. Describe your real surface — for a bridge, that is your op and do vocabulary, not a REST endpoint table.
Declare ai_brain_aware and ship two Markdown files. They are read from the INSTALLED package directory (opsiq/connectors/<slug>/) for ENABLED connectors only, and injected into the admin agent's system prompt.
What this platform IS, how its data is shaped, what its objects are called, and the quirks that would otherwise make the assistant guess. Write it for a competent colleague who has never seen the platform.
The callable surface. For a bridge connector this is your op and do vocabulary with their parameters, not a REST endpoint table.
Roughly 6,000 characters kept per connector, and about 24,000 characters for the whole block across every enabled connector. Over the per-connector cap your file is truncated; be concise before the truncator is.
These files are the difference between the assistant using your universal table tools and answering from the wrong section because nothing ever told it those tools existed.
One signing contract serves three surfaces. The connector's job is to turn "who is logged in on the platform" into a signed token OpsIQ can verify, and then to present the verified subject in OpsIQ's shape. The connector never authenticates anyone — the platform does, and the signature carries that assertion.
An admin subject. The widget loads inside the platform's admin panel and every staff member is matched to their own OpsIQ agent. Full walkthrough on the admin widget page.
A customer subject. This is what lets a logged-in customer get their WHOLE account instead of an anonymous lookup: every order, full detail, and any self-service action you allow.
The same claims plus jti and single_use, with a 120-second life, because the token travels in a URL and must be spendable once. Do not hand-roll this one: Settings, Support Portal carries a ready snippet per language, and the platform mints it for you when the account area runs on this server.
These are the claims the verifiers check. Nothing here is optional, whatever a partial example elsewhere might suggest.
Top level. Must equal the site key of the request, or the token is refused.
Top level, unix seconds. exp must be in the future and after iat. A token more than about a minute in the future is refused. Keep the life short — minutes to hours.
Top level, beside exp. Your platform's assertion that a real human is logged in.
Top level. A short slug naming the origin. Recommended, and it lets a connector's identity provider tell its own tokens from another platform's.
An object naming the subject. It must carry a non-empty id, and a username or an email — the per-admin access gate matches on those. Include both when you have both.
$payload = [
'site_key' => $cfgSiteKey,
'iat' => time(),
'exp' => time() + 6 * 3600,
'authenticated' => true,
'platform' => 'yourplatform',
/* 'admin' or 'customer' — OpsIQ stamps the matching session identity
* from whichever key is present. */
$opsiqSubject => $subjectPayload,
];
$payload64 = rtrim(strtr(base64_encode(json_encode($payload, JSON_UNESCAPED_SLASHES)), '+/', '-_'), '=');
$identityToken = $payload64 . '.' . hash_hmac('sha256', $payload64, $cfgSecret);OpsIQ has two token verifiers, and they were not identical. Knowing this saves you an afternoon, because the symptom looks nothing like the cause.
opsiq/embed/admin_ajax.php carries a local verifier that accepts the authenticated flag in either position. Conversation list, history and unread all go through it, so they authenticate fine.
opsiq/includes/customer_identity_token_verify.php sits behind the chat stream and the core AJAX API. It historically required the flag at the TOP level.
History and conversations work. Every chat turn answers "Admin login required". It reads exactly like a session bug and is not: the token is missing the top-level flag.
It now accepts the flag at the top level OR inside the subject, so the contract is uniform. Older cores read only the top level. Emit the canonical shape and your package works on every release.
Two things have to be true. Core must stamp the verified customer, and your connector must present it.
Same signer as the admin one, with a customer subject. Read the customer from the platform's own session. If your platform signs customers in on a different guard from admins, read the guard you want and never fall back across subjects — that is how a customer would be handed an admin token.
On a valid token, core stamps the verified subject into the session. Your provider reads a proven identity; it never authenticates.
detectCustomer() returns the OpsIQ shape. It MUST implement OpsIQ\Platform\IdentityProviderInterface, or the registry silently skips it — the same trap as the context provider.
And OpsIQ locks it to the verified identity before execution. The model cannot supply it.
use OpsIQ\Platform\IdentityProviderInterface;
final class IdentityProvider implements IdentityProviderInterface
{
public function slug(): string { return 'yourplatform_identity'; }
public function label(): string { return 'Your Platform identity (bridge-signed identity_token)'; }
public function priority(): int { return 25; } // ahead of the generic session provider
public function isAvailable(): bool
{
try {
$s = \OpsIQ\Connectors\ConnectorRegistry::getSettings('yourplatform') ?: [];
return trim((string)($s['base_url'] ?? '')) !== '';
} catch (\Throwable $e) { return false; }
}
public function detectAdmin(): ?array
{
$row = $this->sessionRowFor('_opsiq_admin_identity');
if (!$row || !$this->isOurs($row)) return null;
return [
'id' => (int)($row['id'] ?? 0),
'name' => $this->displayName($row, 'Admin'),
'email' => (string)($row['email'] ?? ''),
'username' => (string)($row['username'] ?? ''),
'role' => (string)($row['role'] ?? ''),
'platform' => 'yourplatform',
'source' => 'yourplatform_identity_token',
];
}
public function detectCustomer(): ?array
{
$row = $this->sessionRowFor('_opsiq_customer_identity');
if (!$row || !$this->isOurs($row)) return null;
return [
'id' => (int)($row['id'] ?? 0),
'name' => $this->displayName($row, 'Customer'),
'email' => (string)($row['email'] ?? ''),
'phone' => (string)($row['phone'] ?? ''),
'platform' => 'yourplatform',
'source' => 'yourplatform_identity_token',
];
}
/* A session identity stamped by ANOTHER platform's token must not be
* claimed here. An empty platform is accepted because older bridges did
* not stamp one, and the site key already scoped the token. */
private function isOurs(array $row): bool
{
$p = strtolower(trim((string)($row['platform'] ?? '')));
return $p === '' || $p === 'yourplatform' || $p === 'remote';
}
private function sessionRowFor(string $key): ?array
{
if (session_status() !== PHP_SESSION_ACTIVE) return null;
$row = $_SESSION[$key] ?? null;
return (is_array($row) && (int)($row['id'] ?? 0) > 0) ? $row : null;
}
}The model must never choose whose data it reads. OpsIQ enforces that on its side, and your platform must enforce it on the other side too. One lock is a bug away from a leak; two locks are a contract.
Before a customer-chat action runs, OpsIQ replaces every identity-shaped parameter with the VERIFIED visitor identity: client_id, clientid, user_id, userid, customer_id, account_id take the verified numeric id; client_identifier, customer_identifier, account_identifier take it as a string; email, client_email, customer_email, user_email take the verified email. Whatever the model proposed is discarded.
Take the id you were given and add it to the WHERE clause of every read and every write on that surface. Never trust the reference in the request on its own. A signed-in customer asking about someone else's order must come back empty, not forbidden.
Call it customer_id, not cust or ref. A parameter OpsIQ does not recognise is a parameter it cannot lock.
You can spare the operator all page wiring. Add an admin_identity_probe_url setting (https only) pointing at your identity endpoint. The plain admin-widget loader from Remote Sites, Codes then works with no page attributes at all: the widget discovers the endpoint through the connector, calls it with the site key and widget token, and authenticates each admin individually. A page can still override with a data-identity-endpoint attribute or window.OpsIQAdminIdentityEndpoint.
{
"key": "admin_identity_probe_url",
"label": "Admin identity probe URL",
"type": "text",
"placeholder": "https://your-site.com/opsiq-yourplatform-bridge.php?op=admin_identity",
"help": "Set this to your bridge admin_identity endpoint and the plain admin-widget loader works with NO page wiring: the widget probes this URL by itself, the bridge answers with the signed identity of the CURRENTLY logged-in admin, and every admin is matched to their own OpsIQ agent. Leave empty to keep the admin embed off."
}Same-origin, so it cannot carry a custom header. Its authentication is the platform session. Put it AHEAD of your bridge-key gate, keep it away from record data, and return nothing at all for a logged-out visitor.
{"success":true,"authenticated":true,"admin":{...},"identity_token":"..."} — and {"success":false,"authenticated":false,"error":"..."} when nobody is signed in.
Only the signed, expiring token.
The full endpoint implementations for Laravel, WordPress, WHMCS, Symfony and plain PHP, plus the hard-won Laravel specifics and the troubleshooting order, are on the admin widget page. They are the same code for a customer subject: change the guard you read and the subject key you sign.
The most common way to lose an afternoon is to edit a connector under marketplace_connectors/, reinstall it, and find nothing changed. Installs do not read that folder. They pull a signed ZIP from the marketplace catalogue. Publishing is the sequence that puts your changes into that ZIP.
It is where you work. Nothing installs from it.
An install downloads that ZIP, verifies the signature, and unpacks it. Until you rebuild the ZIP, every install keeps getting the old package.
It writes into /connectors/<slug>/ on this install. That is a local connector, not a marketplace release. The two paths do not overlap.
settings.json and connector_contract.json. Conformance compares them and fails if the slug, the version or the capability set disagree. Add a CHANGELOG.md entry while you are there — it is a required file.
php tools/sync_connector_bridge_snippets.php --apply — only relevant if your package ships bridge/*.php, and mandatory if it does. Skipping it means the panel hands operators the previous bridge.
php tools/resign_all_connectors.php — the signature covers file hashes, so ANY edit invalidates it. Sign last, after every file is final.
The seeder signs each package as it builds the ZIP, and it runs in a context where the key cannot be read from settings — so it must come from the environment.
Reinstalling the connector updates the package. It does NOT touch the copy sitting in the operator's webroot. Tell them, in the panel and in the changelog.
# 2 — hold the panel copy identical to the shipped bridge
php tools/sync_connector_bridge_snippets.php --apply
# 3 — re-sign (do this last, after every file is final)
php tools/resign_all_connectors.php
# 4 — the seeder reads the signing key from the ENVIRONMENT only
export OPSIQ_CONNECTOR_SIGNING_KEY="$(php -r 'require "bootstrap/init.php"; echo opsiq_setting("connector_signing_key","");')"
php saas/scripts/maint/seed_marketplace_free.php --apply --only=<slug>
# verify before and after
php tools/verify_identity_contracts.php
php vendor/bin/phpunit tests/phpunit/Unit/ConnectorsThe ZIP is built from the signer's own file list, so a stray file sitting in your package folder is not shipped. That is deliberate: an unsigned file used to ride along to customers.
php, json, js, css, md, txt, html, sh, svg, png, jpg, jpeg, gif, webp, ico, yml, yaml — recursively, including bridge/ and tests/. signature.json itself is excluded from the hashes and then added to the ZIP so installs can verify.
The seeder names every file it left behind. Read that list. A file you expected to ship appearing there means a wrong extension or a wrong location — not a silent success.
Including a Markdown file. Re-sign that package.
Must return an instance of ConnectorInterface.
Manifest: slug, name, version, manifest_version, compatibility, capabilities, connector_contract_version, settings.
Machine-readable contract. Its slug, version and capability set must be identical to settings.json.
All three are checked for existence AND minimum size. DEVELOPER.md needs real content, not a stub.
Each capability names the file it expects — ContextProvider.php for context, IdentityProvider.php for identity, GuestLookupProvider.php for guest_lookup, and so on — unless the connector implements the capability inline.
Conformance scans the three Markdown files for secret-shaped values and private keys, and fails on a hit.
The full conformance suite is the same one an install runs. It checks the manifest against the canonical contract, that runtime and manifest capabilities agree, that every declared capability has its file and its methods, the identity-token contract in every minting file, the bridge-snippet match, guest-lookup allowlist hygiene, action uniqueness and confirmation safety, and the package signature.
# conformance for every marketplace package php tools/test_marketplace_connector_conformance.php # the identity-token contract, statically, with file:line on failure php tools/verify_identity_contracts.php # the connector unit suite php vendor/bin/phpunit tests/phpunit/Unit/Connectors # the release gate php tools/release_gate_connectors.php
This is the source-level contract for building a connector that OpsIQ can discover, configure, validate, enable, execute, test, sign and distribute.
connectors/example_platform/
├── connector.php # connector implementation / entry point
├── settings.json # manifest + configuration schema
├── actions.json # optional action catalogue
├── README.md # setup, scopes, webhooks and limits
├── workflow_recipes.json # optional reusable recipes
├── knowledge.json # optional provider knowledge
├── profile.json # optional connector profile
├── src/ # optional client/provider classes
├── assets/ # optional admin assets
└── signature.json # signed release metadatasettings.json uses manifest version 1. The validator expects a slug, name, version, manifest_version, compatibility, description and capabilities. Compatibility declares opsiq_min and opsiq_max. Release status is one of production, beta, preview or template; capability maturity uses levels L1–L6. Legacy packages can be normalised with warnings, but a new package should pass without warnings.
slug(), name(), description(), capabilities(), settingsSchema(), testConnection().onEnable() and onDisable(). Disable must be non-destructive; data purge is a separate deliberate operation.handleWebhook(), poll(), backfill(). Poll handles incremental work; backfill imports history and must be safe to repeat.pushReply() where the platform accepts replies.registerActions() supplies executable action contracts.securityCapabilities(), syncBlockedIp(), removeBlockedIp(), testSecuritySync().The abstract base also offers optional chunked backfill, customer listing, email-account discovery/creation, subscribers, admin/customer detection, billing/context/identity providers, response extraction, retrying HTTP calls, JSON-path access, fuzzy ranking and pagination helpers.
Supported capability names include actions, triggers, context, identity, sales, billing, inbound_ticket, outbound_reply, sync_users, sync_departments, security_events, customer_import, security_native_block, promo_audience, promo_feed, email_mailbox, native_api, ai_brain_aware and ai_tickets. The builder provides API key, bearer, basic, HMAC, OAuth 2 client credentials, OAuth 2 authorisation code and custom authentication templates.
onEnable(), synchronises action definitions and can start the initial backfill.onDisable() and stops activity without deleting imported data.actions.json catalogue does not make an action usable until the connector is installed, enabled, configured and its connection is valid.Run PHP lint, manifest validation, connection tests, action schema tests, webhook signature/replay tests, workspace-isolation tests, backfill-repeat tests, disabled-connector tests and failure/retry tests. A marketplace package should then be signed and verified, include setup/permissions/webhook documentation, and state its true release status. The connector tile and manifest are the authoritative availability signal.
Step-by-step recipes for common connector setups.
Goal: Connect Shopify with automatic order sync and GDPR compliance.
1. Create a custom app in Shopify admin (Settings > Apps > Develop apps). 2. Grant scopes: read_orders, read_customers, read_products, write_customers. 3. Copy the Admin API access token. 4. In OpsIQ Connectors > Shopify, enter store domain and token. 5. Click Test Connection. 6. Enable Webhook sync, OpsIQ registers order/customer webhooks automatically. 7. GDPR webhooks register automatically (data_request, customers/redact, shop/redact). 8. Verify: place a test order, check it appears in OpsIQ Sales within 30 seconds.
Goal: Connect WHMCS so AI can look up clients, services, tickets, and invoices.
1. In WHMCS admin, Setup > Staff Management > Manage API Credentials. Create a key. 2. In OpsIQ Connectors > WHMCS, enter URL, API identifier, and secret. 3. Click Test Connection. 4. Install the WHMCS module addon for ticket relay. 5. Verify: ask the admin AI "Find client [email protected]". WHMCS data should appear.
Goal: Track Stripe payments and let AI look up transactions.
1. In Stripe Dashboard > Developers > API keys, create a restricted key (read: Customers, Charges, Invoices, Subscriptions). 2. In OpsIQ Connectors > Stripe, enter the restricted key. 3. Test Connection. 4. Add webhook endpoint in Stripe: copy the webhook URL shown on the connector's own settings page. It carries a per-connector token and looks like https://your-domain.com/api/connectors.php?slug=stripe&token=THE_TOKEN A URL without the token is rejected with "Missing slug or token". 5. Select events: charge.succeeded, invoice.paid, customer.subscription.updated. 6. Copy the webhook signing secret to OpsIQ. 7. Verify: make a test payment, check it in OpsIQ Sales.
Goal: Connect GBP for review management, posts, and insights.
1. Create a Google Cloud project, enable Business Profile API. 2. Create OAuth 2.0 credentials (Web application). 3. Set redirect URI: copy it from the connector's own settings page. Google and Microsoft connectors share one slug-less callback: https://your-domain.com/connectors.php?oauth=callback Everything else uses https://your-domain.com/connectors.php?slug=<slug>&oauth=callback OAuth redirect URIs must match EXACTLY, and a URI missing oauth=callback is read as a webhook and answered with "Missing slug or token". 4. In OpsIQ, enter Client ID and Client Secret. 5. Click Authorize, sign in, grant access. 6. Select your business location. 7. Verify: reviews, posts, and insights should appear.
OpsIQ subsystems are open for extension. A connector can plug a new capability into the CRM or Site Intelligence with no changes to OpsIQ core, via the platform capability registry (\OpsIQ\Platform\CapabilityRegistry). Declare the capability, implement its small method set, ship the connector, OpsIQ discovers it and wires it into the UI, the Customer 360 timeline and the install prompts.
Add a <domain>_capabilities array, best for no-code/marketplace connectors. Domains: crm, site_intelligence.
Implement crmCapabilities() / siCapabilities() returning the same descriptors.
Goal: make a calendar connector appear in the CRM Schedule-meeting panel.
"crm_capabilities": [ { "type": "calendar", "label": "Calendar (Acme)", "actions": ["createEvent","listEvents","freeBusy"], "requires_auth": true } ]
Goal: feed local-listing data into Site Intelligence.
"site_intelligence_capabilities": [ { "type": "local_listing", "actions": ["listLocations","listReviews","getInsights"], "requires_auth": true } ]
createEvent($settings,$params) → {success,event_id,html_link,meet_link}; listEvents; freeBusy. Driven by \OpsIQ\CRM\CalendarBridge.
enrich($settings,$params) → {success,traits}. Driven by \OpsIQ\CRM\EnrichmentBridge (also runs automatically on company create when a provider is connected).
sendForSignature($settings,$params) → {success,envelope_id,sign_url}. Driven by \OpsIQ\CRM\EsignBridge.
listLocations, listReviews, getInsights. Ships via the Google Business Profile connector.
keywordRanks($settings,$params) → {success,ranks}. Driven by \OpsIQ\SiteIntelligence\RankDataBridge. Ships: SerpApi connector.
report($settings,$params) (sync/export) + ingest($settings,$events) (import). Driven by \OpsIQ\Analytics\WebAnalyticsBridge. Ships: Google Analytics (GA4) connector. Data API for reports, Measurement Protocol for import. Analytics is open for connectors like CRM + Site Intelligence (domain analytics / analytics_capabilities).
listPayments, customerPayments, createPaymentLink. Driven by \OpsIQ\Payments\PaymentsBridge. Show a customer's payments on the CRM timeline + send a payment link on a deal. Ships: Stripe Payments connector. Domain payments / payments_capabilities.
listMessages + sendMessage. Driven by \OpsIQ\Mailbox\MailboxBridge. A customer's emails on the Customer 360 timeline + send email from a deal. Ships: Gmail + Outlook/Microsoft 365 connectors. Domain mailbox / mailbox_capabilities.
All Google connectors share ONE app via \OpsIQ\OAuth\SharedGoogleApp. Set google_oauth_client_id/_secret once and Calendar, Analytics, Business Profile + Gmail all work (the per-connector "(optional)" fields are overrides). They also share ONE redirect URI, <site>/connectors.php?oauth=callback (no per-connector slug), because Google exposes no API to add redirect URIs to an app; OpsIQ recovers the connector from the signed OAuth state nonce. Register that single URI once and every Google connector (present + future) authorizes with no further Console setup. Return SharedGoogleApp::resolve(...)’s redirect_uri from your oauthParams(); never hard-code a per-slug redirect. Microsoft connectors do the same via \OpsIQ\OAuth\SharedMicrosoftApp (microsoft_oauth_*).
The Import (historical backfill) and Import customers buttons show ONLY for connectors that actually implement them, detected by reflection, so there is no flag to declare. Override backfill() or backfillChunk() to earn the Import button; override listCustomers() (return {email, first_name, …} pages) to earn Import customers. Inherit the AbstractConnector no-op and the button stays hidden, so the UI never offers an import a connector cannot perform.
The CRM agent proposes and books meetings off deal signals (\OpsIQ\CRM\MeetingProposer → CalendarBridge), and auto-enriches new accounts, the “AI operates the CRM” loop, executed across connector buses.
fetchTicket())When a visitor references a ticket number in the client chat ("what's the status of T-000123?"), OpsIQ resolves it in two tiers. Tier 1 reads the shared OpsIQ ticket store, every connector with inbound_ticket mirrors its tickets there, so synced tickets just work for ALL connectors with zero per-connector code. Tier 2 is a live fallback for OLD tickets that were never mirrored: core calls an OPTIONAL fetchTicket() on each enabled connector that implements it. It is duck-typed (discovered by method_exists(), like contextProviders()/audienceCatalog()), so the signed ConnectorInterface is untouched and connectors that don't need it (email/chat sources that create tickets natively) simply omit it.
fetchTicket() receives the VERIFIED visitor identity in $ctx (client_id + client_email, the same verified identity the client chat AI uses). Resolve the platform customer from that identity and query ONLY that customer's tickets, then re-check ownership on the detail record. Return null on any miss, mismatch, or error, never another customer's data. A return of null degrades gracefully to "couldn't find that ticket".<?php
// connector.php — OPTIONAL universal client-chat ticket resolver (Tier 2).
// Only add it if your platform keeps its OWN ticket store that may hold tickets
// not yet mirrored into OpsIQ. Return the normalised array below, or null.
//
// $ref = ['mode' => 'id'|'tid', 'value' => string] (from extract_ticket_ref)
// $ctx = ['client_id' => int, 'client_email' => string] (VERIFIED visitor)
// $settings = your connector settings
public function fetchTicket(array $ref, array $ctx, array $settings): ?array
{
try {
$email = trim((string)($ctx['client_email'] ?? ''));
$cid = (int)($ctx['client_id'] ?? 0);
if ($cid <= 0 && $email === '') return null; // no verified identity → refuse
// 1) Resolve THIS visitor on your platform (by verified email/id).
// 2) List ONLY their tickets and match $ref against the ticket number/id.
// 3) Re-confirm ownership on the detail record before returning.
// On any miss/mismatch/error → return null (never leak).
return [
'tid' => 'T-000123', // the customer-facing reference
'id' => 123, // your internal id
'status' => 'open',
'subject' => '…',
'department' => 'Billing', // '' if your platform has none
'priority' => 'high',
'opened_at' => '2026-06-29 10:00:00',
'last_reply' => '2026-06-29 12:00:00',
'message' => 'opening message text',
'replies' => [ // oldest → newest; opening message may be first
['who' => 'You', 'date' => '…', 'message' => '…'],
['who' => 'Staff', 'date' => '…', 'message' => '…'],
],
];
} catch (\Throwable $e) {
error_log('[yourslug][fetchTicket] ' . $e->getMessage());
return null; // graceful degrade
}
}CapabilityRegistry::providers($domain,$type) lists providers with installed/enabled/ready status (filesystem-based; DB only for the enabled flag).
CapabilityRegistry::active($domain,$type) returns the first ready provider with its loaded connector and settings. Bridges call this instead of hardcoding slugs.
Where a feature needs a capability that is not connected yet, the UI shows a one-click Connect/Install prompt, never a dead control.
See connectors/PLATFORM_CONNECTORS.md (CRM + Site Intelligence) and connectors/CRM_CONNECTORS.md in the package.
Signed-in customers can ask the customer chat AI about their OWN account ("my balance", "my orders", "did support answer my ticket") and, if the business enables it, request refunds. All of it is powered by YOUR connector's declarations: no OpsIQ core changes, no platform hardcoding. The AI calls your lookups as native tools (it cannot invent one), identity is locked server-side to the verified customer, and results are automatically trimmed for the AI.
In your actions.json, a read-only action becomes customer-callable with ALL THREE: "scope":"client", "requires_confirmation":false, "is_destructive":false. Use "scope":"both" when the same lookup should also be callable by your team in the Admin AI. The full vocabulary is admin, client, both and system (system reaches neither AI — API and webhook routes only). Anything else is rejected outright: package validation fails and the action does not install. There is no writing scope — the Writing assistant is served the admin action set.
Name your identity parameter from the standard set. Locked to the verified numeric id: client_id, clientid, customer_id, user_id, userid, account_id. Locked to that id as a string: client_identifier, customer_identifier, account_identifier. Locked to the verified email: email, client_email, customer_email, user_email. OpsIQ locks and auto-fills it from the platform-verified signed-in customer; the AI never sees or chooses identity. A non-standard name fails closed (denied, never leaked).
Anything not scoped by that identity: fetch-by-bare-id (order_id/ticket_id alone), store-wide lists, free-text searches. Those are cross-customer leaks on any platform. Keep them "scope":"admin".
Lookup results are structurally trimmed before they reach the AI: secret-shaped keys are dropped, long strings and lists are capped, blank fields are pruned, and a flat map wider than the key cap keeps its answer-bearing keys first, money (credit, balance, amount, total, due, paid), identity (email, *name, phone, company), state (status, active, expir*, renew*), dates, plan/product/domain/service/subscription/order/invoice/ticket fields, currency, counts and stats/summary/totals, before any remaining seats go to other keys smallest-value-first. Practical guidance: name your fields with that standard vocabulary and return the fields that answer the customer's question rather than a raw 100-key platform dump; a field named outside the vocabulary competes for the leftover seats and can be trimmed from very wide payloads.
Two raw operations, policy-free: (1) a payment-verification read filterable by identity AND a transaction reference (your API must AND the filters), e.g. whmcs_get_transactions; (2) a refund execute action (scope:"admin", requires_confirmation:true, is_destructive:true, never customer-exposed), e.g. whmcs_refund_order. The business picks both keys in Settings → Client Chat; OpsIQ re-verifies the payment server-side, applies the business's policy box (amount cap, age window, monthly limit), issues inside the box, and files a review ticket for everything else.
The Connector Builder's action editor has the same controls: set "Who can use it" to Signed-in customers, leave both write checkboxes off, and use a standard identity parameter name.
The "Customer Self-Service" entries in connectors/whmcs/actions.json, woocommerce/actions.json, oscommerce/actions.json; full contract in connectors/README.md §8.1–8.2 and ConnectorInterface::registerActions().
Hotels, couriers and many commerce platforms serve customers who hold a reference but no login: a guest with a booking confirmation, a recipient with a tracking number. The guest_lookup capability (Connector Contract, mode: generated) lets YOUR connector serve those visitors in the client chat AI — no OpsIQ core changes, no platform hardcoding. Your connector declares WHAT proves entitlement and WHICH fields are visible; OpsIQ enforces the switches, the throttle and the uniform deny.
The visitor supplies the record reference (matched by the regex you declare) plus the proof you pick — normally the email on the record. Your fetch action retrieves the record SERVER-SIDE by reference; OpsIQ's generated provider compares the proof against the FETCHED record. The visitor's input is never trusted, and no verified identity is created: the match entitles the visitor to that one record's allowlisted fields, nothing else.
Not-found and proof-mismatch produce ONE identical answer. The AI is explicitly instructed never to confirm whether a reference exists and never to invent record details. Attempts are rate-limited per conversation + IP by core before your connector is ever consulted.
Nothing serves guests until the business enables BOTH switches: the workspace-wide control in Settings → Security → "Guest record lookups in client chat" (permission-gated AND always password-confirmed, even when optional step-up is off), and your connector's own guest_lookup_enabled settings toggle. Installing or enabling a connector alone never opens the guest surface.
The generated provider registers on the guest context surface — structurally separate from admin and customer. Existing context providers are never consulted for anonymous visitors, and the guest provider is never consulted for signed-in ones. The ctx it receives carries the chat message, the thread id and the visitor's asserted (unverified) pre-chat email as a proof candidate — no identity fields.
On the Actions step, add a read-only action that returns ONE record by its reference (e.g. GET /bookings/{booking_number}) and map its response fields with aliases: status, arrival, departure, room_type, customer_email…
On the capability step, enable guest_lookup. A dedicated panel appears: pick the fetch action, name the reference parameter, give the reference pattern (a regex body such as \bBK-[0-9]{4,10}\b), name the record ("booking"), and pick the proof — email on the record (recommended) or none (reference alone, for status-only courier tracking).
Tick exactly the fields a guest may see. Everything else is DROPPED — never redacted. The Builder refuses PII-shaped fields (email, phone, address, payment…) in the allowlist, and the release-gate conformance suite re-checks the same rule before publish, so a hand-edited spec cannot sneak one in. Note that install-time validation covers the manifest and the signature only, so run the conformance suite yourself before you ship. The proof field itself can never be shown.
The Builder emits GuestLookupProvider.php — the canonical hardened implementation, identical for every generated package — and adds the guest_lookup_enabled toggle to your connector's settings. The business arms the two switches and the chat AI starts offering the lookup when a visitor asks about your record type.
Think "what would a courier print on the public tracking page": status, dates, room or service category, counts. Names, contact details, street addresses, payment data and free-text notes have no place in an anonymous chat — the Builder and conformance both refuse them.
The generated provider ends its output with an instruction to answer only from the listed fields and to offer a ticket for anything else. Detail not in the allowlist is "not available in chat" — by design.
The provider re-derives the reference from the visitor's recent messages in the same conversation, so "and when is check-out?" works without re-typing the reference. The matched reference and proof email are remembered on the chat thread as CANDIDATES, so follow-ups do not re-ask. They are candidates only: every turn still re-fetches the record server-side and re-compares the proof before releasing a single field.
A marketplace package may ship its own GuestLookupProvider.php implementing ContextProviderInterface with surfaces(): ['guest']. Follow the generated template's contract exactly — fetch by reference, proof-match server-side, uniform deny, allowlist-only output — and declare guest_lookup in capabilities. Conformance verifies the guest surface and scans the allowlist for PII.
Let the Promotion Studio target campaigns by LIVE client and billing state from YOUR platform: "has an unpaid invoice", "order pending", "subscription cancelled". Any connector (pre-installed, marketplace, or one you build yourself) joins by implementing two small methods. No OpsIQ core changes, no platform hardcoding: your connector appears as a platform in the studio Targeting tab with its own dropdown of facts, and several connectors can be enabled side by side.
Implement audienceCatalog() on your connector class. It returns a label and the list of keys your platform can answer. Each key shows up in the studio dropdown under your platform name.
Implement audienceFlags(array $identity). OpsIQ calls it at delivery time with the VERIFIED logged-in visitor identity (from the widget identity token, the same identity the client chat AI uses). Return a flat key => value map.
Enable the connector. The Promotion Studio Targeting tab grows a "Client & billing" section listing your platform; admins build rules like "unpaid_invoices >= 1"; every fact also becomes a personalization variable such as {unpaid_invoices}.
public function audienceCatalog(): array
{
return ['label' => 'My Billing Platform', 'keys' => [
['key' => 'unpaid_invoices', 'label' => 'Unpaid invoices (count)', 'type' => 'number'],
['key' => 'pending_orders', 'label' => 'Pending orders (count)', 'type' => 'number'],
['key' => 'client_status', 'label' => 'Client status', 'type' => 'text'],
]];
}
public function audienceFlags(array $identity): array
{
// $identity = verified token payload: ['email' => ..., 'id' => ..., 'name' => ...]
$email = strtolower(trim((string)($identity['email'] ?? '')));
if ($email === '') return [];
$client = $this->api('GetClient', ['email' => $email]); // your platform call
if (!$client) return []; // unknown client -> return [] (fails CLOSED)
return [
'unpaid_invoices' => (int)$client['unpaid_count'],
'pending_orders' => (int)$client['pending_orders'],
'client_status' => (string)$client['status'],
];
}Add 'promo_audience' to your connector's capabilities() array so the platform and marketplace list it as audience-capable (discovery also works from method presence, but declaring it is the clean signal). The pre-installed connectors/whmcs connector is the full reference implementation.
Lowercase snake_case, 2-60 chars, matching ^[a-z0-9_]+$. Types: number, text, bool. Undeclared keys returned by audienceFlags() are still usable in rules, but declare everything you support so admins can see it.
The $identity array comes from the signed widget identity token issued by the customer site at login, never from client-supplied fields. If your platform cannot resolve the identity, return an empty array.
On ANY error (API down, client not found, timeout) return []. A rule whose fact is missing makes the campaign NOT show. A billing-targeted popup must never reach the wrong person; OpsIQ enforces this in the rule matcher too.
audienceFlags() is called at most once per connector per page view, and ONLY when a published campaign actually uses your platform's rules. Anonymous visitors cost you zero calls. Keep it to 1-2 API calls; OpsIQ memoizes within the request.
Admins combine your keys with =, !=, >, >=, <, <=, contains, is set, is empty, you only supply values.
Every fact doubles as a variable in campaign copy: {unpaid_invoices}, {client_status}, plus the built-ins {first_name} and {client_email}. Values are sanitized before rendering.
Declarative (JSON-only) marketplace connectors get promo_audience for FREE: if your connector declares customers/users, invoices, orders or subscriptions resources, OpsIQ derives customer_status, unpaid_invoices, amount_due, pending_orders, active_subscriptions and subscription_status from your existing search actions. No code at all.
Add an audience_capabilities object · {"label": "My Platform", "keys": [{"key": "open_carts", "label": "Open carts", "type": "number"}]}, to control exactly which facts (and labels) appear in the studio dropdown.
Connectors > your connector > Enable. Then open any campaign's Targeting tab. Your platform must appear under "Client & billing (connectors)".
Add: Your platform · a key · >= · 1 and set "Logged-in clients only". Save and publish.
Log in to your platform as a client who matches the rule (popup must show) and as one who does not (popup must stay hidden). Logged-out visitors never match logged-in rules.
Beyond the built-in triggers (delay, scroll, exit-intent, idle, click, pages-viewed, chat / ticket activity), you can fire a campaign from anywhere in your site or connector front-end, after a successful checkout step, when a cart is abandoned, when your SPA changes route, etc.
Set the campaign trigger to Custom with an event name (e.g. checkout_failed), then call the global hook from your page:
// Any campaign whose Custom trigger event matches will be evaluated
// (it still respects targeting, frequency caps and audience rules).
window.OpsIQPromo && window.OpsIQPromo.fire('checkout_failed');The survey capability lets any platform supply verified customer identity adapters, audience facts, safe variables and recipient candidates to Survey Studio. It is independent from promo_audience and does not give a connector ownership of surveys, responses, analytics or email delivery.
SurveyConnectorInterface, the dedicated Builder panel, generated SurveyProvider.php, package metadata and conformance isolation all ship. Consumption is not yet wired: SurveyConnectorRegistry is implemented and tested, but no Survey runtime calls it yet, so provider health is not surfaced in the admin UI and no published connector package declares the capability. Signed-token Survey Identity Gateway issuance, targeting and variable integration, CRM Outreach materialization and the first shipped provider mappings remain separate phases. Build against this contract now; expect the runtime to start consuming it in a later release.Declare typed canonical facts and resolve values only for a server-verified, workspace-bound subject. Typical facts include order_count, last_order_status, cancelled_order_count, customer_created_at, active_subscription_count, past_due_invoice_count and open_ticket_count.
Declare customer, account, order, subscription and support variables with type, sensitivity and allowed context. Survey copy requires fallbacks and output-context escaping.
Optionally enumerate candidates for CRM Outreach with stable external IDs, bounded pages, deterministic cursors and consent-related metadata. Survey freezes the chosen audience before any send.
Accept identity only from the Survey Identity Gateway after token signature, expiry, purpose, connector and workspace verification. Browser-supplied email, ID, tags or billing facts are never authoritative.
SurveyConnectorRegistry is designed to report compatible, blocked and unavailable providers without exposing settings, paths, raw identities or exception messages, and a blocked provider can never be invoked. The reporting surface is not yet exposed in the admin UI: today a blocked provider is simply inert.
Undeclared keys, wrong types, oversized values, subject mismatches, connector timeouts and unknown identities are rejected. A targeting rule that needs an unavailable fact does not match. Recipient pages are capped and audited. Sensitive values never appear in public preview or logs.
Contract 2.2 ships the capability registry entry, interface, Survey mapping panel, generated SurveyProvider.php, capability version, README/developer reference and conformance fixtures. Commerce, helpdesk, SaaS bridge and local PHP profiles include it; Standard API connectors opt in. The static gate rejects a Survey provider that calls a Promotion namespace, table or capability.
The reply_feedback capability mirrors a platform's own per-reply ratings into OpsIQ. A star a customer gives a staff reply inside WHMCS's client area lands on the SAME reply in the OpsIQ admin thread, with the same chip, agent credit, Feedback page entry and Team & Performance computation as a rating given on an OpsIQ portal ticket. One storage, one chip, one pipeline; the connector only translates.
There are exactly two entry paths and one truth. OpsIQ portal tickets write natively. Platform tickets flow through the connector, and core lands every event via ReplyFeedback::recordMirrored(): the same columns, staff-only rule, one-rating-per-reply latest-wins semantics, workspace stamp and Voice of Customer indexing the portal write uses. A connector never writes feedback rows itself.
Add the capabilities.reply_feedback entry: version 1.0, the ReplyFeedbackConnectorInterface, methods replyFeedbackCatalog and pullReplyFeedback, implies inbound_ticket.
Add reply_feedback to the capabilities list. This is what connector discovery reads.
Declare reply_feedback.modes (poll and/or webhook) and the platform's rating scale. This is what the conformance gate reads.
Implement the interface, list reply_feedback in capabilities(), then re-sign the package.
Declare modes, the platform's own rating scale (core normalises to the native 1-5), and any reaction tokens. The catalog must agree with spec.json.
pullReplyFeedback returns canonical events: platform ticket id, platform reply id, rating, optional reaction/comment, submitted time and a stable event_id. It reads and translates. It never writes.
event_id is stable per feedback STATE, so a replayed event is a no-op and a changed rating overwrites (latest wins, like the portal).
Pages are bounded and deterministic; a cursor that does not advance ends the run. Historical backfill drains as a rolling window, never one giant pull.
With no configuration, return an empty complete page instead of throwing. The conformance runner probes with empty arguments.
Core resolves each event to a local reply by the mirror marker the ticket mirror already stamps (<slug>:<ticket>:reply:<reply>). An event that cannot be resolved is dropped, never guessed; feedback only attaches to staff replies; and agent credit always comes from the reply's existing author. The rating write never changes authorship. This is why the capability requires inbound_ticket or ticket_mirror.
WHMCS stores client-area per-reply star ratings in tblticketreplies.rating. The WHMCS connector declares poll mode with a 1-5 scale, ships a ticket_reply_ratings relay command in its bridge file, and translates each row into an event whose ids match the whmcs:<ticket>:reply:<reply> markers its ticket mirror already stamps. After upgrading the connector, re-copy the bridge file to the WHMCS server so the new command exists there.
doc/contracts/TICKET_REPLY_FEEDBACK_CAPABILITY.md in the OpsIQ package. Acceptance: rate a reply inside the platform, wait for the hourly poll, and the same reply in OpsIQ shows the chip, the Feedback page lists it, and a replayed event changes nothing.The Marketplace lets you discover, install, and publish connectors built by the community.
Go to Connectors > Marketplace. Search by name, category, or platform.
Check the description, supported actions, and ratings.
Click Install. The connector package downloads and installs to marketplace_connectors/.
Enable it in Connectors, enter API credentials, and test.
Use the Connector Builder. Verify all actions work.
Generate profile.json, actions.json, knowledge.json, and PHP files.
Run php tools/sign_connector.php <slug> to sign ONE package (it also accepts a path). It does not boot OpsIQ, so give it the key: either --key=<secret> or the OPSIQ_CONNECTOR_SIGNING_KEY environment variable, otherwise it stops with "No signing key available". tools/resign_all_connectors.php re-signs EVERY package on the install and reads the key from settings by itself, but it can also mint a NEW install-wide signing key, so reach for it only when that is what you want.
Upload through the marketplace submission flow for review.
The runtime discovery root. Everything here is live: the connectors that ship with OpsIQ, anything installed from the marketplace, and anything the Connector Builder publishes on this install.
The publishing SOURCE for first-party marketplace packages. It is not a discovery root: nothing here is live until it is packaged, signed, seeded into the catalogue and installed, at which point a copy lands in connectors/.
The API and Webhook Builder lets you create custom API endpoints and webhook listeners inside OpsIQ without writing raw PHP.
Run when something happens in OpsIQ, or when an external system posts a matching event to your webhook URL. Type the event name, for example ticket.created.
Use one of the built-in interval events as the event name: cron.minutely, cron.hourly or cron.daily. The Actions and Triggers screen has buttons for these, so you do not have to remember them.
Run when an admin asks the AI for it in plain language. Add the phrase that should match, for example find customer.
An external system sends an HTTP POST to your OpsIQ webhook URL with an event name. Any trigger listening for that event fires.
An event trigger can carry conditions, so it only runs when the incoming data matches. Without conditions it runs every time the event fires.
A path into the event data. Use a dot for nested values, for example customer.email.
Choose whether every rule must match, or just one of them.
equals, does not equal, contains, does not contain, starts with, is one of, is not one of. Matching ignores capitals.
greater than, at least, less than, at most. Numbers written as text still compare correctly.
is present, is missing, is empty, is not empty.
Event ticket.created, with one rule: priority equals urgent.
The action runs for urgent tickets and is skipped for everything else. No filtering needed at your end.
Send HTTP POST to an external URL with a custom payload.
Create a support ticket with specified department, subject, and message.
Send an email with a custom template.
Update a customer, ticket, or CRM record.
Execute a registered action from an enabled connector with its connector permission and confirmation rules.
Search the complete named General API catalog. Fields, scopes, permissions, confirmation, idempotency and dry-run support come from the live action contract; the workflow executes inside its saved workspace and administrator context.
Use a connector Native API Read or confirmed Native API Write action when the provider endpoint has no curated action. Credentials remain inside the connector and only relative provider paths are accepted.
Ready-to-use trigger-action recipes for common automations.
Monitoring system sends POST when server goes down.
Trigger: Inbound webhook Condition: payload.status = "down" Action: Create ticket · Dept: Technical, Subject: "Server {{payload.hostname}} down", Priority: Urgent
Slack message every time a customer places an order over $100.
Trigger: Event (order.completed) Condition: order.amount > 100 Action: Send webhook to Slack incoming webhook URL with order details
Summary email to management every Monday at 9am.
Trigger: Schedule (Monday 09:00) Action: Send email with last week's stats pulled from the REST API
If a ticket has no reply for 24 hours, assign to team lead.
Trigger: Schedule (every hour) Condition: ticket.status = "Open" AND ticket.last_reply_age > 86400 Action: Assign to team-lead, add internal note
This walkthrough creates a simple connector action from scratch.
Before you start, decide which one you need. Both are configured in the same screen.
The action sends an HTTP request to your platform. Choose this when OpsIQ needs to reach out and do something on your side.
The action runs something an installed connector already provides. Choose this when the work is already available and you just want to trigger it. You pick the connector action from a list, so there is nothing to wire up.
Example: "lookup_product". Look up a product by name, return price, stock, and description.
Add the action definition:
{
"actions": [
{
"action_id": "lookup_product",
"label": "Look up a product",
"category": "Catalogue",
"description": "Find a product by name and return price, stock and description.",
"scope": "admin",
"requires_confirmation": false,
"is_destructive": false,
"delivery_type": "http",
"http_method": "GET",
"http_url": "/api/products/search",
"parameters": [
{ "name": "name", "type": "string", "required": true, "in": "query",
"description": "Product name to search for" }
],
"returns": [
{ "alias": "id", "path": "data.id", "type": "string" },
{ "alias": "name", "path": "data.name", "type": "string" },
{ "alias": "price", "path": "data.price", "type": "number" },
{ "alias": "stock", "path": "data.stock_quantity", "type": "number" }
]
}
]
}In the Connector Builder's Review step, press Dry run. It runs the full conformance checklist against your package and, when you have supplied credentials, makes a real connection test. It does not use sample data.
Ask admin AI: "Look up product Widget Pro." The AI should find and execute the action.
Inbound endpoints accept signed JSON from another system and turn it into deduplicated contact activity that can feed timelines, scoring and workflows.
Create one source per sending system. OpsIQ generates a URL/token and secret. Send JSON with Content-Type: application/json and sign the exact raw body using HMAC-SHA256:
X-OpsIQ-Inbound-Signature: sha256=<hex hmac>Map JSON paths for the contact email, event name and optional event ID. The event ID is the preferred deduplication key. Accepted activity enters the contact timeline and can affect lead scoring, segments, lifecycle rules and workflows.
Reject invalid signatures before parsing business data. Rotate a secret by updating both sides inside a controlled window; do not log the secret.
Outbound webhook administration creates signed subscriptions, tests endpoints and monitors asynchronous delivery and retry health.
Full administrators create an HTTPS endpoint, choose specific events or the wildcard, store the secret safely and send a test. OpsIQ signs the raw payload with HMAC-SHA256:
X-OpsIQ-Signature: sha256=<hex hmac>Verify the signature before deserialising or acting. Delivery is asynchronous and automatically retried after approximately 1 minute, 5 minutes, 30 minutes, 2 hours and 12 hours. Use the recent-delivery rail to inspect status, response code and attempt count.
Your receiver must be idempotent because any asynchronous system can redeliver. Return a 2xx response only after durable acceptance.
Webhooks let external systems notify OpsIQ when something happens (inbound), and let OpsIQ notify external systems when something happens internally (outbound).
Go to Settings > Webhooks. Add an endpoint URL and select events to receive.
Subscribe to specific events, or to ["*"] for everything. The full list for your install is below, and webhooks.events.list returns it as JSON.
Failed deliveries retry with exponential backoff. After 15 consecutive failures, the endpoint is auto-disabled.
Every delivery is signed. X-OpsIQ-Signature carries v2=<hex>, and the signed string is version.timestamp.delivery_id.body — not the body alone. Always verify, and always rebuild the string exactly. See the examples below.
OpsIQ will not send to private/internal IPs (127.x, 10.x, 172.16.x, 192.168.x, 169.254.169.254).
Webhooks are delivered via the job queue, not blocking OpsIQ operations.
Each event has a unique event_id that stays the same across retries for deduplication.
The event name, for example ticket.created.
The delivery id. It stays the same across retries — use it to ignore a duplicate.
Unix seconds at signing time. Reject anything older than about five minutes.
The signature as v2=<hex>. Split on the =: the left side is the version, the right side is the value you compare.
The scheme in use, currently v2. Read it from the header rather than hard-coding it, and your code keeps working if a v3 is ever added.
version.timestamp.delivery_id.body, not the raw body on its own. Hashing only the body is the single most common reason a verification fails — every genuine delivery gets rejected and the endpoint looks broken.<?php
// Read the raw body BEFORE any framework parses it — the signature covers
// the exact bytes we sent, so a re-encoded array will not match.
$raw = file_get_contents("php://input");
$sigHeader= $_SERVER["HTTP_X_OPSIQ_SIGNATURE"] ?? ""; // "v2=<hex>"
$ts = (string)($_SERVER["HTTP_X_OPSIQ_TIMESTAMP"] ?? "");
$delivery = (string)($_SERVER["HTTP_X_OPSIQ_DELIVERY"] ?? "");
$secret = "your endpoint signing secret"; // shown once when you add the endpoint
// 1. Refuse a stale delivery. This is what stops a captured request being replayed.
if ($ts === "" || abs(time() - (int)$ts) > 300) {
http_response_code(401);
exit(json_encode(["error" => "Stale delivery"]));
}
// 2. The header names its own version: "v2=<hex>".
[$version, $received] = array_pad(explode("=", $sigHeader, 2), 2, "");
// 3. Rebuild exactly what OpsIQ signed.
$canonical = $version . "." . $ts . "." . $delivery . "." . $raw;
$expected = hash_hmac("sha256", $canonical, $secret);
// 4. Constant-time compare, so a timing attack cannot reveal the secret.
if ($received === "" || !hash_equals($expected, $received)) {
http_response_code(401);
exit(json_encode(["error" => "Invalid signature"]));
}
// 5. Accept. Deliveries retry, so treat a delivery id you have already
// processed as a success and do the work only once.
$event = json_decode($raw, true);
// ... your handling ...
http_response_code(200);
echo json_encode(["received" => true]);const crypto = require("crypto");
// express.raw gives you the exact bytes OpsIQ signed. express.json() does not.
app.post("/opsiq-webhook", express.raw({ type: "application/json" }), (req, res) => {
const raw = req.body; // Buffer
const sig = req.headers["x-opsiq-signature"] || ""; // "v2=<hex>"
const ts = req.headers["x-opsiq-timestamp"] || "";
const delivery = req.headers["x-opsiq-delivery"] || "";
const secret = process.env.OPSIQ_WEBHOOK_SECRET;
// 1. Reject stale deliveries (replay protection).
if (!ts || Math.abs(Date.now() / 1000 - Number(ts)) > 300) {
return res.status(401).json({ error: "Stale delivery" });
}
// 2. Split "v2=<hex>" into its version and its value.
const [version, received] = sig.split("=", 2);
// 3. Rebuild what OpsIQ signed: version.timestamp.delivery_id.body
const canonical = Buffer.concat([
Buffer.from(`${version}.${ts}.${delivery}.`),
raw,
]);
const expected = crypto.createHmac("sha256", secret).update(canonical).digest("hex");
// 4. Constant-time compare. Lengths must match first or timingSafeEqual throws.
const a = Buffer.from(expected), b = Buffer.from(received || "");
if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
return res.status(401).json({ error: "Invalid signature" });
}
// 5. Accept, and make the work idempotent on the delivery id.
const event = JSON.parse(raw.toString("utf8"));
res.json({ received: true });
});Generated from the running build, so it always matches the version you are on.
webhooks.events.list returns this same list as JSON, so your code never has to hard-code it.Fired by PHASE_ANOMALY_ALERTS when a daily KPI (sessions, pageviews, conversions, revenue) deviates from its same-weekday 4-week baseline beyond the configured threshold. Payload: day (required), title, site_key, anomalies.
Fired the moment a chat-confirmed order lands on the merchant platform (connector or custom-actions integration) - before payment. Subscribe to sync carts, reserve stock, or notify fulfilment systems. Payload: reference (required), connector, amount_minor, currency, customer_email, thread_id, occurred_at.
Fired exactly once per order when the gateway actively verifies the payment (amount and currency exact). This is the settlement signal - it rides the same claim that prevents duplicate receipts, so it can never double-fire. Payload: reference (required), connector, occurred_at.
Fired by OpsIQ.
Fired by OpsIQ.
Fired by OpsIQ.
Fired by OpsIQ.
Fired by OpsIQ.
Fired by OpsIQ.
Fired when a conversation is assigned to an agent or unassigned. Payload: thread_id (required), site_key, assigned_admin_id, by_admin_id, occurred_at.
Fired when a new Client Chat conversation (thread) is opened. Payload: thread_id (required), site_key, channel, client_email, client_name, visitor_id, created_at.
Fired when a visible message is written to a conversation by the visitor, an agent, the AI or the system. Internal notes do not fire. Payload: thread_id (required), message_id (required), site_key, sender_type, admin_id, message, has_attachment, created_at.
Fired when the visitor rates a conversation (1-5 stars). Payload: thread_id (required), site_key, stars, comment, trigger, admin_id, occurred_at.
Fired when an agent resolves a conversation and hands it back to the AI. Payload: thread_id (required), site_key, by_admin_id, occurred_at.
Fired when a CRM company/account is created. Payload: company_id (required), name.
Fired when a CRM deal/opportunity is created (by an order, the capture agent, or a human). Payload: deal_id (required), title, amount, currency, scope.
Fired when a deal is moved to a Lost stage (closed-lost). Payload: deal_id (required), stage, amount.
Fired when a deal moves to a different pipeline stage. Payload: deal_id (required), stage, amount.
Fired when a deal is moved to a Won stage (closed-won). Payload: deal_id (required), stage, amount.
Fired when a CRM task is created (incl. AI-suggested next-step / renewal tasks). Payload: task_id (required), title.
Fired by OpsIQ.
Fired by OpsIQ.
Fired when a Voice-of-Customer analysis run completes. Payload: analysis_run_id (required), workspace_key, sample_count, model_version.
Fired when a newly indexed response meets its metric-specific detractor rule. Payload: feedback_item_id (required), workspace_key, source_kind, metric_kind, classification.
Fired when a Feedback follow-up is completed. Payload: feedback_item_id (required), workspace_key, actor_admin_id, outcome_code.
Fired when Feedback ownership changes. Payload: feedback_item_id (required), workspace_key, assignee_admin_id, team_id, actor_admin_id.
Fired when a source record is added to or refreshed in the canonical Feedback index. Payload: feedback_item_id (required), source_kind, source_id, workspace_key, metric_kind, classification.
Fired when source deletion or redaction removes Feedback content from the index. Payload: feedback_item_id (required), workspace_key, source_kind.
Fired when the Feedback workflow state changes. Payload: feedback_item_id (required), workspace_key, state, actor_admin_id.
Fired when a tag is added to or removed from Feedback. Payload: feedback_item_id (required), workspace_key, tag, operation.
Fired when a canonical Feedback item changes. Payload: feedback_item_id (required), workspace_key, change.
Fired when a Feedback source replay or incremental index operation fails. Payload: workspace_key, source_kind (required), error_code, checkpoint.
Fired when a Feedback source checkpoint is behind its expected freshness window. Payload: workspace_key, source_kind (required), lag_seconds, last_success_at.
Fired when a canonical topic or theme signal is attached to Feedback. Payload: feedback_item_id (required), workspace_key, theme_key, confidence.
Fired when an urgent Feedback signal is detected. Payload: feedback_item_id (required), workspace_key, source_kind, signal_key.
Fired when an invoice is generated. Payload: invoice_id (required), customer_id, customer_email, amount, currency, due_date, items.
Fired when an invoice passes its due date unpaid. Payload: invoice_id (required), customer_id, customer_email, amount, currency, days_overdue.
Fired when an invoice is paid in full. Payload: invoice_id (required), customer_id, customer_email, amount, currency, paid_at.
Fired when a new order is placed. Payload: order_id (required), customer_id, customer_email, amount, currency, items, status, source.
Fired when a payment succeeds. Payload: order_id (required), payment_id, provider_ref, customer_id, customer_email, amount, amount_minor, currency, gateway, invoice_id, items, paid_at.
Fired when a payment attempt fails. Payload: order_id, customer_id, customer_email, amount, currency, gateway, reason.
Fired when a refund is issued. Payload: order_id, refund_id, customer_id, customer_email, amount, currency, reason.
Fired by PHASE_SECURITY_ALERTS when a security rule trips: failed-login wave, new automatic IP blocks, or a tamper-evidence (audit/consent hash chain) verification failure. Payload: rule (required), title, site_key, count, blocks, errors.
Fired when a subscription is cancelled. Payload: subscription_id (required), plan_name, customer_id, customer_email, cancel_reason, cancelled_at, ends_at.
Fired when a subscription is started. Payload: subscription_id (required), plan_id, plan_name, customer_id, customer_email, amount, currency, interval, trial_ends_at, next_billing_at.
Fired when a subscription renews successfully. Payload: subscription_id (required), plan_name, customer_id, customer_email, amount, currency, next_billing_at.
Fired when a ticket is closed or resolved. Payload: ticket_id (required), resolution, closed_by_type, closed_by_id.
Fired when a new support ticket is opened. Payload: ticket_id (required), ticket_number, subject, department_id, department_name, customer_id, customer_email, priority, message, author_type, author_id, author_name.
Fired when a connector mirror adopts the remote platform's ticket number for an OpsIQ ticket. Payload: ticket_id (required), old_number (required), ticket_number (required), connector, external_ref.
Fired when a reply is posted to a ticket. Payload: ticket_id (required), reply_id, author_type, author_id, author_name, message.
Fired when a new user/customer account is created. Payload: user_id (required), email, firstname, lastname, company, country, source.
Use ngrok to expose your local server. Set the webhook endpoint to your ngrok URL.
OpsIQ retries with exponential backoff. If your endpoint recovers within the retry window, no events are lost.
API keys authenticate requests to the OpsIQ REST API. Each key has scoped permissions.
Navigate to API key management.
Give it a descriptive name.
Give the key only what it needs. Scopes come in read and write pairs per area, so a reporting integration can be granted reads and nothing else.
Pick the narrowest set that does the job. admin satisfies every scope below, so use it only when you genuinely need broad access.
Contacts, companies, deals, activities, segments, outreach, conversions, lifecycle and CRM webhooks.
List and read tickets and their messages; reply, update, open and run bulk queue operations.
Read live-chat conversations and message history; send messages, assign and change status.
Knowledge base entries.
Saved reply templates.
See which connectors are installed, what they can do, and test their credentials.
See your actions, triggers and their run history.
Departments available for routing.
Notifications for a named operator.
Report sections, CSV exports and scheduled report definitions.
Monitored sites and their SEO reports.
Signed download links for attachments.
Status page components and incidents.
AI writing helpers: draft, summarise, translate, rewrite, compose, analyse.
Everything, including a small number of sensitive actions that are deliberately not reachable by any narrow scope: erasing a contact, changing privacy settings, and reading the access log.
The key may call anything its scopes allow.
Every write is refused, whatever the scopes say. The safest choice for reporting, dashboards and anything that should never change data.
You list the exact actions the key may call. Anything else is refused, even within an allowed scope.
Shown once. Starts with "opq_". Store it securely.
The OpsIQ widget is a JavaScript snippet you add to your website for tracking, AI chat, ticket creation, and customer identification.
<script src="https://your-opsiq-domain.com/widget.php" data-site-key="site_abc123" async></script>
Paste before the closing </body> tag. The script loads asynchronously and does not block page rendering.
Required. Your site key from Connected Sites.
Optional. "chat" (default), "tickets", or "both".
Optional. "bottom-right" (default) or "bottom-left".
Optional. Primary color hex code.
Optional. Initial greeting message.
Optional. UI language: "en", "es", "fr", "de", "pt", "ar", etc.
Optional. Server-generated signed identity token.
// Manually notify OpsIQ of a route change (for custom routers)
window.OpsIQ = window.OpsIQ || [];
window.OpsIQ.push(["pageview", {
url: window.location.href,
title: document.title,
}]);script-src 'self' https://your-opsiq-domain.com; connect-src 'self' https://your-opsiq-domain.com; frame-src https://your-opsiq-domain.com;
No. Under 15 KB gzipped, loads async after page content.
Use data-color for primary color. Contact support for CSS override options.
Platform-specific installation guides.
Add to all pages of a WordPress site.
Option 1: Edit theme footer.php, paste snippet before </body>. Option 2: Use "Insert Headers and Footers" plugin > Scripts in Footer. Option 3: Use a child theme footer.php to survive theme updates.
Add to your Shopify store.
Online Store > Themes > Edit Code > Layout > theme.liquid. Paste before </body>. Save.
Add to a React or Next.js app.
In Next.js, use next/script in app/layout.tsx: import Script from "next/script"; <Script src="https://your-opsiq.com/widget.php" data-site-key="site_abc" strategy="lazyOnload" />
Add to your WHMCS client area.
Setup > General Settings > Other > Global Footer Content. Paste the snippet. Or edit your template footer.tpl.
Add via GTM.
Create Custom HTML tag, paste snippet. Trigger: All Pages. Publish.
Embed the OpsIQ admin assistant — admin chat, ticket inbox and AI Writing — inside YOUR OWN platform's admin panel, so your team never leaves their tools. Like visitor identity and portal SSO, this is ONE generic contract implemented in ~15 lines of your platform's server code — the same pattern Zendesk, Intercom and Discourse use for SSO. There is no per-platform plugin to wait for: any stack that can compute an HMAC can do this today.
From Remote Sites → your site → Codes, copy the loader line and add it to your admin panel's pages (footer include, layout template, or an admin-only custom-JS box):
<script async src="https://YOUR-OPSIQ/opsiq/embed/admin_widget.php?site_key=SITE_KEY&identity_token=TOKEN_FROM_STEP_2"></script>
Only YOUR application knows which admin is signed in — that is not a shortcoming, it is the security model. Your server generates a short-lived signed token from your own session, exactly like the visitor identity token, signed with the same site webhook secret:
<?php
$secret = "opsiq_whsec_your_site_secret"; // Remote Sites → Codes
$payload = json_encode([
"site_key" => "SITE_KEY",
"iat" => time(),
"exp" => time() + 6 * 3600,
"authenticated" => true, // REQUIRED, top level — see note below
"platform" => "your-platform",
"admin" => [
"id" => (string)$admin->id, // from YOUR session
"name" => $admin->name,
"username" => $admin->username,
"email" => $admin->email,
"role" => $admin->role,
"authenticated" => true,
],
]);
$payload64 = rtrim(strtr(base64_encode($payload), "+/", "-_"), "=");
$identityToken = $payload64 . "." . hash_hmac("sha256", $payload64, $secret);
// Put $identityToken into the embed line (identity_token=…), or expose it as
// window.OpsIQAdminIdentityToken before the loader script.Every admin who logs into your platform is matched individually: OpsIQ's per-admin access gate resolves the token's username + email against one OpsIQ agent (Team page; use the agent's "match emails" list when platform emails differ) and applies THAT agent's workspace, department and inbox permissions. New staff member = add the agent in OpsIQ; no embed changes.
Whatever role string your platform sends is shown on the OpsIQ side for attribution; authorization always comes from the OpsIQ agent record, never from the asserted role.
Browsers never send your admin cookie to another origin — no vendor can "just detect" your login cross-domain. Every serious product solves this the same way: your server vouches, signed. That is the whole contract.
Skip step 2 and use the static token from Remote Sites → Codes in the loader line (token=… instead of identity_token=…). The widget works with the workspace's shared identity; the per-admin gate can stay enforced later when the team grows.
authenticated flag — put it at the TOP levelThis flag is your server's assertion that a human is really logged in, and OpsIQ refuses any token without it. Put "authenticated" => true beside site_key/iat/exp, NOT only inside the admin object. Current OpsIQ accepts it in either position, but older releases only read the top level — and the failure is deceptive: conversation list, history and unread all authenticate fine while every chat turn answers "Admin login required", which looks like a session bug and is not. If you see exactly that split, check this flag first.
Sign on the server only, never in browser JavaScript. Keep exp short (minutes to hours); OpsIQ rejects expired and future-dated tokens, and the signature binds the token to your site key.
The WHMCS module does this automatically from the WHMCS admin session; the Botble Hotel connector's bridge file does it from the Laravel session (op=admin_identity). Both are just this contract in their platform's dialect — copy whichever reads closest to your stack.
When your OpsIQ connector stores your identity endpoint in its admin_identity_probe_url setting, the PLAIN loader line is all your admin pages need: the widget discovers the probe from the connector, calls it with your site key + widget token, and authenticates each admin automatically. The page can still override with a data-identity-endpoint attribute or window.OpsIQAdminIdentityEndpoint.
If your platform is Laravel (Botble, Bagisto, custom apps) and your endpoint is a standalone file that boots the framework to read the logged-in admin, three specifics will save you hours — each one produced a real production failure before it was learned:
Your service providers may resolve request from the container during boot. Laravel's own lifecycle binds the captured request first thing inside Kernel::handle() — mirror that order: $app->instance('request', Request::capture()) BEFORE $kernel->bootstrap(), or you get "Target class [request] does not exist".
Modern Laravel prefixes cookie values with an HMAC computed WITH THE APP KEY (CookieValuePrefix) — a plain sha1(name."v2") can never match it. Strip with CookieValuePrefix::validate($name, $decrypted, $keys), with a structural fallback (40 hex chars + | at position 40). Tell: a session id longer than 40 chars (81 = prefix still attached) and a session that loads with only _token in it.
The auth stamp is login_<guard>_<sha1(guard class)> — for the default web guard: 'login_web_' . sha1(Illuminate\Auth\SessionGuard::class). Scan any login_* numeric key as a fallback for custom guards.
Ship a debug=1 mode that names the failing STEP and exception — a blind catch-all made a live deployment undiagnosable. The Botble bridge (from v1.0.7) is the reference: step markers at kernel/bind/bootstrap/decrypt/session/auth/db.
<?php
/* identity endpoint · LARAVEL (Botble, Bagisto, any Laravel admin)
* Drop this in your PUBLIC web root, e.g. /opsiq-identity.php
* Answers: {"success":true,"authenticated":true,"admin":{...},"identity_token":"..."} */
define("OPSIQ_SITE_KEY", "SITE_KEY");
define("OPSIQ_SITE_SECRET", "opsiq_whsec_your_site_secret"); // Remote Sites → Codes
header("Content-Type: application/json");
$step = "boot";
try {
require __DIR__ . "/../vendor/autoload.php";
$app = require_once __DIR__ . "/../bootstrap/app.php";
$step = "bind";
// ORDER MATTERS: bind the request BEFORE bootstrapping, or providers that
// resolve "request" during boot throw "Target class [request] does not exist".
$request = Illuminate\Http\Request::capture();
$app->instance("request", $request);
$step = "bootstrap";
$kernel = $app->make(Illuminate\Contracts\Http\Kernel::class);
$kernel->bootstrap();
$step = "session";
$app["session"]->driver()->setId($request->cookie(config("session.cookie")));
$app["session"]->driver()->start();
$step = "auth";
$user = auth()->guard("web")->user(); // use YOUR admin guard name
if (!$user) {
echo json_encode(["success" => false, "authenticated" => false, "error" => "no admin session"]);
exit;
}
$step = "sign";
$admin = [
"id" => (string)$user->id,
"name" => (string)($user->name ?? $user->username),
"username" => (string)($user->username ?? $user->email),
"email" => (string)$user->email,
"role" => (string)optional($user->roles->first())->name,
"authenticated" => true,
];
$payload = json_encode([
"site_key" => OPSIQ_SITE_KEY,
"iat" => time(),
"exp" => time() + 6 * 3600,
"authenticated" => true, // TOP LEVEL — required
"platform" => "laravel",
"admin" => $admin,
], JSON_UNESCAPED_SLASHES);
$p64 = rtrim(strtr(base64_encode($payload), "+/", "-_"), "=");
$token = $p64 . "." . hash_hmac("sha256", $p64, OPSIQ_SITE_SECRET);
echo json_encode(["success" => true, "authenticated" => true,
"admin" => $admin, "identity_token" => $token]);
} catch (\Throwable $e) {
// debug=1 names the failing STEP — never ship a blind catch-all
$err = ($_GET["debug"] ?? "") === "1"
? get_class($e) . " at [" . $step . "]: " . $e->getMessage()
: "identity unavailable";
echo json_encode(["success" => false, "authenticated" => false, "error" => $err]);
}Only the "who is logged in?" line changes — the signing block is identical everywhere. Sign on the server, never in JavaScript.
<?php
/* The ONE helper every platform shares. Keep it verbatim. */
function opsiq_identity_token(array $admin, string $siteKey, string $secret, string $platform): string {
$payload = json_encode([
"site_key" => $siteKey,
"iat" => time(),
"exp" => time() + 6 * 3600,
"authenticated" => true, // TOP LEVEL — OpsIQ refuses the token without it
"platform" => $platform,
"admin" => $admin + ["authenticated" => true],
], JSON_UNESCAPED_SLASHES);
$p64 = rtrim(strtr(base64_encode($payload), "+/", "-_"), "=");
return $p64 . "." . hash_hmac("sha256", $p64, $secret);
}
/* ── WORDPRESS ─────────────────────────────────────────────────────────── */
require_once ABSPATH . "wp-load.php";
if (!current_user_can("manage_options")) { /* not an admin → refuse */ }
$u = wp_get_current_user();
$admin = ["id" => (string)$u->ID, "name" => $u->display_name,
"username" => $u->user_login, "email" => $u->user_email,
"role" => implode(",", $u->roles)];
/* ── WHMCS (inside an addon/hook, admin area) ──────────────────────────── */
$aid = (int)($_SESSION["adminid"] ?? 0);
if ($aid <= 0) { /* not an admin → refuse */ }
$row = Capsule::table("tbladmins")->where("id", $aid)->first();
$admin = ["id" => (string)$row->id, "name" => trim($row->firstname . " " . $row->lastname),
"username" => $row->username, "email" => $row->email, "role" => "administrator"];
/* ── SYMFONY ───────────────────────────────────────────────────────────── */
$u = $security->getUser(); // Symfony\Bundle\SecurityBundle\Security
if (!$u) { /* not an admin → refuse */ }
$admin = ["id" => (string)$u->getId(), "name" => $u->getName(),
"username" => $u->getUserIdentifier(), "email" => $u->getEmail(),
"role" => implode(",", $u->getRoles())];
/* ── PLAIN PHP / your own app ──────────────────────────────────────────── */
session_start();
if (empty($_SESSION["admin_id"])) { /* not an admin → refuse */ }
$admin = ["id" => (string)$_SESSION["admin_id"], "name" => $_SESSION["admin_name"] ?? "",
"username" => $_SESSION["admin_username"] ?? "", "email" => $_SESSION["admin_email"] ?? "",
"role" => $_SESSION["admin_role"] ?? ""];
/* ── then, on EVERY stack ──────────────────────────────────────────────── */
$token = opsiq_identity_token($admin, "SITE_KEY", "opsiq_whsec_your_site_secret", "wordpress");
echo json_encode(["success" => true, "authenticated" => true,
"admin" => $admin, "identity_token" => $token]);Your endpoint returned no identity_token. Open the endpoint URL directly in the logged-in admin browser with &debug=1 — you will see the failing step. On Laravel this is nearly always the request-binding or cookie-prefix item above.
The classic split. Your token is missing the TOP-LEVEL authenticated flag — the widget's own endpoint accepts the token, the shared verifier behind the chat stream refuses it. Add "authenticated" => true beside exp.
The token verified, but its username + email match no OpsIQ agent. Add the agent in OpsIQ → Team, or add the platform email to that agent's match-emails list when it differs from their OpsIQ email.
A CORS preflight is rejecting one of your request headers. Your endpoint must answer OPTIONS and echo the requesting origin, or simply avoid custom headers — the widget only needs the cookie.
Check exp: tokens are short-lived by design. The widget re-probes automatically, so this usually means the endpoint stopped seeing the session — an app key rotation, a session-driver change, or a cookie-domain change.
Identity connects anonymous visitors to known customers. When identified, OpsIQ links browsing history, chats, and tickets to the customer profile.
You tell the widget who the visitor is with a plain JavaScript object. It fills the email and customer id on the visitor log, so your dashboard shows signed-in traffic and sessions join up. It is a HINT: anyone can edit it in their browser, so OpsIQ never releases account data on the strength of it.
Your server signs a short-lived token with the site webhook secret. OpsIQ verifies the signature and only then treats the person as a proven customer. This is the level that unlocks account answers in customer chat and connector lookups. Use it for anything a stranger must not see.
Set the object BEFORE the widget script, or call identify() later once your app knows who is signed in. Both forms are read; use whichever fits your page.
<!-- Form A: set the global before the loader -->
<script>
window.OpsIQClient = {
id: "cust_1001",
email: "[email protected]",
name: "Jane Smith",
plan: "pro"
};
</script>
<script async src="https://YOUR-OPSIQ/widget.php?site_key=YOUR_SITE_KEY"></script>
<!-- Form B: identify later, e.g. after a client-side login -->
<script>
window.opsiq.identify({
id: "cust_1001",
email: "[email protected]",
name: "Jane Smith",
plan: "pro"
});
</script>Exactly the same token contract as the admin widget, with a customer subject instead of an admin one. Sign it on your server and pass it to the widget. Two details decide whether it verifies, and both are easy to get wrong:
Sign $payload64, not $payload. Signing the raw JSON produces a token that looks right and is rejected every time with a signature mismatch.
Translate +/ to -_ and strip the = padding. Plain base64 happens to survive today; base64url is the contract and is what every OpsIQ verifier and reference connector emits.
Beside site_key, iat and exp. It is your assertion that a real human is logged in, and OpsIQ refuses the token without it.
A token carrying only an email verifies as a signature and is then silently dropped. Always send an id.
Minutes to hours. The token is a session assertion, not a credential to store.
<?php
/* Server-signed customer identity. Runnable as-is: set the two constants. */
$siteKey = "YOUR_SITE_KEY"; // Remote Sites -> Codes
$secret = "opsiq_whsec_your_site_secret"; // Remote Sites -> Codes
$payload = json_encode([
"site_key" => $siteKey,
"iat" => time(),
"exp" => time() + 3600,
"authenticated" => true, // TOP LEVEL - required
"platform" => "your-platform",
"customer" => [
"id" => (string)$user->id, // REQUIRED
"email" => (string)$user->email, // REQUIRED
"name" => (string)$user->name,
"plan" => (string)($user->plan ?? ""),
"authenticated" => true,
],
], JSON_UNESCAPED_SLASHES);
/* base64url(payload) . "." . hex HMAC-SHA256 OF THAT STRING. */
$payload64 = rtrim(strtr(base64_encode($payload), "+/", "-_"), "=");
$token = $payload64 . "." . hash_hmac("sha256", $payload64, $secret);
/* Hand it to the widget either way: */
printf(
'<script async src="https://YOUR-OPSIQ/widget.php?site_key=%s&identity_token=%s"></script>',
rawurlencode($siteKey),
rawurlencode($token)
);
// or, if the loader is already on the page:
// echo '<script>window.opsiqConfig = window.opsiqConfig || {}; '
// . 'window.opsiqConfig.identityToken = ' . json_encode($token) . ';</script>';customer subject, passed as identity_token to widget.php. Covered above.
admin subject, passed to opsiq/embed/admin_widget.php. Same signer, different subject key. See "Admin widget in your backend".
A stricter variant: the same claims plus jti and single_use:true, and a 120-second life, because the token travels in a URL and must be spendable once. Do not hand-roll it. Settings, Support Portal has a ready snippet for your language, and the platform mints it for you when your account area runs on this server.
They become anonymous until they are identified again. OpsIQ links the new anonymous record to the customer profile the moment a hint or a token arrives.
That is the Level 1 / Level 2 split. An unsigned hint fills the visitor log and nothing else. Account answers need a verified signature.
OpsIQ provides SDK packages and plugins for common platforms.
Composer package: identity token generation, action API helpers, webhook signature verification.
Browser-side: tracking, identity, custom events, chat control.
Widget injection, identity from WP user sessions, WooCommerce sync.
Full integration: widget, ticket relay, identity, admin AI.
App embed with automatic customer identity.
composer require opsiq/sdk
use OpsIQ\SDK\Identity;
$token = Identity::createToken(
siteKey: "site_abc123",
secret: "opsiq_whsec_your_secret",
customer: ["id" => "cust_1001", "email" => "[email protected]", "name" => "Jane"]
);
// Call any catalog action over the action API
$ch = curl_init("https://your-opsiq.com/api/v1.php");
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
"Authorization: Bearer opq_your_key",
"Content-Type: application/json",
],
CURLOPT_POSTFIELDS => json_encode([
"action" => "crm.contacts.list",
"status" => "lead",
"limit" => 25,
]),
]);
$contacts = json_decode(curl_exec($ch), true);Survey Studio is designed to use the same typed General API, internal executor, event bus and webhook operations as the rest of OpsIQ. This lets developers integrate end to end without building a packaged connector.
platform.get.survey.config and platform.save.survey.config. The surveys.* and feedback.* families below are the approved target contract and must return unknown_action until registered.surveys.types.*, surveys.templates.* and surveys.quick_launch.* list, preview, instantiate and validate complete starters.
surveys.create|get|list|update|archive|duplicate plus immutable version, validation and publish actions.
surveys.deployments.*, surveys.links.*, surveys.audiences.*, surveys.triggers.* and surveys.variables.*.
surveys.invitations.*, surveys.campaigns.*, surveys.recipients.*, surveys.responses.*, exports, redaction and analytics.
surveys.webhooks.*, surveys.imports.*, feedback.items.*, feedback.analytics.*, feedback.sources.* and feedback.analysis.*.
Use typed surveys.* actions with a workspace-pinned key. Writes declare permission, risk, confirmation, idempotency and dry-run behavior.
Send a signed event to an inbound webhook, for example an order cancellation or completed onboarding step. Replay protection deduplicates the event ID.
Choose an OpsIQ General API action such as issuing a Survey invitation or preparing a campaign, then map fields from the verified trigger payload.
Deliver the documented business-safe survey.* lifecycle subset to your endpoint with signature, filter, retry, log and authorized replay.
The shared catalog will cover Survey/deployment publish state, audience and trigger decisions, invitations, render/start/partial/resume/complete/abandon, response redaction, campaign state and delivery failures. High-volume focus, scroll and question timing stay in Survey Analytics storage unless explicitly documented for fan-out.
The OpsIQ REST API lets you programmatically access all platform features.
Send the key as Authorization: Bearer opq_... or X-OpsIQ-Key: opq_.... Use one authentication header, not both.
POST https://your-opsiq-domain.com/api/v1.php
Authorization: Bearer opq_your_api_key
# Alternative header: X-OpsIQ-Key: opq_your_api_key
Content-Type: application/json
{
"action": "endpoint.name",
"site_key": "site_abc123"
}The API is action-based: send an action name in the body. Every registered administrator JSON operation has a stable named action. POST {"action":"meta.actions"} (no key required) for the authoritative, per-install list, request contract, risk metadata and scope. The deprecated platform.routes.* bridge remains only for older integrations.
List CRM contacts (scope crm.read). Params: q, status, source, tag, lead score, limit.
Resolve-or-create a contact (scope crm.write). Params: email plus fields, tags, notes.
List CRM deals (scope crm.read). Params: status, stage_id, company_id, owner_admin_id, pipeline_id, limit.
Record a lifecycle/business activity for a contact (scope crm.write). Params: email or contact_id, event, value, currency.
Record a conversion (scope crm.write). Params: contact_id or email, conversion_type, value, currency.
Poll the CRM event stream (scope crm.read). Params: limit.
List tickets (scope tickets.read). Params: page, per_page, sort, order, status, priority, department_id, assigned_admin_id, client_email, search.
One ticket and its messages (scope tickets.read). Params: ticket_id or ticket_number, include_messages, messages_limit.
Post a reply to a ticket (scope tickets.write). Params: ticket_id or ticket_number, body, author_type, author_name, internal.
Update a ticket (scope tickets.write). Params: ticket_id or ticket_number, status, priority, subject, department_id, assigned_admin_id.
Open a support ticket (scope tickets.write). Params: customer_email, customer_name, subject, body, priority.
Run a bulk queue operation (scope tickets.write). Params: operation, ids.
List live-chat conversations (scope conversations.read). Params: page, per_page, status, assigned_admin_id, client_email, search.
One conversation and its messages (scope conversations.read). Params: conversation_id or thread_key, include_messages.
Paged message history (scope conversations.read). Params: conversation_id, page, per_page, include_internal.
Send a message into a conversation (scope conversations.write). Params: conversation_id, message, sender_type, internal.
Assign, re-status or re-title a conversation (scope conversations.write). Params: conversation_id, status, assigned_admin_id, subject.
See which connectors are installed, what each one can do, and whether its credentials work (scope connectors.read).
The actions your Actions builder will run (scope automations.read).
What will fire and on which conditions (scope automations.read).
Execution history for debugging an integration (scope automations.read). Params: status, action_key.
Departments you can route a ticket to (scope departments.read).
Notifications for one operator (scope notifications.read). Params: admin_id (required), unread_only.
A report section as CSV (scope analytics.read). Params: section, preset, from, to. Call analytics.sections.list for valid values.
Monitored sites and their SEO reports (scope site_intelligence.read).
Your Store catalogue, paged (scope commerce.read). Filters: active, category, search. .get returns one product with its variants.
Store orders (scope commerce.read). Filters: status, payment_method, channel, customer_email. Fetch one by order_id or its ORD- reference, with line items. The live gateway checkout handle is never returned.
Refund requests and their state (scope commerce.read).
Price an item for a customer (scope commerce.write). Source store or a connector slug. Creates nothing: no order, no payment. See the Commerce section.
Customer-satisfaction responses as data (scope tickets.read). Filter by rating, ticket, agent or period; .metrics returns the same numbers the dashboard shows.
Chat conversations your visitors rated, with the comment, what prompted the rating and the agent credited (scope conversations.read).
Page through your Help Center articles (scope kb.read).
One Help Center article by id (scope kb.read). Params: article_id.
Every event you can subscribe a webhook endpoint to, with its payload. Available on every plan, so you can build against it before you buy.
A short-lived signed download link for an attachment (scope files.read). Params: reference, ttl.
Ask whether an IP or email is blocked or suspicious here (scope security.read). Combines the IP firewall, the ticket spam blocklist and the cached Security AI verdict. Params: ip, email.
Report abuse your system observed (scope security.write). Recorded as a security event, classified by the Security AI immediately, and admins are alerted on high-risk verdicts. Params: ip, email, kind, reason, source.
Manage the spam rules the ticket pipeline enforces (scope security.write / security.read). Same store as the Tickets page "Block sender" control. Params: kind (email, domain, ip), value, reason, expires_hours.
Every list action uses the same parameters, so you learn them once.
Page number starting at 1, and page size. Default 50, maximum 200. limit and offset are also accepted if you prefer them.
Field to sort by, and asc or desc (default desc). Each action accepts a fixed set of sort fields; anything else is ignored rather than erroring.
Send filters as an object, or pass a filter as a top-level parameter. Unknown filters are ignored.
items, page, per_page, count, total and has_more. Keep requesting pages until has_more is false.
POST /api/v1.php
Authorization: Bearer opq_your_api_key
{
"action": "tickets.list",
"status": "open",
"priority": "urgent",
"sort": "created_at",
"order": "desc",
"page": 1,
"per_page": 50
}Every failure returns the same shape, with a stable code you can branch on. Do not match on the human-readable error text, which may be reworded.
{
"success": false,
"code": "missing_scope",
"error": "API key missing required scope. Needed one of: tickets.read, admin",
"request_id": "req_8f2c1a9d4b7e"
}No key was sent, or the key is wrong or expired. HTTP 401.
The key is valid but lacks the scope this action needs. HTTP 403.
The key is read-only, or this action is not in its allow-list. HTTP 403.
No such action. Call meta.actions for the current list. HTTP 400.
A required parameter is absent, or a value is not accepted. HTTP 400.
The record does not exist, or is not in the workspace this key can see. HTTP 404.
Your plan does not include the feature this action belongs to. The body names the feature, the plan_name in force and an upgrade_url. Retrying will not help; the plan has to change. HTTP 402.
The installation's licence is not active, so no action will run until it is restored. HTTP 402.
Commerce-specific: the store has selling switched off, so nothing can be quoted or ordered. HTTP 400.
The hourly limit for this key is used up. HTTP 429.
Something failed on our side. The request_id identifies the attempt if you need to report it. HTTP 500.
If a write times out you cannot tell whether it landed. Send an idempotency_key and a repeat of the same call returns the original result instead of doing the work twice.
{
"action": "tickets.reply",
"ticket_id": 4192,
"body": "Thanks, that is now fixed.",
"idempotency_key": "your-unique-id-for-this-attempt"
}A key is remembered for 24 hours against the same action and API key.
The original response, plus idempotent_replay: true so you can tell it was a replay.
Only successful writes are remembered. If a call failed, sending it again with the same key runs it again, which is what you want.
Reads ignore the key. Repeating a read is harmless.
Add dry_run: true to any write. Your key, scopes and parameters are all checked exactly as normal, then the call stops before anything is created or changed.
{
"action": "tickets.update",
"ticket_id": 4192,
"status": "closed",
"dry_run": true
}
{
"success": true,
"dry_run": true,
"would_execute": true,
"message": "Authorised and validated. No write was performed because dry_run was set."
}A configurable hourly limit per API key (default 1000 requests per hour). Set it per key under Settings, API Keys.
HTTP 429 with code rate_limited, plus a Retry-After header telling you how many seconds to wait. The limit resets at the top of the next clock hour.
Every response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (a Unix timestamp). Watch Remaining and slow down before you run out rather than waiting to be refused.
A 429 means wait and try again. A 401 means the key itself is wrong or expired, so retrying will not help until you fix the key.
Repeated failed-auth attempts from one IP are throttled separately. Valid keys never trip this.
Back off when Remaining gets low, and honour Retry-After after a 429 instead of retrying immediately.
v1. Every response carries X-OpsIQ-API-Version and X-OpsIQ-API-Status so you can confirm what you are talking to.
If a version is ever retired, responses gain standard Deprecation and Sunset headers, and meta.actions reports deprecated and sunset_at. Check those in your monitoring and you will never be surprised.
Existing action names, their parameters and their error codes. New actions and new optional fields may be added at any time, so ignore fields you do not recognise rather than failing on them.
This is the whole loop: find work, read it, act on it, and confirm what you did.
# 1. Discover what this install offers and what each action needs.
POST /api/v1.php
{"action":"meta.actions"}
# 2. Find the urgent open tickets.
POST /api/v1.php
Authorization: Bearer opq_your_api_key
{"action":"tickets.list","status":"open","priority":"urgent","per_page":25}
# 3. Read one, including its conversation history.
{"action":"tickets.get","ticket_id":4192}
# 4. Reply, safely enough to retry if the network drops.
{"action":"tickets.reply","ticket_id":4192,
"body":"We have issued the refund.","idempotency_key":"reply-4192-attempt-1"}
# 5. Close it.
{"action":"tickets.update","ticket_id":4192,"status":"closed"}
# 6. Page through anything larger: keep going until has_more is false.
{"action":"tickets.list","page":2,"per_page":50}Each of these is a complete, runnable piece of a real integration rather than a fragment.
The rule is the same everywhere: keep asking for the next page until has_more is false. Never guess a total.
import requests
API = "https://your-opsiq-domain.com/api/v1.php"
HEAD = {"Authorization": "Bearer opq_your_api_key"}
def every(action, **params):
"""Yield every record for a list action, one page at a time."""
page = 1
while True:
r = requests.post(API, headers=HEAD,
json={"action": action, "page": page, "per_page": 200, **params},
timeout=30)
r.raise_for_status()
body = r.json()
if not body.get("success"):
raise RuntimeError(f"{body.get('code')}: {body.get('error')}")
yield from body.get("items", [])
if not body.get("has_more"):
return
page += 1
for ticket in every("tickets.list", status="open"):
print(ticket["ticket_number"], ticket["subject"])const API = "https://your-opsiq-domain.com/api/v1.php";
const HEAD = { Authorization: "Bearer opq_your_api_key", "Content-Type": "application/json" };
async function* every(action, params = {}) {
for (let page = 1; ; page++) {
const res = await fetch(API, {
method: "POST",
headers: HEAD,
body: JSON.stringify({ action, page, per_page: 200, ...params }),
});
const body = await res.json();
if (!body.success) throw new Error(`${body.code}: ${body.error}`);
yield* body.items ?? [];
if (!body.has_more) return;
}
}
for await (const contact of every("crm.contacts.list", { status: "lead" })) {
console.log(contact.email);
}<?php
$api = "https://your-opsiq-domain.com/api/v1.php";
function opsiq(string $action, array $params = []): array {
global $api;
$ch = curl_init($api);
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HTTPHEADER => [
"Authorization: Bearer opq_your_api_key",
"Content-Type: application/json",
],
CURLOPT_POSTFIELDS => json_encode(["action" => $action] + $params),
CURLOPT_TIMEOUT => 30,
]);
$body = json_decode((string)curl_exec($ch), true) ?: [];
curl_close($ch);
if (empty($body["success"])) {
throw new RuntimeException(($body["code"] ?? "error") . ": " . ($body["error"] ?? "unknown"));
}
return $body;
}
$page = 1;
do {
$res = opsiq("tickets.list", ["status" => "open", "page" => $page, "per_page" => 200]);
foreach ($res["items"] as $t) {
echo $t["ticket_number"], " ", $t["subject"], PHP_EOL;
}
$page++;
} while (!empty($res["has_more"]));Branch on code, never on the wording of error. This wrapper is the whole contract in one function.
import time, requests
RETRYABLE = {"server_error", "handler_unavailable"}
def call(action, **params):
for attempt in range(4):
r = requests.post(API, headers=HEAD, json={"action": action, **params}, timeout=30)
body = r.json()
if body.get("success"):
return body
code = body.get("code")
if code == "rate_limited":
# Honour Retry-After rather than guessing.
time.sleep(int(r.headers.get("Retry-After", 60)))
continue
if code in RETRYABLE:
time.sleep(2 ** attempt)
continue
# Everything below is permanent: retrying cannot fix it.
if code == "plan_feature_locked":
raise RuntimeError(f"Plan {body['plan_name']} lacks {body['feature']}: {body['upgrade_url']}")
if code in ("missing_scope", "read_only_key", "action_restricted"):
raise RuntimeError(f"This API key cannot do that: {body['error']}")
if code in ("invalid_api_key", "missing_api_key"):
raise RuntimeError("The key is wrong or expired; retrying will not help.")
raise RuntimeError(f"{code}: {body.get('error')} (request_id {body.get('request_id')})")
raise RuntimeError("Gave up after repeated retries")Read the low scores, open a ticket for each, and never act on the same one twice.
# 1. Yesterday's detractors.
POST /api/v1.php
{"action":"tickets.csat.list","filters":{"max_rating":2},"days":1,"per_page":100}
# 2. For each one, open a follow-up ticket. The idempotency key is derived
# from the response id, so re-running the job creates nothing twice.
POST /api/v1.php
{"action":"tickets.open",
"customer_email":"[email protected]",
"subject":"Following up on your feedback",
"body":"We saw your rating and want to put it right.",
"priority":"high",
"idempotency_key":"csat-followup-8821"}
# 3. The same shape works for chat: conversations.ratings.list with
# {"filters":{"max_stars":2},"days":1} returns the comment, what
# prompted the rating and which agent it is credited to.POST /api/v1.php
{"action":"commerce.quotes.create","source":"whmcs","item_id":"47","quantity":1}
# The merchant needs more from the customer before it can price this:
{
"success": false,
"code": "quote_refused",
"error": "We need the domain this hosting plan is for.",
"actionable": true,
"missing": ["domain"]
}
# Ask the customer for exactly what "missing" names, then quote again.
POST /api/v1.php
{"action":"commerce.quotes.create","source":"whmcs","item_id":"47",
"fields":{"domain":"example.ng"}}
{
"success": true,
"source": "whmcs",
"quote": {
"quote_id": "…",
"totals": { "total": { "amount_minor": 306027, "currency": "NGN" }, "currency": "NGN" },
"expires_at": "2026-09-05T12:34:56+00:00"
},
"ordering": { "creates_order": false, "confirm_via_api": false }
}totals.total exactly as returned. Quantity does not always multiply the unit price — a hotel quotes one room for three nights — so a figure you calculate yourself can differ from what the merchant will actually charge.Verify, de-duplicate, answer quickly, then do the work. Deliveries retry, so the same event can arrive more than once.
<?php
// (verification exactly as in the Webhooks section, omitted here for brevity)
$event = json_decode($raw, true);
$name = $_SERVER["HTTP_X_OPSIQ_EVENT"] ?? ($event["event"] ?? "");
$delivery = $_SERVER["HTTP_X_OPSIQ_DELIVERY"] ?? "";
// 1. Already seen this delivery? Say OK and stop — do not redo the work.
if ($db->alreadyProcessed($delivery)) {
http_response_code(200);
exit(json_encode(["ok" => true, "duplicate" => true]));
}
// 2. Answer FAST. Anything slow belongs on your own queue: OpsIQ treats a
// timeout as a failure and will retry the whole delivery.
$db->markProcessed($delivery);
$queue->push($name, $event);
http_response_code(200);
echo json_encode(["ok" => true]);
// 3. Your worker then routes on the event name.
// conversation.rated -> alert the team on a 1 or 2 star rating
// ticket.created -> mirror into your own helpdesk
// crm.deal.won -> post to #sales-alerts
// commerce.payment.confirmed-> release the order in your fulfilment systemEvery action belongs to a product feature, and your plan decides which features you have. If your plan does not include a feature, the action answers 402 — after your key is checked, so an unauthenticated caller learns nothing about your plan, and before anything is created, so a blocked write never half-happens.
{
"success": false,
"code": "plan_feature_locked",
"feature": "commerce",
"plan_locked": true,
"plan_name": "Growth",
"upgrade_url": "https://…",
"request_id": "req_8f2c1a9d4b7e"
}A 403 means the KEY is too narrow — reissue it with the right scope and it works. A 402 means the ACCOUNT does not have the feature — no key can unlock it, the plan has to change.
It is not transient. Surface the upgrade_url to whoever owns the account instead of backing off and trying again.
Scopes express what the key issuer delegated; the plan expresses what the account bought. An admin-scoped key still gets a 402 for a feature the plan lacks.
The feature each action needs is published in the action directory below and in meta.action, so you can check at build time rather than discovering it in production.
The quickest way to see exactly where a key stands is meta.me. It reports the plan in force, every feature it carries, and every action this key cannot call with the reason for each.
POST /api/v1.php
Authorization: Bearer opq_your_api_key
{"action":"meta.me"}
{
"success": true,
"key": { "name": "Reporting", "scopes": ["tickets.read"], "permissions_mode": "read_only" },
"plan": { "name": "Growth", "features": { "ticket_system": true, "commerce": false } },
"capabilities": {
"available_action_count": 812,
"blocked_actions": {
"commerce.orders.list": "plan_locked:commerce",
"tickets.reply": "read_only"
}
}
}commerce.quotes.create prices one item for one customer. It creates nothing — no order, no payment session, no held stock — so it is safe to call while a customer is still deciding.
POST /api/v1.php
Authorization: Bearer opq_your_api_key
# Your own Store
{"action":"commerce.quotes.create","source":"store","item_id":"12","quantity":2}
# A connected merchant platform, priced for a known customer
{"action":"commerce.quotes.create","source":"whmcs","item_id":"47",
"fields":{"domain":"example.ng"},
"customer":{"connector_customer_id":"1042"}}For a connected platform, the total comes from that merchant and is never recalculated here. Quantity does not always multiply the unit price — a hotel quotes one room for three nights — so show the total you were given, not one you worked out.
If the merchant needs more from the customer, you get quote_refused with a missing list naming the fields to collect, and the merchant's own wording to show.
A quote is indicative. Confirmation happens where the customer is — the signed card in chat, or the merchant's own checkout — never through this API. The response says so in ordering.
If the store has selling switched off, quoting answers selling_paused rather than pricing something nobody can buy.
Almost everything you need is one POST to /api/v1.php. These are the exceptions, and what each is for.
The machine contract and the human reference. No key needed, so you can explore before you have one.
Server-sent events for live chat replies as they are generated. A stream, not a JSON action.
The older AI-writing endpoint. Everything it does is also available as writing.* actions on /api/v1.php, which is where new work should go.
Draft, rewrite and triage for a ticket inbox embedded in your own admin.
Site Intelligence as a small REST API — sites, crawls, issues, keywords, revenue — for CI pipelines that want to start a crawl after a deploy and read the result.
Where a connected platform POSTs its own webhooks to you. The token is minted when you enable the connector.
The integration engine: run and confirm actions, and ingest sales, identity and journey events. It uses its own key type, issued under API & Webhook builder.
This list is generated from the running catalogue, so it always matches the version you are on. meta.actions returns the same information as JSON.
Write. Scope: administration.write, admin. Contract: route_inferred. Admin 2fa Disable
Write. Scope: administration.write, admin. Contract: route_inferred. Admin 2fa Enable
Write. Scope: administration.write, admin. Contract: route_inferred. Admin 2fa Recovery Regenerate
Read. Scope: administration.read, admin. Contract: declared_dynamic. Admin 2fa Setup
Read. Scope: administration.read, admin. Contract: declared_dynamic. Admin 2fa Status
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Ai Train From Reply
Write. Scope: administration.write, admin. Contract: declared_dynamic. Admin Brain Cancel
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Brain View
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Chat Access Check
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Chat Create Ticket On Behalf
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Chat Draft Ticket From Thread
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Conv Delete
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Conv Get
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Conv List
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Conv New
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Conv Save
Read. Scope: administration.read, admin. Contract: declared_dynamic. Admin Notification Prefs Get
Write. Scope: administration.write, admin. Contract: declared_dynamic. Admin Notification Prefs Save
Read. Scope: administration.read, admin. Contract: route_inferred. Admin Notifications List
Read. Scope: administration.read, admin. Contract: declared_dynamic. Admin Notifications Mark All Read
Read. Scope: administration.read, admin. Contract: route_inferred. Admin Notifications Mark Read
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Notifications Pulse
Read. Scope: administration.read, admin. Contract: declared_dynamic. Admin Online List
Write. Scope: administration.write, admin. Contract: declared_dynamic. Admin Presence Ping
Write. Scope: administration.write, admin. Contract: route_inferred. Admin Realtime Token
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Add Widget
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Analytics Connectors Catalog
Read. Scope: analytics.read, admin. Contract: route_inferred. Analytics Data
Read. Scope: analytics.read, admin. Contract: route_inferred. Analytics Export
Read. Scope: analytics.read, admin. Contract: route_inferred. Analytics Export Csv
Write. Scope: analytics.write, admin. Contract: route_inferred. Analytics Import
Write. Scope: analytics.write, admin. Contract: route_inferred. Analytics Report
Write. Scope: analytics.write, admin. Contract: route_inferred. Analytics Segments Delete
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Analytics Segments List
Write. Scope: analytics.write, admin. Contract: route_inferred. Analytics Segments Save
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Analytics Status
Write. Scope: analytics.write, admin. Contract: declared_dynamic. Replay Clear All
Read. Scope: analytics.read, admin. Contract: route_inferred. Funnels Compute
Write. Scope: analytics.write, admin. Contract: route_inferred. Ab Test Create
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Create
Write. Scope: analytics.write, admin. Contract: route_inferred. Report Create
Write. Scope: analytics.write, admin. Contract: route_inferred. Ab Test Delete
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Delete
Write. Scope: analytics.write, admin. Contract: route_inferred. Funnels Delete
Write. Scope: analytics.write, admin. Contract: route_inferred. Report Delete
Read. Scope: analytics.read, admin. Contract: route_inferred. Replay Events
Read. Scope: analytics.read, admin. Contract: source_inferred. Analytics Export
Read. Scope: analytics.read, admin. Contract: route_inferred. Dashboard Get
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Dashboard Layout Get
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Layout Save
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Ab Test List
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Dashboard List
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Funnels List
Read. Scope: analytics.read, admin. Contract: declared_dynamic. Report List
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Remove Widget
Read. Scope: analytics.read, admin. Contract: route_inferred. Dashboard Rename
Read. Scope: analytics.read, admin. Contract: route_inferred. Ab Test Results
Write. Scope: analytics.write, admin. Contract: route_inferred. Funnels Save
Read. Scope: analytics.read, admin. Contract: explicit. List scheduled analytics reports for an operator Required fields: admin_id.
Read. Scope: analytics.read, admin. Contract: explicit. List analytics report sections and date presets
Write. Scope: analytics.write, admin. Contract: route_inferred. Report Send Now
Read. Scope: analytics.read, admin. Contract: route_inferred. Replay Sessions
Read. Scope: analytics.read, admin. Contract: route_inferred. Funnels Step Visitors
Read. Scope: analytics.read, admin. Contract: route_inferred. Replay Timeline
Write. Scope: analytics.write, admin. Contract: route_inferred. Dashboard Toggle Shared
Write. Scope: analytics.write, admin. Contract: route_inferred. Ab Test Update
Write. Scope: analytics.write, admin. Contract: route_inferred. Report Update
Read. Scope: analytics.read, admin. Contract: route_inferred. Dashboard Widget Data
Read. Scope: automations.read, admin. Contract: explicit. List integration actions
Write. Scope: automations.write, admin. Contract: route_inferred. Workflow Delete
Read. Scope: automations.read, admin. Contract: route_inferred. Workflow List
Read. Scope: automations.read, admin. Contract: explicit. List automation execution history
Write. Scope: automations.write, admin. Contract: route_inferred. Workflow Save
Read. Scope: automations.read, admin. Contract: explicit. List integration triggers
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Call Start
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Cobrowse Send
Read. Scope: chat.read, admin. Contract: route_inferred. Chat Feedback
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Feedback Digest
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Form Delete
Read. Scope: chat.read, admin. Contract: route_inferred. Chat Form Get
Read. Scope: chat.read, admin. Contract: declared_dynamic. Chat Form List
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Form Save
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Form Set Default
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Meeting Type Delete
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Meeting Type Save
Read. Scope: chat.read, admin. Contract: route_inferred. Chat Meeting Types List
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Online Admins
Write. Scope: admin. Contract: route_inferred. Chat Permissions List
Write. Scope: admin. Contract: route_inferred. Chat Permissions Revoke
Write. Scope: admin. Contract: route_inferred. Chat Permissions Save
Write. Scope: admin. Contract: route_inferred. Chat Permissions Upload Avatar
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Reaction Toggle
Write. Scope: chat.write, admin. Contract: source_inferred. Chat Saved Replies Add Retry-safe with idempotency_key.
Read. Scope: chat.read, admin. Contract: explicit. List workspace and personal saved replies
Write. Scope: chat.write, admin. Contract: source_inferred. Chat Saved Replies Save Retry-safe with idempotency_key.
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Set Persona
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Snooze Clear
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Snooze Set
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Transfer Thread
Write. Scope: chat.write, admin. Contract: declared_dynamic. Chat Transfer Unread
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Typing Preview
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper Ai Summary
Write. Scope: chat.write, admin. Contract: declared_dynamic. Chat Whisper Controls
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper Delete Room
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper List
Write. Scope: chat.write, admin. Contract: declared_dynamic. Chat Whisper Mentions
Write. Scope: chat.write, admin. Contract: declared_dynamic. Chat Whisper Rooms
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper Save Controls
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper Send
Write. Scope: chat.write, admin. Contract: declared_dynamic. Chat Whisper Targets
Write. Scope: chat.write, admin. Contract: route_inferred. Chat Whisper Unread
Read. Scope: commerce.read, admin. Contract: explicit. Get one Store order with its line items
Read. Scope: commerce.read, admin. Contract: explicit. List Store orders in the bound workspace
Read. Scope: commerce.read, admin. Contract: explicit. Get one Store product with its variants Required fields: product_id.
Read. Scope: commerce.read, admin. Contract: explicit. List Store products in the bound workspace
Write. Scope: commerce.write, admin. Contract: explicit. Quote an item for a customer (creates nothing) Required fields: source, item_id. Retry-safe with idempotency_key.
Read. Scope: commerce.read, admin. Contract: explicit. List Store refund requests in the bound workspace
Read. Scope: admin. Contract: route_inferred. Email Auth Check
Write. Scope: communications.write, admin. Contract: route_inferred. Push Campaign Delete
Write. Scope: communications.write, admin. Contract: route_inferred. Push Campaign Save
Write. Scope: communications.write, admin. Contract: route_inferred. Push Campaign Send
Read. Scope: communications.read, admin. Contract: declared_dynamic. Push Campaigns List
Write. Scope: communications.write, admin. Contract: route_inferred. Email Drafts Delete
Read. Scope: communications.read, admin. Contract: declared_dynamic. Email Drafts List
Write. Scope: communications.write, admin. Contract: route_inferred. Email Drafts Save
Write. Scope: communications.write, admin. Contract: route_inferred. Email Drafts Send
Write. Scope: communications.write, admin. Contract: route_inferred. Email Mailboxes Delete
Read. Scope: communications.read, admin. Contract: route_inferred. Email Mailboxes List
Read. Scope: communications.read, admin. Contract: declared_dynamic. Email Mailboxes Poll
Write. Scope: communications.write, admin. Contract: route_inferred. Email Mailboxes Save
Read. Scope: communications.read, admin. Contract: declared_dynamic. Email Mailboxes Test
Write. Scope: communications.write, admin. Contract: declared_dynamic. Email Pipe Regen Token
Read. Scope: communications.read, admin. Contract: declared_dynamic. Email Platform List
Write. Scope: communications.write, admin. Contract: route_inferred. Email Platform Send
Read. Scope: communications.read, admin. Contract: declared_dynamic. Email Settings Get
Write. Scope: communications.write, admin. Contract: route_inferred. Email Settings Save
Read. Scope: communications.read, admin. Contract: route_inferred. Email Settings Test
Write. Scope: communications.write, admin. Contract: declared_dynamic. Push Vapid Generate
Read. Scope: connector_builder.read, admin. Contract: explicit. Export a generated connector Required fields: slug.
Write. Scope: connector_builder.write, admin. Contract: explicit. Generate a connector package Required fields: spec. Retry-safe with idempotency_key.
Read. Scope: connector_builder.read, admin. Contract: explicit. Load a Builder specification Required fields: slug.
Write. Scope: connector_builder.write, admin. Contract: explicit. Import cURL into Connector Builder Retry-safe with idempotency_key.
Write. Scope: connector_builder.write, admin. Contract: explicit. Import OpenAPI into Connector Builder Retry-safe with idempotency_key.
Write. Scope: connector_builder.write, admin. Contract: explicit. Import Postman into Connector Builder Retry-safe with idempotency_key.
Read. Scope: connector_builder.read, admin. Contract: explicit. List Builder connectors
Read. Scope: connector_builder.read, connectors.read, admin. Contract: source_inferred. List Connector Builder profiles and capability contracts
Write. Scope: connector_builder.write, admin. Contract: explicit. Run Builder conformance tests Required fields: slug. Retry-safe with idempotency_key.
Write. Scope: connector_builder.write, admin. Contract: explicit. Update a generated connector Required fields: slug, spec. Retry-safe with idempotency_key.
Read. Scope: connector_builder.read, admin. Contract: explicit. Validate a Builder specification Required fields: spec.
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Action
Write. Scope: connectors.write, admin. Contract: explicit. Start connector backfill Required fields: slug. Retry-safe with idempotency_key.
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Backfill
Read. Scope: connectors.read, admin. Contract: explicit. Read connector backfill status Required fields: slug.
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Backfill Status
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Ai Actions
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Ai Draft
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Ai Handler
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Ai Map
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Delete
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Dry Run
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Generate
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Import Curl
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Import Openapi
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Import Postman
Read. Scope: connectors.read, admin. Contract: declared_dynamic. Connectors Builder List
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Load
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Marketplace Apply
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Marketplace Link
Read. Scope: connectors.read, admin. Contract: declared_dynamic. Connectors Builder Marketplace Status
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Marketplace Submit
Read. Scope: connectors.read, admin. Contract: declared_dynamic. Connectors Builder Schema
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Test
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Test Action
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Builder Update
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Builder Validate
Write. Scope: connectors.write, admin. Contract: route_inferred. Connector Contacts Import
Read. Scope: connectors.read, connector_builder.read, admin. Contract: source_inferred. Read the canonical connector capability contract
Write. Scope: connectors.write, admin. Contract: explicit. Synchronize connector customers Required fields: slug. Retry-safe with idempotency_key.
Write. Scope: connectors.write, admin. Contract: explicit. Disable a connector Required fields: slug. Retry-safe with idempotency_key.
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Disable
Read. Scope: connectors.read, admin. Contract: route_inferred. Connector Email Account Department
Write. Scope: connectors.write, admin. Contract: route_inferred. Connector Email Account Remove
Read. Scope: connectors.read, admin. Contract: route_inferred. Connector Email Account Routing
Write. Scope: connectors.write, admin. Contract: explicit. Enable a connector Required fields: slug. Retry-safe with idempotency_key.
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Enable
Read. Scope: connectors.read, admin. Contract: source_inferred. Connectors Get
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Get
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Install
Read. Scope: connectors.read, admin. Contract: declared_dynamic. Connector Integrity Scan
Read. Scope: connectors.read, admin. Contract: explicit. List installed connectors and capabilities
Read. Scope: connectors.read, admin. Contract: declared_dynamic. Connectors List
Write. Scope: connectors.write, admin. Contract: route_inferred. Connector Oauth Start
Read. Scope: connectors.read, admin. Contract: explicit. Read connector settings Required fields: slug.
Write. Scope: connectors.write, admin. Contract: explicit. Save connector settings Required fields: slug, settings. Retry-safe with idempotency_key.
Write. Scope: connectors.write, admin. Contract: route_inferred. Connector Shared Oauth Delete
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Sync Customers
Read. Scope: connectors.read, admin. Contract: source_inferred. Connectors Test
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Test
Write. Scope: connectors.write, admin. Contract: route_inferred. Connectors Uninstall
Read. Scope: connectors.read, admin. Contract: route_inferred. Connectors Workflow Recipes
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Ai Draft
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Ai Rewrite
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Archive
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Assign
Write. Scope: conversations.write, admin. Contract: declared_dynamic. Admin Client Chat Assignees
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Bulk
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Clear
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Clear All
Write. Scope: conversations.write, admin. Contract: declared_dynamic. Admin Client Chat Customer Tickets
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Decline
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Delete
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Delete Last
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Edit Last
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Export
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Forget Visitor
Read. Scope: conversations.read, admin. Contract: source_inferred. Conversations Get
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat History
Read. Scope: conversations.read, admin. Contract: source_inferred. Conversations List
Read. Scope: conversations.read, admin. Contract: source_inferred. Conversations Messages
Read. Scope: conversations.read, admin. Contract: explicit. List rated Client Chat conversations
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Resolve
Write. Scope: conversations.write, admin. Contract: declared_dynamic. Admin Client Chat Saved Replies
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Saved Reply Add
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Saved Reply Ai Generate
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Saved Reply Delete
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Saved Reply Save
Write. Scope: conversations.write, admin. Contract: source_inferred. Conversations Send Retry-safe with idempotency_key.
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Send
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Tags Set
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Thread
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Threads
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Toggle
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Toggle Attachments
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Toggle Call Button
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Typing
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Unarchive
Write. Scope: conversations.write, admin. Contract: explicit. Update a conversation status, assignment or subject Retry-safe with idempotency_key.
Write. Scope: conversations.write, admin. Contract: route_inferred. Admin Client Chat Upload
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Ab Results
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Access Set
Read. Scope: admin. Contract: source_inferred. Crm Access Log List
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Account Health
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Account Health Board
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Account Health Refresh
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Account Plan Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Account Plan Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Account Plans Due
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Account Timeline
Read. Scope: crm.read. Contract: explicit. List CRM contact activities
Write. Scope: crm.write. Contract: explicit. Record a CRM contact activity Required fields: contact_id, activity_type. Retry-safe with idempotency_key.
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Activity Feed
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Agent Toggle
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Ai Policy Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Ai Policy Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Ai Policy Simulate
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Ai Trace
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Approval Decide
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Approval Delegate Set
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Approval List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Approval Policy Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Approval Policy Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Approval Settings
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Approve Apply
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Approve List
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Approve Reject
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Approve Update
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Ask
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Assign Owner
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Assignment Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Assignment Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Attachment Delete
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Attachment List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Attachment Upload
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Autobook Meeting
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Autodeal Mode
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Book Meeting
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Booking Link Save
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Booking Links List
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Build Apply
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Build Get
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Build List
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Build Plan
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Build Rollback
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Bulk
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Bundle Set
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Calendar Status
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Capture Status
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Comm Policy Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Comm Policy Save
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Command Snapshot
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Companies List
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Company Hierarchy
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Company Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Company Set Parent
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Company Suggest Related
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Connectors Catalog
Read. Scope: crm.read. Contract: source_inferred. Crm Consent Log List
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Contact Churn
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contact Draft Email
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contact Enrich
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contact Propose Email
Read. Scope: crm.read. Contract: source_inferred. Crm Contacts Detail
Write. Scope: admin. Contract: source_inferred. Crm Contacts Erase Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Contacts Export
Read. Scope: crm.read. Contract: source_inferred. Crm Contacts Import List
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Import Run Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Contacts List
Read. Scope: crm.read. Contract: source_inferred. Crm Contacts Next Action
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Open Chat Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Open Ticket Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Resync Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Save Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Contacts Send Email Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: explicit. Crm Contacts Upsert Required fields: email. Retry-safe with idempotency_key.
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contract Amend
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contract Price Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contract Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contract Usage
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Contracts List
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Conversation Intel
Write. Scope: crm.write. Contract: source_inferred. Crm Conversions Goals Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Conversions Goals List
Write. Scope: crm.write. Contract: source_inferred. Crm Conversions Goals Save Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Conversions List
Write. Scope: crm.write. Contract: source_inferred. Crm Conversions Record Retry-safe with idempotency_key.
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Create Video Meeting
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Customer Auto Sync
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Customer Auto Sync Status
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Customer Emails
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Customer Payments
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Data Steward Bulk Propose
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Data Steward Inbox
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Data Steward Propose
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Deal Advance
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Deal Coach
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Deal Coach Action
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Deal Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Deal Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Deal Splits Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Deal Splits Set
Write. Scope: crm.write. Contract: explicit. Advance a CRM deal to another stage Required fields: deal_id, stage_id. Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: explicit. Create a CRM deal Required fields: title. Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: explicit. Get one CRM deal Required fields: deal_id.
Read. Scope: crm.read. Contract: explicit. List CRM deals
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Deals List
Write. Scope: crm.write. Contract: explicit. Update a CRM deal Required fields: deal_id. Retry-safe with idempotency_key.
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Detail
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Draft Outreach
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Enrich Account
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Erase
Read. Scope: crm.read. Contract: explicit. List subscribable CRM domain events
Read. Scope: crm.read. Contract: explicit. List durable CRM domain events
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Export
Read. Scope: crm.read, admin. Contract: route_inferred. Contact Export All
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Field Add
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Field Policy Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Field Policy Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Field Remove
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Fields List
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Forecast Board
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Forecast Snapshot
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Form Save
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Forms List
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Health Repair Catalog
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Health Smoke
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Health Snapshot
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Home Persona Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Identity Rules Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Identity Rules Save
Read. Scope: crm.read, admin. Contract: route_inferred. Contact Import List
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Import Run
Read. Scope: crm.read. Contract: source_inferred. Crm Inbound Activity
Write. Scope: crm.write. Contract: source_inferred. Crm Inbound Endpoints Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Inbound Endpoints List
Write. Scope: crm.write. Contract: source_inferred. Crm Inbound Endpoints Save Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Inbound Endpoints Test Retry-safe with idempotency_key.
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Leaderboard
Write. Scope: crm.write. Contract: source_inferred. Crm Lifecycle Evaluate Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Lifecycle Rules Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Lifecycle Rules List
Write. Scope: crm.write. Contract: source_inferred. Crm Lifecycle Rules Save Retry-safe with idempotency_key.
Read. Scope: crm.read, admin. Contract: route_inferred. Contacts List
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Mailbox Status
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Meeting Book
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Meeting Cancel
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Meeting List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Meeting Reschedule Accept
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Meeting Reschedule Reject
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Merge
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Message Send
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Messaging Provider Delete
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Messaging Provider Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Messaging Provider Test
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Messaging Status
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Next Action
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Object Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Objects List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Offline Pull
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Offline Push
Read. Scope: crm.read, admin. Contract: route_inferred. Contact Open Chat
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Open Ticket
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Campaigns Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Outreach Campaigns List
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Campaigns Save Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Campaigns Send Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Send Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Templates Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Outreach Templates List
Read. Scope: crm.read. Contract: source_inferred. Crm Outreach Templates Preview
Write. Scope: crm.write. Contract: source_inferred. Crm Outreach Templates Save Retry-safe with idempotency_key.
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Payments Status
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Pipeline Data
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Price Resolve
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Pricebook Entry Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Pricebook Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Pricebooks List
Read. Scope: crm.read. Contract: source_inferred. Crm Privacy Settings Get
Write. Scope: admin. Contract: source_inferred. Crm Privacy Settings Save Retry-safe with idempotency_key.
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Product Archive
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Product Revenue
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Product Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Products List
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Propose Meeting
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Propose Outreach
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Prospecting Dashboard
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Prospecting Icp Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Prospecting Import
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Prospecting Research
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Prospecting Score
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Prospecting Sequence
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Qualification Checklist Get
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Qualification Checklist Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Quota Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Quote Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Quote Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Quotes List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Delete
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Record Fields Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Fields Save
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Record Get
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Record History
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Share Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Share Unset
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Record Shares
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Records List
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Restore Email Consent
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Resync From Platform
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Retention Catalog
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Revert
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Runtime Policy Get
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Runtime Policy Remote Wipe
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Runtime Policy Save
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Scoring Rule Ai
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Scoring Rule Delete
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Scoring Rule List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Scoring Rule Save
Write. Scope: crm.write. Contract: source_inferred. Crm Segments Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Segments List
Read. Scope: crm.read. Contract: source_inferred. Crm Segments Members
Read. Scope: crm.read. Contract: source_inferred. Crm Segments Preview
Write. Scope: crm.write. Contract: source_inferred. Crm Segments Save Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Segments Suggestions Accept Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Segments Suggestions Dismiss Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Segments Suggestions List
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Semantic Search
Write. Scope: crm.write, admin. Contract: route_inferred. Contact Send Email
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Send Email
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Send For Signature
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Send Payment Link
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Sequence Action
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Sequence Runs
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Setup Status
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Sharing Rules Get
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Sharing Rules Save
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Subject Registry
Read. Scope: crm.read, admin. Contract: route_inferred. Crm Subscriptions List
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Subscriptions Rollup
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Subscriptions Sync
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Task Create
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Tasks List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Team Parent Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Team Rules Set
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Team Save
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Teams List
Write. Scope: crm.write, admin. Contract: route_inferred. Crm Territory Set
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Video Status
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Views Delete
Read. Scope: crm.read, admin. Contract: declared_dynamic. Crm Views List
Write. Scope: crm.write, admin. Contract: declared_dynamic. Crm Views Save
Write. Scope: crm.write. Contract: source_inferred. Crm Webhooks Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: explicit. List CRM outbound webhook endpoints and recent deliveries
Write. Scope: crm.write. Contract: source_inferred. Crm Webhooks Save Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Webhooks Test Retry-safe with idempotency_key.
Write. Scope: crm.write. Contract: source_inferred. Crm Workflows Delete Retry-safe with idempotency_key.
Read. Scope: crm.read. Contract: source_inferred. Crm Workflows List
Write. Scope: crm.write. Contract: source_inferred. Crm Workflows Save Retry-safe with idempotency_key.
Write. Scope: customers.write, journey.write, admin. Contract: explicit. Analyze a customer journey with AI Required fields: client_id. Retry-safe with idempotency_key.
Read. Scope: admin. Contract: route_inferred. Cdp Behaviour
Write. Scope: admin. Contract: route_inferred. Cdp Behaviour Analyze
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Embed Backfill
Read. Scope: customers.read, admin. Contract: declared_dynamic. Client Chat Embed Status
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Ai Generate
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Approve All
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Delete
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Faq Delete All
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Faq Export
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Generate
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Import
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq List
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Save
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Set Help
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Set Help All
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Faq Status
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Grant Upload
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Help Set Slug
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Crawl Step
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Delete
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Knowledge Delete All
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Knowledge Delete Duplicates
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Knowledge Duplicates
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Knowledge Export Json
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Import Json
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Preview
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Recrawl
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Knowledge Test Url
Write. Scope: customers.write, admin. Contract: route_inferred. Client Chat Revoke Upload
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Upload Agent Avatar
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Upload Ai Avatar
Write. Scope: customers.write, admin. Contract: declared_dynamic. Client Chat Upload Icon
Write. Scope: admin. Contract: route_inferred. Cdp Client Analyze
Write. Scope: admin. Contract: route_inferred. Cdp Client Delete
Write. Scope: admin. Contract: route_inferred. Cdp Client Export
Read. Scope: admin. Contract: route_inferred. Cdp Client Journey
Write. Scope: customers.write, admin. Contract: route_inferred. Cdp Client Prepare Outreach
Read. Scope: admin. Contract: route_inferred. Cdp Clients List
Read. Scope: customers.read, admin. Contract: route_inferred. Client Detail
Read. Scope: customers.read, crm.read, admin. Contract: explicit. Get a customer profile Required fields: client_id.
Read. Scope: customers.read, journey.read, admin. Contract: explicit. Get a complete customer journey Required fields: client_id.
Read. Scope: customers.read, crm.read, admin. Contract: explicit. List known customers
Write. Scope: customers.write, crm.write, admin. Contract: explicit. Prepare CRM outreach for a customer Required fields: client_id. Retry-safe with idempotency_key.
Read. Scope: departments.read, admin. Contract: source_inferred. Departments List
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ab Autowinner
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ab Bandit
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Survey Address Get
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Address Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Agent
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Analyze
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Compile Profile
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Copy
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Ai Critique
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Decide
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Design
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Edit
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Generate
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Ai Ideas
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Image
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Image Edit
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Localize
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Logo
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Ai Media Jobs
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Ai Narrative
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Ai Responsive
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Ai Variants
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Video Start
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Ai Video Status
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Approval Decide
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Approval Request
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Approvals List
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Asset Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Asset Upload
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Assets List
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Audience Materialize
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Audience Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Audience Test
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Audit Export
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Autoresponder Get
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Autoresponder Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Bank Delete
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Survey Bank List
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Bank Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Bank Used
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Blackouts Get
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Blackouts Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Brand Kit Bootstrap
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Brand Kit Font Upload
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Brand Kit Get
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Survey Brand Kit Get
Write. Scope: engagement.write, admin. Contract: declared_dynamic. Promo Brand Kit Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Brand Kit Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Archive
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Delete
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign Duplicate
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign Get
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Campaign Launch
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign List
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign Pause
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign Preview
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Publish
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Rollback
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Campaign Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Campaign Toggle
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Campaign Versions
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Comment Add
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Comments Add
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Comments Delete
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Comments List
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Comments List
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Comments Resolve
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Connectors Catalog
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Coupon Providers
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Coupons Clear
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Coupons Stats
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Coupons Upload
Write. Scope: engagement.write, admin. Contract: route_inferred. Announcement Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Tour Delete
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Delivery Analytics
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Delivery Dashboard
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Deployment Ab Promote
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Deployment Ab Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Deployment Publish
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Deployment Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Deployment Status
Read. Scope: engagement.read, admin. Contract: route_inferred. Campaign Detail
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Digest Save
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Feed Catalog
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Feed Items
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Geo Preview
Write. Scope: engagement.write, admin. Contract: route_inferred. Proactive Idle Cron Set
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Import Create
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Import Replay
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Leads Export
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Leads List
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Announcements List
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Tours List
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Module Set Ai Live
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Module Set Custom Html
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Module Set Enabled
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Module Status
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Onsite Preview
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Promo Pause All
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Presence
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Preview Share
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Push Draft
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Recipients Issue
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Recipients List
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Recipients Revoke
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Response Detail
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Responses Browse
Write. Scope: engagement.write, admin. Contract: route_inferred. Proactive Rule Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Proactive Rule Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Proactive Rule Stats
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Rule Test
Write. Scope: engagement.write, admin. Contract: route_inferred. Proactive Rule Toggle
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Proactive Rules List
Write. Scope: engagement.write, admin. Contract: route_inferred. Announcement Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Tour Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Stats
Read. Scope: engagement.read, admin. Contract: route_inferred. Tour Stats
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio A11y
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Ai Generate
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Ai Insights
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Ai Target
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Archive
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Survey Studio Assets
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Create
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Duplicate
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Studio Event
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Studio Get
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Governance
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Survey Studio List
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Studio Preview
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Studio Preview Link
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Publish
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Rename
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Revert
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Save Draft
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Save Targeting
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Set Active
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Set Status
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Template Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Template Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Tpl Preview
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Upload
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Studio Webhook
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Targeting Simulate
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Template Apply
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Template List
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Template Save Custom
Write. Scope: engagement.write, admin. Contract: route_inferred. Announcement Toggle
Write. Scope: engagement.write, admin. Contract: route_inferred. Tour Toggle
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Trigger Set Save
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Variant Delete
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Variant List
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Variant Promote
Write. Scope: engagement.write, admin. Contract: route_inferred. Promo Variant Save
Read. Scope: engagement.read, admin. Contract: route_inferred. Survey Version Compare
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Version Get
Read. Scope: engagement.read, admin. Contract: route_inferred. Promo Version Label
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Webhook Delete
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Webhook Replay
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Webhook Run
Write. Scope: engagement.write, admin. Contract: route_inferred. Survey Webhook Save
Read. Scope: engagement.read, admin. Contract: declared_dynamic. Tour Widget Data
Read. Scope: feedback.read, admin. Contract: source_inferred. Feedback Analytics
Read. Scope: feedback.read, admin. Contract: source_inferred. Feedback Detractors
Read. Scope: feedback.read, admin. Contract: source_inferred. Feedback Get
Write. Scope: feedback.write, admin. Contract: explicit. Ingest a feedback record or external review
Read. Scope: feedback.read, admin. Contract: source_inferred. Feedback List
Read. Scope: feedback.read, admin. Contract: source_inferred. Feedback Overview
Read. Scope: feedback.read, admin. Contract: explicit. List Voice of Customer feedback sources
Write. Scope: feedback.write, admin. Contract: source_inferred. Feedback Update Retry-safe with idempotency_key.
Read. Scope: files.read, admin. Contract: source_inferred. Files Get
Write. Scope: hr.write, admin. Contract: explicit. Close an agent incident — the same act that lifts the suspension it caused Required fields: incident_uuid, resolution. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Run one agent step: gate verdict, execution and outcome reported separately Required fields: run_uuid, agent_key, tool_key, jurisdiction, purpose. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. What actually happened at a step (permitted, executed, proven, failed, compensated) Required fields: run_uuid, seq.
Write. Scope: hr.write, admin. Contract: explicit. A human takes an agent run; no further agent steps are accepted Required fields: run_uuid. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Grant an agent a tool for one jurisdiction and purpose, up to a risk ceiling Required fields: agent_key, tool_key, jurisdiction, max_risk, purpose. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. List the registered typed tools an agent may use, and open agent incidents
Write. Scope: hr.write, admin. Contract: explicit. Bundle recent reviewer corrections into a dataset; it is pending privacy review and trains nothing Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. The AI quality board: sampled defect rate, override pressure per workflow, coaching reception
Write. Scope: hr.write, admin. Contract: explicit. Release booking slots whose claim never became a booked meeting Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Certify an HR connector (scope sandbox|production; production demands provider-side proof under dual control) Required fields: connector_class, connector_key, scope, evidence, submitted_by. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. One connector account's health: certification level and scope, last reconciliation verdict, failures and webhook backlog Required fields: account_uuid.
Write. Scope: hr.write, admin. Contract: explicit. File an appeal against an AI decision on a person's behalf; it must be heard by an independent human Required fields: decision_uuid, subject_type, subject_id, grounds. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Plain-language explanation of one AI decision: what was looked at, which policy, and how to appeal Required fields: decision_uuid, audience.
Write. Scope: hr.write, admin. Contract: explicit. Provision seatless employee access and send the invitation Required fields: person_uuid. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Lift an employee access suspension (written reason required) and provision again Required fields: person_uuid, reason. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Measured persona experience metrics (self-service rate, decision cycle, coaching usefulness, quality) from live journeys
Read. Scope: hr.read, admin. Contract: explicit. The whole launch picture: 15-gate leadership score, release readiness checks and jurisdiction coverage
Read. Scope: hr.read, admin. Contract: explicit. List a person's identity facets and open conflicts Required fields: person_uuid.
Write. Scope: hr.write, admin. Contract: explicit. Link an identity facet to a person Required fields: person_uuid, facet_type, facet_key. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Connect the AI to interview media; refuses unless media really reaches the worker Required fields: media_uuid. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Record or withdraw consent for ONE interview purpose (recording, biometric_liveness, transcription) Required fields: media_uuid, purpose, state. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Pause a live interview Required fields: media_uuid. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Provision an interview room (a place to meet — NOT AI participation) Required fields: session_uuid, transport, accommodation_route. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Read an interview room, including whether the AI is actually participating Required fields: media_uuid.
Write. Scope: hr.write, admin. Contract: explicit. A human takes the interview; the AI cannot speak in it again Required fields: media_uuid, reason. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. What this product may do in one country, per feature, with the law behind each answer Required fields: code.
Write. Scope: hr.write, admin. Contract: explicit. Report a change in the law; a high or critical one suspends every lane in that jurisdiction at once Required fields: pack_key, summary, severity. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Computed coverage for every market: released pack, named counsel owner, cited sources, passing tests
Read. Scope: hr.read, admin. Contract: explicit. Why an action about one person is allowed, reduced or blocked, with the rule and citation Required fields: person_uuid, feature.
Write. Scope: hr.write, admin. Contract: explicit. Put a drafted policy pack into effect; refused without a named counsel owner and a cited law Required fields: release_uuid. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Read courses, paths and enrolments
Read. Scope: hr.read, admin. Contract: explicit. Read leave types and requests
Read. Scope: hr.read, admin. Contract: explicit. Every lifecycle lane with its mode, KPIs and whether a live tool path really exists behind it
Read. Scope: hr.read, admin. Contract: explicit. Read HR connector accounts, conflicts and deliveries
Read. Scope: hr.read, admin. Contract: explicit. Read the organisation tree
Write. Scope: hr.write, admin. Contract: explicit. Create an HR person Required fields: display_name, primary_email, worker_type. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. Get one HR person Required fields: person_uuid.
Read. Scope: hr.read, admin. Contract: explicit. List HR people
Write. Scope: hr.write, admin. Contract: explicit. Update an HR person Required fields: person_uuid, display_name, primary_email. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. List job postings
Read. Scope: hr.read, admin. Contract: explicit. Run the HR release readiness report
Write. Scope: hr.write, admin. Contract: explicit. Run the four HR release gates (schema, manifest, probe, readiness) Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Create a requisition Required fields: title, openings, justification. Retry-safe with idempotency_key.
Read. Scope: hr.read, admin. Contract: explicit. List requisitions
Write. Scope: hr.write, admin. Contract: explicit. Delete a workforce conversation; refused while it is under legal hold Required fields: thread_uuid, reason. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Place or lift a legal hold on a workforce conversation Required fields: thread_uuid, on, reason. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Set a conversation's retention class (standard|extended|permanent) Required fields: thread_uuid, retention_class. Retry-safe with idempotency_key.
Write. Scope: hr.write, admin. Contract: explicit. Run the conversation retention sweep; legal holds are never swept Retry-safe with idempotency_key.
Write. Scope: intent.write, admin. Contract: declared_dynamic. Intent Clear
Read. Scope: intent.read, analytics.read, admin. Contract: explicit. Read the intent funnel
Read. Scope: intent.read, admin. Contract: route_inferred. Intent Funnel Aggregate
Read. Scope: intent.read, admin. Contract: route_inferred. Intent Funnel
Read. Scope: intent.read, analytics.read, admin. Contract: explicit. Read intent summaries
Read. Scope: intent.read, admin. Contract: route_inferred. Intent Summary
Write. Scope: kb.write, admin. Contract: source_inferred. Kb Faq Delete Retry-safe with idempotency_key.
Write. Scope: kb.write, admin. Contract: source_inferred. Kb Faq Generate Retry-safe with idempotency_key.
Write. Scope: kb.write, admin. Contract: source_inferred. Kb Faq Import Retry-safe with idempotency_key.
Read. Scope: kb.read, read, admin. Contract: source_inferred. Kb Faq List
Write. Scope: kb.write, admin. Contract: source_inferred. Kb Faq Save Retry-safe with idempotency_key.
Write. Scope: kb.write, admin. Contract: source_inferred. Kb Faq Set Status Retry-safe with idempotency_key.
Read. Scope: kb.read, admin. Contract: route_inferred. Help Analytics Get
Write. Scope: kb.write, admin. Contract: route_inferred. Help Analytics Toggle
Read. Scope: kb.read, admin. Contract: route_inferred. Help Article Ai Refine
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Class Bulk
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Delete
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Publish
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Save
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Set Category
Write. Scope: kb.write, admin. Contract: route_inferred. Help Article Set Public
Write. Scope: kb.write, admin. Contract: route_inferred. Help Articles Ai Generate
Write. Scope: kb.write, admin. Contract: route_inferred. Help Articles Bulk Delete
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Articles Count
Read. Scope: kb.read, admin. Contract: explicit. Get one Help Center article Required fields: article_id.
Read. Scope: kb.read, admin. Contract: route_inferred. Help Articles Ids
Read. Scope: kb.read, admin. Contract: route_inferred. Help Articles List
Write. Scope: kb.write, admin. Contract: route_inferred. Help Articles Set Public All
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Categories Ai Merge
Write. Scope: kb.write, admin. Contract: route_inferred. Help Categories Bulk Delete
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Categories List
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Categories Merge Dupes
Write. Scope: kb.write, admin. Contract: route_inferred. Help Category Delete
Read. Scope: kb.read, admin. Contract: route_inferred. Help Category Get
Write. Scope: kb.write, admin. Contract: route_inferred. Help Category Save
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Article Image Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Favicon Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Hero Dark Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Hero Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Logo Dark Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Logo Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Og Image Upload
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Center Settings Get
Write. Scope: kb.write, admin. Contract: route_inferred. Help Center Settings Save
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Subhero Dark Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Subhero Upload
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Translate Estimate
Write. Scope: kb.write, admin. Contract: route_inferred. Help Center Translate Run
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Center Translate Status
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Translate Stop
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Center Widget Icon Upload
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Comments Deliver Notifications
Write. Scope: kb.write, admin. Contract: route_inferred. Help Comments Maintenance
Write. Scope: kb.write, admin. Contract: route_inferred. Help Comments Moderate
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Comments Moderate
Read. Scope: kb.read, admin. Contract: route_inferred. Help Comments Moderation List
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Comments Moderation List
Write. Scope: kb.write, admin. Contract: route_inferred. Help Comments Notification Run
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Import Batches
Write. Scope: kb.write, admin. Contract: declared_dynamic. Kb Import Connectors
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Import Csv Preview
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Import Preview
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Import Resync
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Import Run
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Import Undo
Write. Scope: kb.write, admin. Contract: route_inferred. Help Insights Generate
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Insights Get
Write. Scope: kb.write, admin. Contract: declared_dynamic. Kb Mark Reviewed
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Missed Dismiss
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Missed Draft Article
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Missed List
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Missed Mark Published
Write. Scope: kb.write, admin. Contract: declared_dynamic. Kb Missed Refresh
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Organize Descriptions
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Organize Status
Write. Scope: kb.write, admin. Contract: route_inferred. Help Organize Step
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Publish
Write. Scope: kb.write, admin. Contract: declared_dynamic. Help Reformat Revert
Read. Scope: kb.read, admin. Contract: declared_dynamic. Help Reformat Status
Write. Scope: kb.write, admin. Contract: route_inferred. Help Reformat Step
Read. Scope: kb.read, admin. Contract: declared_dynamic. Kb Review Queue
Read. Scope: kb.read, admin. Contract: declared_dynamic. Kb Search Gaps
Write. Scope: kb.write, admin. Contract: route_inferred. Help Set Featured
Write. Scope: kb.write, admin. Contract: declared_dynamic. Kb Set Visibility
Write. Scope: kb.write, admin. Contract: route_inferred. Help Subdomain Allocate
Read. Scope: kb.read, admin. Contract: route_inferred. Help Subdomain Check
Write. Scope: kb.write, admin. Contract: route_inferred. Help Subdomain Release
Write. Scope: kb.write, admin. Contract: declared_dynamic. Kb Taxonomy Organize
Read. Scope: kb.read, admin. Contract: declared_dynamic. Kb Taxonomy Status
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Taxonomy Step
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Widget Categories
Write. Scope: kb.write, admin. Contract: route_inferred. Kb Widget Publish
Read. Scope: kb.read, admin. Contract: route_inferred. Kb Widget Targets
Write. Scope: leads.write, crm.write, admin. Contract: explicit. Delete a lead Required fields: lead_id. Retry-safe with idempotency_key.
Write. Scope: leads.write, admin. Contract: route_inferred. Lead Delete
Read. Scope: leads.read, crm.read, admin. Contract: explicit. List leads
Read. Scope: leads.read, analytics.read, admin. Contract: explicit. Get lead statistics
Read. Scope: leads.read, admin. Contract: declared_dynamic. Leads Stats
Write. Scope: leads.write, crm.write, admin. Contract: explicit. Update a lead Required fields: lead_id, status. Retry-safe with idempotency_key.
Read. Scope: none. Contract: explicit. Get one General API action contract Required fields: name.
Read. Scope: none. Contract: explicit. List the complete General API contract
Read. Scope: none. Contract: explicit. Describe the authenticated API key and active workspace
Read. Scope: none. Contract: explicit. List API scopes and the actions protected by each scope
Read. Scope: notifications.read, admin. Contract: source_inferred. Notifications List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Add Announcement
Write. Scope: platform.write, admin. Contract: route_inferred. Add Kb Article
Write. Scope: platform.write, admin. Contract: route_inferred. Add Todo Item
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Action Lookup
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Anomaly Detect
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain Add
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain Edit
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain List
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain Pin
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Brain Status
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Chat
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Confidence Stats
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Context Lookup
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Daily Brief
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Daily Brief Check
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Daily Brief Dismiss
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Daily Brief Fetch
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Eval Control Summary
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Eval Feedback Queue
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Eval Kb Gap Queue
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Eval Load
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Eval Replay History
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Eval Run
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Eval Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Eval Score Answer
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Eval Simulate
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Feedback Analysis
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Feedback Stats
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Archive
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Clear All
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Delete
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Export Csv
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Get
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai History Stats
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Insight Clear
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Insight History
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Insight Report Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Insight Report Get
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Instructions Compress
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Instructions Connector Templates
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Instructions Example
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Instructions Load
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Instructions Preview
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Instructions Reset
Write. Scope: platform.write, admin. Contract: declared_dynamic. Ai Instructions Save
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Page Insights
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Popup Regen
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Quality View
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Reasoning Chain Get
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Score Lead
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Smart Alerts
Read. Scope: platform.read, admin. Contract: route_inferred. Ai Spoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Ai Triage Accuracy
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Whmcs Chat
Write. Scope: platform.write, admin. Contract: route_inferred. Ai Writing
Read. Scope: admin. Contract: declared_dynamic. Api Keys Catalog
Write. Scope: admin. Contract: route_inferred. Api Keys Create
Write. Scope: admin. Contract: route_inferred. Api Keys Delete
Read. Scope: admin. Contract: declared_dynamic. Api Keys List
Write. Scope: admin. Contract: route_inferred. Api Keys Revoke
Write. Scope: admin. Contract: route_inferred. Api Keys Update
Read. Scope: admin. Contract: route_inferred. Audit Export
Write. Scope: platform.write, admin. Contract: route_inferred. Blocked
Read. Scope: platform.read, admin. Contract: declared_dynamic. Campaigns
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Browsers
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Countries
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Devices
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Hourly
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart New Returning
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Os
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chart Sources
Read. Scope: platform.read, admin. Contract: route_inferred. Chart Visitors
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Flow Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Chatbot Flow Get
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Flow Save
Read. Scope: platform.read, admin. Contract: route_inferred. Chatbot Flow Stats
Read. Scope: platform.read, admin. Contract: route_inferred. Chatbot Flow Test Advance
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Flow Test Start
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Flow Toggle
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chatbot Flows List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Chatbot Flows Widget Data
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Node Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Chatbot Node Save
Read. Scope: platform.read, admin. Contract: route_inferred. Chatbot Nodes List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Clear Admin Chat History
Read. Scope: platform.read, admin. Contract: declared_dynamic. Command Center View
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Actf Execute
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Actf Policy Save
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Actf Review
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Actf Simulate
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Analytics Report
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Analytics Report Email
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Autonomy Issue
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Autonomy Status
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Digital Codes Import
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Digital Config Save
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Digital File Upload
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Fulfilment Transition
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Intelligence Economics Save
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Intelligence Market Price Save
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Intelligence Market Save
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Merchandising Save
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Orders List
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Orders Transition
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Products Delete
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Products Image Upload
Read. Scope: commerce.read, admin. Contract: declared_dynamic. Commerce Products List
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Products Save
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Refunds Complete Manual
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Refunds Request
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Returns Transition
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Storefront Domain Remove
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Storefront Domain Set
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Storefront Logo Upload
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Storefront Slug Save
Write. Scope: commerce.write, admin. Contract: route_inferred. Commerce Variants Delete
Write. Scope: commerce.write, admin. Contract: declared_dynamic. Commerce Variants Save
Write. Scope: platform.write, admin. Contract: route_inferred. Complete Todo Item
Read. Scope: platform.read, admin. Contract: route_inferred. Consent Log List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Countries
Read. Scope: platform.read, admin. Contract: route_inferred. Country Detail
Write. Scope: platform.write, admin. Contract: route_inferred. Custom Code Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Custom Code Disable
Write. Scope: platform.write, admin. Contract: route_inferred. Custom Code Reject
Write. Scope: platform.write, admin. Contract: route_inferred. Custom Code Rollback
Read. Scope: platform.read, admin. Contract: route_inferred. Custom Code Status
Write. Scope: platform.write, admin. Contract: route_inferred. Delete Todo Item
Read. Scope: platform.read, admin. Contract: declared_dynamic. Devices
Read. Scope: platform.read, admin. Contract: declared_dynamic. Diag Check Resolutions
Write. Scope: platform.write, admin. Contract: route_inferred. Diag Dismiss
Read. Scope: platform.read, admin. Contract: route_inferred. Diag Recheck
Read. Scope: platform.read, admin. Contract: declared_dynamic. Diag Recheck All
Write. Scope: platform.write, admin. Contract: route_inferred. Diag Report
Read. Scope: platform.read, admin. Contract: route_inferred. Diag Unmute
Write. Scope: admin. Contract: route_inferred. Dismiss Credit Alert
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Knowledge Ai Generate
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Knowledge Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Knowledge List
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Knowledge Save
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Knowledge Toggle
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Verify Add
Read. Scope: platform.read, admin. Contract: declared_dynamic. Domain Verify List
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Verify Recheck
Write. Scope: platform.write, admin. Contract: route_inferred. Domain Verify Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Dynamic Action Dispatch
Write. Scope: platform.write, admin. Contract: declared_dynamic. Events Clear All
Read. Scope: platform.read, admin. Contract: route_inferred. Events List
Write. Scope: platform.write, admin. Contract: route_inferred. Experiment Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Experiment Results
Write. Scope: platform.write, admin. Contract: route_inferred. Experiment Save
Write. Scope: platform.write, admin. Contract: declared_dynamic. Experiments Clear All
Read. Scope: platform.read, admin. Contract: declared_dynamic. Experiments List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Failed Logins Clear All
Write. Scope: platform.write, admin. Contract: declared_dynamic. Failed Logins Clear History
Write. Scope: platform.write, admin. Contract: route_inferred. Failed Logins Journey
Write. Scope: platform.write, admin. Contract: declared_dynamic. Failed Logins List
Write. Scope: platform.write, admin. Contract: route_inferred. Failed Logins Unblock
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Analysis Get
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Analysis Run
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics All
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Detractors
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Metrics
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Segments
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Sentiment
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Themes
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Analytics Trends
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Assignees List
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Event Outbox Drain
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Exports Create
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Exports Get
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback External Review Ingest
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Ingest Create
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Assign
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Items Evidence
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Follow Up Complete
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Follow Up Set Required fields: bool.
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Items Get
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback Items List
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Mark Read
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Notes Add
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Set Priority
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Set Status
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Tags Add
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Items Tags Remove
Read. Scope: platform.read, admin. Contract: route_inferred. Feedback List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Reconciliation
Write. Scope: platform.write, admin. Contract: declared_dynamic. Feedback Reports Delete
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Reports Email
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Reports Get
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Reports List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Satisfaction Advice Last
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Satisfaction Advise
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Satisfaction Overview
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Sources Health
Read. Scope: platform.read, admin. Contract: declared_dynamic. Feedback Sources List
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Sources Rebuild
Write. Scope: platform.write, admin. Contract: route_inferred. Feedback Sources Replay
Write. Scope: platform.write, admin. Contract: declared_dynamic. Feedback Stats
Write. Scope: platform.write, admin. Contract: declared_dynamic. Fx Refresh Now
Read. Scope: platform.read, admin. Contract: declared_dynamic. Geoip Autodetect
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Admin Chat History
Write. Scope: platform.write, admin. Contract: route_inferred. Get Ai Snapshot
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Campaign Groups
Write. Scope: platform.write, admin. Contract: declared_dynamic. Get Client Chat Knowledge Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Get Kb Categories
Read. Scope: platform.read, admin. Contract: route_inferred. Get Live Health Snapshot
Write. Scope: platform.write, admin. Contract: declared_dynamic. Get Pwa Chat Prefs
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Servers
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Survey Config
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Ticket Options
Read. Scope: platform.read, admin. Contract: route_inferred. Get Ticket Thread
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Todo List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Get Whmcs Health Snapshot
Read. Scope: platform.read, admin. Contract: route_inferred. Get Widget Advanced
Write. Scope: platform.write, admin. Contract: route_inferred. Groups Create
Write. Scope: platform.write, admin. Contract: route_inferred. Groups Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Groups List
Write. Scope: platform.write, admin. Contract: route_inferred. Groups Rename
Write. Scope: platform.write, admin. Contract: route_inferred. Groups Set Primary
Read. Scope: platform.read, admin. Contract: route_inferred. Hc Preview Mint
Write. Scope: platform.write, admin. Contract: route_inferred. Hc Template Apply
Write. Scope: platform.write, admin. Contract: route_inferred. Hc Template Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Hc Template Preview
Write. Scope: platform.write, admin. Contract: route_inferred. Hc Template Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hc Templates List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hc Translation Review Get
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hc Translation Review List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hc Translation Review Revert
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hc Translation Review Save
Read. Scope: platform.read, admin. Contract: route_inferred. Heatmap
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Access Policy List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Access Policy Set
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Access Request
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Access Revoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Accommodation List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Accommodation Resolve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Agent Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Agent Compensation Retry
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Agent Compensation Sweep
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Agent Compensations
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Agent Incident Close
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Agent Register
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Agent Step
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Agent Step Status
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Agent Takeover
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Agent Tool Auth
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Agent Tool Grant
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Agent Tools
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Ai Act Build
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Ai Act Export
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Ai Act Fria Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Ai Act Notice Publish
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Ai Act Overseer Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Ai Act Overseer Revoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Ai Act Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Ai Metering Export
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Ai Metering Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Ai Metering Settings Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Ai Status
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Analytics Ask
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Analytics Snapshot
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Announcement Send
Read. Scope: platform.read, admin. Contract: route_inferred. Hr App Move
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Appeal List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Appeal Resolve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Application List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Auto Offer Run
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Autonomy Lane Demote
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Autonomy Lane Install
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Autonomy Lane Promote
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Autonomy Lane Review
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Autonomy Lane Shadow
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Autonomy Lanes
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Autonomy Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Availability Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Band Approve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Band List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Band Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Benchmarks Contribute Now
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Benchmarks Opt In
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Benchmarks Opt Out
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Benchmarks Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Benefit Enroll
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Benefit Plan Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Bias Audit List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Bias Audit Run
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Booking Link Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Booking Slots Reconcile
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Breaker Reset
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Broadcast Audience Options
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Broadcast List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Broadcast Preview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Broadcast Send
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Budget Set
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Calibration Close
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Calibration Move
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Calibration Open
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Cards Refresh
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Attachment Add
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Case Attachment List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Case Categories
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Event Add
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Case Get
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Intake Mailbox
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Case List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Open
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Route
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Case Thread
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Certification Define
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Certification List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Certification Record
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Certification State
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Certification Types
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Check List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Check Manual Result
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Check Order
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Check Requery
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Check Void
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Checkin Record
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Coach Feedback
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Coach Me
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Coach Receive
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Comp Change Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Comp Change Request
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Compliance Build
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Compliance List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Connector Cert Revoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Connector Cert Submissions
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Connector Cert Submit
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Connector Certify
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Connector Health
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Connector Options
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Connector Revoke
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Contract List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Copilot Apply
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Copilot Plan
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Copilot Recipes
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Copilot Reject
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Correction Dataset Build
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Correction Datasets
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Correction Privacy Review
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Course Enroll
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Course Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Course Skills Tag
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Decision Appeal Assign
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Decision Appeal File
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Decision Appeal Resolve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Decision Appeals List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Decision Explanation
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Decisions Recent
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Discipline Decide
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Discipline Propose
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Document Access Log
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Document Hold
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Document Intake
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Document List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Document Requirement Add
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Document Requirement Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Document Review Approve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Document Reviews
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Dsr List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Dsr Transition
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Email Intake Log
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Employee Access Events
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Employee Provision
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Employee Restore
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Employee Suspend
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Employment Activate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Employment End
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Enterprise Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Equipment Request
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Equipment Returned
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Escrow Resolve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Evidence A11y Record
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Evidence Attest
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Evidence Dr Record
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Evidence Ledgers
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Evidence Load Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Evidence Owner Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Expense Confirm
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Expense Decide
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Expense Handoff
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Expense Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Expense Policy Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Experience Metrics
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Expiry Run
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Fairness Cohort Define
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Fairness Cohorts
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Fairness Evaluate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Faq Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Faq Draft
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Faq List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Faq Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Faq State
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Feedback List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Feedback Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Flag Set
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Flags Get
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Frontline Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Gig Decide
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Gig Post
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Global Readiness
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Goal Create
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Goal Draft
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Goal Update
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Grievance File
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Grievance Outcome
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Headcount Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Headcount Draft
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Headcount List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Hire
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Hiring Decide
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Holiday Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Identity Admin Options
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Identity Conflict Resolve
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Identity Facets
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Identity Link
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Identity Revoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Incident List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Incident Open
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Incident Step
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Review
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Answer
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Interview Room Ask
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Interview Room Connect
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Consent
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room End
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Leave
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Interview Room List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Observe
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Pause
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Provision
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Reconnect
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Resume
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room State
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Room Takeover
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Schedule
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Interview Transcript Correct
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Investigation Close
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Investigation Finding
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Investigation Hold
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Investigation Open
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Investigation Triage
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Iplan Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Iplan Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Iplan List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Iscore Human
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Iscore Run
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Isession Attach Meeting
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Isession Control
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Isession List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Isession Liveness
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Isession Schedule
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Job Arch Analyse
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Arch Apply
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Arch Approve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Job Arch Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Job Arch Propose
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Arch Reject
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Family Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Level Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Job Profile Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Capabilities
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Jurisdiction Case Run
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Jurisdiction Case Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Change Assess
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Jurisdiction Change Close
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Change Raise
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Jurisdiction Coverage
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Explain
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Jurisdiction Pack Draft
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Pack Release
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Pack Withdraw
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Jurisdiction Release List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Jurisdiction Rule Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Source Declare
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Jurisdiction Transfer Declare
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Kill Flip
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Kill Toggle
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Kiosk Register
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Kiosk Revoke
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Knowledge Pack Install
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Knowledge Pack Remove
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Knowledge Packs
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Leadership Score
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Learning Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Leave Decide
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Leave Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Leave Policy Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Leave Type Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Letter Issue
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Letter Kinds
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Letter Preview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Listening Close
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Listening Overview
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Listening Run Due
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Listening Schedule Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Listening Schedule State
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Correct
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Evaluate
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Loop Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Propose
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Release
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Rollback
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Loop Snapshot
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Marketplace Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Meeting Book
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Meeting Cancel
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Meeting Propose
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Meeting Reschedule
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Meetings Overview
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Meetings Reconcile
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Mentor Propose
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Module Toggle
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Offer Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Offer Draft
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Offer Esign Confirm
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Offer List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Offer Send
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Offer Withdraw
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Draft Tasks
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Onboarding Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Plan Create
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Task Block
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Task Done
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Task Unblock
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Task Verify
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Onboarding Template Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr One On One List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr One On One Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Opportunity Decide
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Opportunity Post
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Org Location Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Org Locations
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Org Map Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Org Map Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Org Map Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Org Tree
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Org Unit Create
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Override Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Overtime Decide
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Path Enroll
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Path Save
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Pay Equity Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pay Gap Evaluate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Payroll Import
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Payroll Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Payroll Reconcile
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr People List
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Perf Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Person Create
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Person Get
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Person Update
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pilot Outcome Record
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Pipeline
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Policy Activate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Policy Compile
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pool Create
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pool Member Add
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pool Member Remove
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Pool Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Portal Slug Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Position Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Position Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Position Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Position Profile Set
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Position State
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Position Vacate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Posting Close
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Posting Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Posting List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Posting Publish
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Probation Open
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Probation Review
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pulse Close
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pulse Issue
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Pulse List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Pulse Open
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Pulse Results
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Quality Overview
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Quality Sample Draw
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Quality Samples
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Quality Verdict
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Queue Agent Add
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Queue Agent Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Queue Save
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Readiness Report
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Recognise
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Relations Overview
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Release Gates
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Release Verify
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Req Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Req List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Req Reject
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Req Transition
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Review Cycle Open
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Review Include
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Review Respond
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Review Template Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Rubric Approve
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Rubric Create
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Rubric List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Run Replay
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Run Start
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Run Step
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Run Takeover
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Scenario Run
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Schedule Save
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Screening Correct
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Screening List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Screening Review
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Screening Run
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Screening Verify
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Security Assurance Record
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Service Item Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Servicedesk Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Shadow Compare
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Shift Add
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Shift Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Signature Cancel
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Signature Confirm
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Signature List
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Signature Request
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Signin Design Get
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Signin Design Save
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Skill Challenge Resolve
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Skills Infer Sweep
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Skills Infer Text
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Skills Overview
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Skills Taxonomy Adopt
Write. Scope: platform.write, admin. Contract: declared_dynamic. Hr Status
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Succession Nominate
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Succession Open
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Succession Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Swap Approve
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Swap Decline
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Sync Conflict Resolve
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Talent Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Thread Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Thread Dm
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Thread Legal Hold
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Thread Outreach
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Thread Post
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Thread Read
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Thread Retention
Read. Scope: platform.read, admin. Contract: route_inferred. Hr Thread Search
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Threads Inbox
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Threads Retention Sweep
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Time Decide
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Time Overview
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Training Requirement Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Truth Register
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Turnover Run
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Verifier Verdict
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Wb Grant
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Wb List
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Wb Read
Write. Scope: platform.write, admin. Contract: route_inferred. Hr Wb State
Read. Scope: platform.read, admin. Contract: declared_dynamic. Hr Workforce Dashboard
Write. Scope: platform.write, admin. Contract: route_inferred. Inbound Activity Feed
Write. Scope: platform.write, admin. Contract: route_inferred. Inbound Endpoints Delete
Write. Scope: admin. Contract: route_inferred. Inbound Endpoints List
Write. Scope: platform.write, admin. Contract: route_inferred. Inbound Endpoints Save
Write. Scope: platform.write, admin. Contract: route_inferred. Inbound Endpoints Test
Read. Scope: platform.read, admin. Contract: declared_dynamic. Interrupted
Read. Scope: platform.read, admin. Contract: route_inferred. Ip Classify
Write. Scope: platform.write, admin. Contract: declared_dynamic. Js Errors Clear All
Read. Scope: platform.read, admin. Contract: route_inferred. Js Errors List
Write. Scope: platform.write, admin. Contract: route_inferred. Js Issue Assign
Write. Scope: platform.write, admin. Contract: route_inferred. Js Issue Update
Write. Scope: platform.write, admin. Contract: route_inferred. Js Sourcemap Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Js Sourcemap Upload
Read. Scope: platform.read, admin. Contract: declared_dynamic. Js Sourcemaps List
Read. Scope: platform.read, admin. Contract: route_inferred. Leads
Write. Scope: admin. Contract: declared_dynamic. License Delete
Read. Scope: platform.read, admin. Contract: declared_dynamic. License Diagnostics
Read. Scope: platform.read, admin. Contract: declared_dynamic. License Force Check
Read. Scope: platform.read, admin. Contract: declared_dynamic. License Preflight
Write. Scope: admin. Contract: route_inferred. License Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. License Status
Write. Scope: platform.write, admin. Contract: declared_dynamic. License Verify Now
Read. Scope: platform.read, admin. Contract: route_inferred. Lifecycle Evaluate
Write. Scope: platform.write, admin. Contract: route_inferred. Lifecycle Rule Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Lifecycle Rule List
Write. Scope: platform.write, admin. Contract: route_inferred. Lifecycle Rule Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. List Assignable Sites
Read. Scope: platform.read, admin. Contract: declared_dynamic. List Network Issues
Read. Scope: platform.read, admin. Contract: declared_dynamic. List Sites
Read. Scope: platform.read, admin. Contract: route_inferred. Lookup Client Full
Write. Scope: platform.write, admin. Contract: route_inferred. Mark Feedback Read
Write. Scope: platform.write, admin. Contract: route_inferred. Marketplace Local Install
Write. Scope: platform.write, admin. Contract: route_inferred. Marketplace Local Uninstall
Read. Scope: platform.read, admin. Contract: declared_dynamic. Marketplace Session Get
Write. Scope: platform.write, admin. Contract: route_inferred. Marketplace Session Set
Read. Scope: platform.read, admin. Contract: route_inferred. Media Ready
Write. Scope: platform.write, admin. Contract: route_inferred. Message Contact Locale
Write. Scope: platform.write, admin. Contract: route_inferred. Message Outbound Convert
Write. Scope: platform.write, admin. Contract: route_inferred. Message Translate
Write. Scope: platform.write, admin. Contract: route_inferred. Message Translation Delete
Write. Scope: platform.write, admin. Contract: route_inferred. Message Translation Save
Write. Scope: platform.write, admin. Contract: declared_dynamic. Meta Channels Disconnect
Read. Scope: platform.read, admin. Contract: declared_dynamic. Observe
Read. Scope: platform.read, admin. Contract: declared_dynamic. Onboarding Action
Read. Scope: platform.read, admin. Contract: declared_dynamic. Onboarding Readiness
Read. Scope: platform.read, admin. Contract: declared_dynamic. Open Network Issue
Read. Scope: platform.read, admin. Contract: route_inferred. Open Ticket
Write. Scope: platform.write, admin. Contract: route_inferred. Operator Text Translate
Read. Scope: platform.read, admin. Contract: declared_dynamic. Download a full backup in one request (retired)
Write. Scope: platform.write, admin. Contract: route_inferred. Opsiq Backup Import
Write. Scope: platform.write, admin. Contract: route_inferred. Opsiq Backup Import Start
Write. Scope: platform.write, admin. Contract: route_inferred. Opsiq Backup Job Start
Write. Scope: platform.write, admin. Contract: route_inferred. Opsiq Backup Job Status
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Campaign Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Outreach Campaign List
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Campaign Save
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Campaign Send
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Compose Send
Read. Scope: platform.read, admin. Contract: route_inferred. Outreach Replies List
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Reply Ai
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Reply Mark
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Reply Pref
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Reply Send
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Reply Thread
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Template Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Outreach Template List
Read. Scope: platform.read, admin. Contract: route_inferred. Outreach Template Preview
Write. Scope: platform.write, admin. Contract: route_inferred. Outreach Template Save
Read. Scope: platform.read, admin. Contract: declared_dynamic. Overview
Read. Scope: platform.read, admin. Contract: route_inferred. Overview Hub View
Read. Scope: platform.read, admin. Contract: declared_dynamic. Overview Intelligence Graph
Read. Scope: platform.read, admin. Contract: route_inferred. Pages
Read. Scope: platform.read, admin. Contract: route_inferred. Paths Data
Read. Scope: platform.read, admin. Contract: declared_dynamic. Pause
Write. Scope: platform.write, admin. Contract: declared_dynamic. Profile Change Password
Read. Scope: platform.read, admin. Contract: route_inferred. Profile Get
Write. Scope: platform.write, admin. Contract: route_inferred. Profile Reward Claim
Write. Scope: platform.write, admin. Contract: route_inferred. Profile Reward Claim Cancel
Write. Scope: platform.write, admin. Contract: declared_dynamic. Profile Save
Write. Scope: platform.write, admin. Contract: route_inferred. Profile Session Revoke
Read. Scope: platform.read, admin. Contract: declared_dynamic. Profile Sessions List
Write. Scope: platform.write, admin. Contract: declared_dynamic. Profile Sessions Revoke Others
Write. Scope: platform.write, admin. Contract: route_inferred. Profile Team Dispute File
Write. Scope: admin. Contract: route_inferred. Purge
Write. Scope: admin. Contract: route_inferred. Purge All
Read. Scope: platform.read, admin. Contract: route_inferred. Realtime
Write. Scope: platform.write, admin. Contract: route_inferred. Realtime Test
Read. Scope: platform.read, admin. Contract: declared_dynamic. Resume
Read. Scope: platform.read, admin. Contract: route_inferred. Retention Data
Read. Scope: admin. Contract: source_inferred. List every registered OpsIQ operation
Read. Scope: admin. Contract: explicit. Execute a registered read operation Required fields: route.
Write. Scope: admin. Contract: explicit. Execute a registered write operation Required fields: route, idempotency_key. Retry-safe with idempotency_key.
Write. Scope: platform.write, admin. Contract: route_inferred. Run Ai Analysis
Write. Scope: platform.write, admin. Contract: route_inferred. Save Admin Chat History
Write. Scope: platform.write, admin. Contract: declared_dynamic. Save Pwa Chat Prefs
Write. Scope: platform.write, admin. Contract: route_inferred. Save Survey Config
Write. Scope: platform.write, admin. Contract: declared_dynamic. Save Widget Advanced
Read. Scope: platform.read, admin. Contract: route_inferred. Scim Token Issue
Read. Scope: platform.read, admin. Contract: declared_dynamic. Scim Token List
Write. Scope: platform.write, admin. Contract: route_inferred. Scim Token Revoke
Write. Scope: platform.write, admin. Contract: route_inferred. Segment Delete
Read. Scope: platform.read, admin. Contract: route_inferred. Segment List
Read. Scope: platform.read, admin. Contract: route_inferred. Segment Members
Read. Scope: platform.read, admin. Contract: route_inferred. Segment Preview
Write. Scope: platform.write, admin. Contract: route_inferred. Segment Save
Write. Scope: platform.write, admin. Contract: route_inferred. Segment Suggestion Accept
Write. Scope: platform.write, admin. Contract: route_inferred. Segment Suggestion Dismiss
Read. Scope: platform.read, admin. Contract: route_inferred. Segment Suggestion List
Write. Scope: platform.write, admin. Contract: route_inferred. Send Campaign
Write. Scope: platform.write, admin. Contract: route_inferred. Send Client Email
Write. Scope: platform.write, admin. Contract: route_inferred. Send Ticket Reply
Read. Scope: platform.read, admin. Contract: declared_dynamic. Service Studio Get
Write. Scope: platform.write, admin. Contract: route_inferred. Set Active Site
Read. Scope: platform.read, admin. Contract: declared_dynamic. Silence
Write. Scope: platform.write, admin. Contract: route_inferred. Site Set Group
Write. Scope: platform.write, admin. Contract: route_inferred. Sites Add
Write. Scope: platform.write, admin. Contract: route_inferred. Sites Edit
Write. Scope: platform.write, admin. Contract: route_inferred. Sites List
Write. Scope: platform.write, admin. Contract: route_inferred. Sites Picker
Write. Scope: platform.write, admin. Contract: route_inferred. Sites Remove
Read. Scope: platform.read, admin. Contract: declared_dynamic. Stats
Write. Scope: platform.write, admin. Contract: declared_dynamic. Stepup Verify
Write. Scope: platform.write, admin. Contract: route_inferred. Submit Agent Ai Feedback
Write. Scope: platform.write, admin. Contract: route_inferred. Submit Triage Feedback
Read. Scope: platform.read, admin. Contract: declared_dynamic. Takeover
Read. Scope: platform.read, admin. Contract: route_inferred. Terminate
Read. Scope: platform.read, admin. Contract: route_inferred. Test Geoip
Read. Scope: platform.read, admin. Contract: route_inferred. Top Pages
Write. Scope: platform.write, admin. Contract: route_inferred. Train Client Chat Knowledge
Read. Scope: platform.read, admin. Contract: declared_dynamic. Triggers
Write. Scope: platform.write, admin. Contract: route_inferred. Turn Pool Add
Read. Scope: platform.read, admin. Contract: declared_dynamic. Turn Pool List
Write. Scope: platform.write, admin. Contract: route_inferred. Turn Pool Pick Test
Write. Scope: platform.write, admin. Contract: route_inferred. Turn Pool Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Turn Pool Update
Write. Scope: platform.write, admin. Contract: route_inferred. Update Lead Status
Write. Scope: platform.write, admin. Contract: route_inferred. Wa Embedded Signup Exchange
Read. Scope: platform.read, admin. Contract: declared_dynamic. Warehouse Export Run
Read. Scope: platform.read, admin. Contract: declared_dynamic. Warehouse Exports List
Read. Scope: platform.read, admin. Contract: route_inferred. Webhook Deliveries List
Write. Scope: platform.write, admin. Contract: route_inferred. Webhook Endpoint Delete
Read. Scope: platform.read, admin. Contract: declared_dynamic. Webhook Endpoint List
Write. Scope: platform.write, admin. Contract: route_inferred. Webhook Endpoint Save
Write. Scope: platform.write, admin. Contract: route_inferred. Webhook Endpoint Test
Write. Scope: platform.write, admin. Contract: route_inferred. Webhook Redeliver
Read. Scope: platform.read, admin. Contract: route_inferred. Weekly Digest View
Read. Scope: platform.read, admin. Contract: declared_dynamic. Whmcs Op Dispatch
Write. Scope: platform.write, admin. Contract: declared_dynamic. Workspace Custom Domain Remove
Write. Scope: platform.write, admin. Contract: route_inferred. Workspace Custom Domain Set
Write. Scope: platform.write, admin. Contract: declared_dynamic. Writing Json Knowledge Clear
Read. Scope: platform.read, admin. Contract: declared_dynamic. Writing Json Knowledge Count
Write. Scope: platform.write, admin. Contract: route_inferred. Writing Json Knowledge Import
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Accessibility Evidence Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Domain Add
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Subdomain Allocate
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Analytics Breakdown
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Analytics Load
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Apply Kit
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Apply Theme
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Design Approval
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Approve
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Ask
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Audience Delete
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Audience Explain
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Audience List
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Audience Preview
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Audience Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Brand Generate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Brand Import
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Design Cancel Schedule
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Certify
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Host Check
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Subdomain Check
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Comment Add
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Comment Resolve
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Component Package Inspect
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Component Package Install
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Component Validate
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Handoff Config
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Data Resolve
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Delete Theme
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Developer Contract
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Studio Discovery Preview
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Discovery Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Load
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Save
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Experiment Control
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Experiment Results
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Experiment Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Experiments List
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Form Archive
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Form Catalog
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Create
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Duplicate
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Studio Form Evaluate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Group Apply
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Group Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Group Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Publish
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Form Restore
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Template
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Studio Form Test
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Form Version Restore
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Design History
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Identity Discover
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Identity Load
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Identity Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Activate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Install
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Kill Switch
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Integration List
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Integration Policy
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Integration Policy Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Preflight
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Revise
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Rollback
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Integration Transition
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Archive
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Journey Catalog
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Duplicate
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Studio Journey Evaluate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Instantiate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Restore
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Journey Save
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Kb Category Delete
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Kb Category Reorder
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Kb Category Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Kb Governance
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Kb Governance Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Kb Languages
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Kb Languages Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Kb Parity
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Kb Search Tuning
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Kb Search Tuning Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Kb Tree
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Knowledge Summary
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Domain List
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Analytics Load
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Design Load
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Form Load
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Lock
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Apply
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Approve
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Migration List
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Reconcile
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Migration Report
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Rollback
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Rollout
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Migration Start
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Node Add
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Node Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Node Duplicate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Node Move
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Node Update
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Operations Control
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Operations Feed
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Operations Record
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Operations Summary
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Org Context
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Org Member Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Org Members
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Org Requests
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Archive
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Create
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Duplicate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Restore
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Page Update
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Parity Accept
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Parity Capture
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Parity Compare
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Parity Create
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Parity List
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Personalization Delete
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Personalization List
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Personalization Save
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Presence
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Preview
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Preview Catalog
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Publish
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Quality
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Redirect Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Redirect Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Release Diff
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Design Release Evidence
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Release History
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Publish
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Rollback
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Schedule
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Domain Remove
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Request Changes
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Restore Field
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Restore Published
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Design Revert
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Review
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Review Link
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Rollback
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Form Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Save Theme
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Saved Section Delete
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Saved Section Instantiate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Saved Section Save
Read. Scope: portal_studio.read, admin. Contract: route_inferred. Portal Design Schedule
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Schedule Cancel
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Scim Config
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Archive
Read. Scope: portal_studio.read, admin. Contract: declared_dynamic. Portal Studio Service Catalog
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Duplicate
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Reorder
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Restore
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Studio Service Template
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Sign In Flow Save
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Design Signin Methods
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Handoff Test Link
Write. Scope: portal_studio.write, admin. Contract: declared_dynamic. Portal Studio Unlock
Write. Scope: portal_studio.write, admin. Contract: route_inferred. Portal Image Upload
Write. Scope: sales.write, admin. Contract: route_inferred. Sales Ai Insight
Write. Scope: sales.write, analytics.write, admin. Contract: explicit. Analyze sales with AI Retry-safe with idempotency_key.
Write. Scope: sales.write, admin. Contract: route_inferred. Sales Chart
Read. Scope: sales.read, analytics.read, admin. Contract: explicit. Compare sales periods
Read. Scope: sales.read, admin. Contract: route_inferred. Sales Compare
Write. Scope: sales.write, admin. Contract: route_inferred. Conversion Goal Delete
Read. Scope: sales.read, admin. Contract: route_inferred. Conversion Goal List
Write. Scope: sales.write, admin. Contract: route_inferred. Conversion Goal Save
Read. Scope: sales.read, analytics.read, admin. Contract: explicit. List sales and conversions
Read. Scope: sales.read, admin. Contract: route_inferred. Conversion List
Write. Scope: sales.write, admin. Contract: route_inferred. Conversion Record
Read. Scope: sales.read, analytics.read, admin. Contract: explicit. Read sales statistics
Read. Scope: sales.read, admin. Contract: declared_dynamic. Sales Stats
Read. Scope: sales.read, admin. Contract: route_inferred. Sales Table
Write. Scope: security.write, admin. Contract: route_inferred. Security Ai Analyze
Write. Scope: security.write, admin. Contract: route_inferred. Security Ai Ask
Read. Scope: security.read, admin. Contract: declared_dynamic. Security Ai Briefs
Read. Scope: security.read, admin. Contract: route_inferred. Security Ai Chain Explain
Write. Scope: security.write, admin. Contract: route_inferred. Security Ai Incident Action
Read. Scope: security.read, admin. Contract: route_inferred. Security Ai Incidents
Read. Scope: security.read, admin. Contract: route_inferred. Security Ai Js Triage
Read. Scope: security.read, admin. Contract: declared_dynamic. Security Ai Policies
Write. Scope: security.write, admin. Contract: route_inferred. Security Ai Policy Action
Read. Scope: security.read, admin. Contract: route_inferred. Security Ai Verdicts
Write. Scope: security.write, admin. Contract: source_inferred. Add a spam rule (email, domain or IP) to the ticket blocklist Required fields: kind, value. Retry-safe with idempotency_key.
Read. Scope: security.read, admin. Contract: explicit. List the current ticket spam rules
Write. Scope: security.write, admin. Contract: declared_dynamic. Security Chain Reanchor
Read. Scope: security.read, admin. Contract: source_inferred. Check an IP or email against the platform blocklists and Security AI verdicts
Write. Scope: security.write, admin. Contract: route_inferred. Block Ip
Write. Scope: security.write, admin. Contract: route_inferred. Unblock Ip
Write. Scope: security.write, admin. Contract: route_inferred. Access Log List
Read. Scope: security.read, admin. Contract: declared_dynamic. Security Overview Chains
Read. Scope: security.read, admin. Contract: declared_dynamic. Security Overview Data
Write. Scope: security.write, admin. Contract: source_inferred. Report abuse a connector observed (spam, login attack, scan, fraud) Retry-safe with idempotency_key.
Write. Scope: security.write, admin. Contract: route_inferred. Block Visitor
Read. Scope: sessions.read, admin. Contract: route_inferred. Session Detail
Read. Scope: sessions.read, analytics.read, admin. Contract: explicit. Get a session journey Required fields: session_id.
Read. Scope: sessions.read, analytics.read, admin. Contract: explicit. List sessions
Read. Scope: sessions.read, admin. Contract: route_inferred. Sessions Merged
Read. Scope: sessions.read, admin. Contract: route_inferred. Sessions Table
Write. Scope: settings.write, admin. Contract: declared_dynamic. Ai Eval Watchtower Config
Read. Scope: settings.read, admin. Contract: route_inferred. Get Client Chat Settings
Read. Scope: settings.read, admin. Contract: route_inferred. Get Settings
Write. Scope: admin. Contract: route_inferred. Opsiq Branding Clear
Write. Scope: admin. Contract: route_inferred. Opsiq Branding Upload
Read. Scope: settings.read, admin. Contract: declared_dynamic. Privacy Settings Get
Write. Scope: settings.write, admin. Contract: route_inferred. Privacy Settings Save
Write. Scope: settings.write, admin. Contract: route_inferred. Save Ai Settings
Write. Scope: settings.write, admin. Contract: declared_dynamic. Save Chat Widget Settings
Write. Scope: settings.write, admin. Contract: route_inferred. Save Client Chat Settings
Write. Scope: settings.write, admin. Contract: route_inferred. Save Settings
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Action Audit Chain
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Action Execute
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Action Preview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Action Token
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Auto Bg
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Auto Bg Stop
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Auto Step
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Chat
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Conn Delete
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Conn Get
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Conn Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Conn Test
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Coverage
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Events
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Apply
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Finalize
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Live Set
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Preview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Rollback
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Start
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Hosted Verify
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Delete
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Finalize
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Rollback
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Start
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Status
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Run Verify
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Runs List
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Set Mode
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Status
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Step Apply
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Step Skip
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Agent Turn Status
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Ai Activity
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Alert Enrich
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Alerts
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Analyst
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Analyst Ask
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Analyst Email
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Analyst Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Badges
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Ai Badges Portfolio
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Badges Preview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Bl Plan
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Bl Plan Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Brief
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Brief Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Comp Analyse
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Comp Analyse Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Content Get
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Content List
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Content Publish
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Content Write
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Daily Digest
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Discover
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Apply
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Apply Bulk
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Dismiss
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Dismiss Bulk
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Generate
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix Generate All
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Fix List
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Kw Coach
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Kw Coach Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Overview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Page Audit
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Page Audit Run
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Ai Portfolio
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Ai Portfolio History
Write. Scope: site_intelligence.write, admin. Contract: declared_dynamic. Si Ai Portfolio Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Probe
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Prompt Add
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Prompt History
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Prompt Remove
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Prompts
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Readiness
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ai Ready
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Alert Resolve
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Alerts
Read. Scope: site_intelligence.read, admin. Contract: explicit. List Site Intelligence alerts
Write. Scope: site_intelligence.write, admin. Contract: explicit. Resolve a Site Intelligence alert Required fields: alert_id. Retry-safe with idempotency_key.
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Analyze
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ask
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Audit Hint
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Backlink Disavow
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Backlinks
Read. Scope: site_intelligence.read, admin. Contract: explicit. List backlinks
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Backlinks Refresh
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Billing Overview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Brand Get
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Brand Radar
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Brand Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Cannibalisation
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Compare
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Competitor Add
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Competitor Refresh
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Competitor Remove
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Competitors
Read. Scope: site_intelligence.read, admin. Contract: explicit. List competitors
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Content Brief
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Content Decay
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Content Draft
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Crawl Budget
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Crawl List
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Crawl Status
Read. Scope: site_intelligence.read, admin. Contract: explicit. List Site Intelligence crawls
Read. Scope: site_intelligence.read, admin. Contract: explicit. Get crawl status
Read. Scope: site_intelligence.read, admin. Contract: explicit. Read the Site Intelligence dashboard
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Dashboard
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Dashboard Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Backfill
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Compare
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Diag Portfolio
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Recs Regen
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Thresholds
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Thresholds Eval
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Thresholds History
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Thresholds Profile
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diag Thresholds Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Diagnostics
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Exec Report
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Export
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ga4 Connect
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ga4 List Properties
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ga4 Map
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ga4 Status
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Ga4 Sync
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Draft Approve
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Draft Dismiss
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Draft Sync
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Drafts
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Gbp Locations
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Map
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Post Draft
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Post Publish
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Qa
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Qa Approve
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Qa Dismiss
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Qa Sync
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Site Prefs
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gbp Sync
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Google Truth Schedule Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Growth
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc Connect
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc List Properties
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc Map
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc Opportunities
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc Status
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Gsc Sync
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Image Audit
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Internal Links
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Issue History
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Issues
Read. Scope: site_intelligence.read, admin. Contract: explicit. List Site Intelligence issues
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Keyword Add
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Keyword Remove
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Keyword Research
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Keywords
Read. Scope: site_intelligence.read, admin. Contract: explicit. List tracked keywords
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Local
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Local Grid
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Local Grid Scan
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Log Ingest
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Log Summary
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Metadata Audit
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Overview
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Page
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Page Experience
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Page Optimize
Read. Scope: site_intelligence.read, admin. Contract: route_inferred. Si Pages
Read. Scope: site_intelligence.read, admin. Contract: explicit. List Site Intelligence pages
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Pagespeed Bridge Status
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Portfolio Export
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Provider Health
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Rank Check
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Rec Action
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Recommendations
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Redirect Audit
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Report
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Report Generate
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Reports
Read. Scope: site_intelligence.read, admin. Contract: source_inferred. Site Intelligence Reports List
Write. Scope: site_intelligence.write, admin. Contract: declared_dynamic. Si Reset Google Oauth
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Revenue
Read. Scope: site_intelligence.read, admin. Contract: declared_dynamic. Si Revenue Portfolio
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Save Shared Google Oauth
Write. Scope: site_intelligence.write, admin. Contract: explicit. Start a Site Intelligence analysis Retry-safe with idempotency_key.
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Schedule Delete
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Schedule Run Now
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Schedule Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Schedules List
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Schema Audit
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Server Engineer
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Settings Save
Read. Scope: site_intelligence.read, admin. Contract: explicit. List Site Intelligence monitored sites
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed Progress
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed V2
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed V2 Build Task
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed V2 Collect
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed V2 Read
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Speed V2 Run
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Start Crawl
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Approve
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Assign
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Bulk Apply
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Bulk Assign
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Bulk Deadline
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Bulk Dismiss
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Deadline
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Note
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Proof
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Reject
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Task Review
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Topical Map
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Webhook Delete
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Webhook Save
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Webhooks List
Write. Scope: site_intelligence.write, admin. Contract: route_inferred. Si Workflow
Write. Scope: status.write, admin. Contract: declared_dynamic. Status Component Save
Write. Scope: status.write, admin. Contract: explicit. Create or update a public status component Required fields: name. Retry-safe with idempotency_key.
Write. Scope: status.write, admin. Contract: declared_dynamic. Status Incident Create
Read. Scope: status.read, admin. Contract: route_inferred. Status Incident Resolve
Write. Scope: status.write, admin. Contract: explicit. Create a status-page incident Required fields: title. Retry-safe with idempotency_key.
Write. Scope: status.write, admin. Contract: source_inferred. Status Incidents Resolve Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: source_inferred. Surveys Analytics Get
Read. Scope: surveys.read, admin. Contract: explicit. List survey audiences
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Audiences Materialize Retry-safe with idempotency_key.
Write. Scope: surveys.write, admin. Contract: explicit. Create or update a survey campaign Required fields: deployment_id. Retry-safe with idempotency_key.
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Campaigns Launch Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: explicit. List survey campaigns
Read. Scope: surveys.read, admin. Contract: explicit. List survey deployments
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Deployments Set Status Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: source_inferred. Surveys Get
Write. Scope: surveys.write, admin. Contract: explicit. Create and run a survey import Required fields: kind. Retry-safe with idempotency_key.
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Imports Process Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: explicit. List survey invitations
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Links Create Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: explicit. List survey definitions
Read. Scope: surveys.read, admin. Contract: source_inferred. Surveys Responses Get
Read. Scope: surveys.read, admin. Contract: explicit. List survey responses
Read. Scope: surveys.read, admin. Contract: explicit. List survey trigger sets
Read. Scope: surveys.read, admin. Contract: explicit. List supported question types and Studio templates
Read. Scope: surveys.read, admin. Contract: source_inferred. Surveys Versions List
Write. Scope: surveys.write, admin. Contract: source_inferred. Surveys Webhooks Delete Retry-safe with idempotency_key.
Read. Scope: surveys.read, admin. Contract: explicit. List survey webhook subscriptions
Write. Scope: surveys.write, admin. Contract: explicit. Create or update a survey webhook subscription Required fields: url. Retry-safe with idempotency_key.
Write. Scope: team.write, admin. Contract: route_inferred. Admin Users Delete
Write. Scope: team.write, admin. Contract: route_inferred. Departments Delete
Read. Scope: team.read, admin. Contract: route_inferred. Admin Users List
Read. Scope: team.read, admin. Contract: declared_dynamic. Departments List
Write. Scope: admin. Contract: route_inferred. Team Perf Activity
Write. Scope: admin. Contract: route_inferred. Team Perf Ai Compare
Write. Scope: admin. Contract: route_inferred. Team Perf Ai Review
Write. Scope: admin. Contract: route_inferred. Team Perf Availability
Write. Scope: admin. Contract: route_inferred. Team Perf Award Finalize
Read. Scope: team.read, admin. Contract: route_inferred. Team Perf Award History
Write. Scope: admin. Contract: route_inferred. Team Perf Award Void
Write. Scope: admin. Contract: route_inferred. Team Perf Claim Pay
Write. Scope: admin. Contract: route_inferred. Team Perf Claim Recover
Write. Scope: admin. Contract: route_inferred. Team Perf Claim Reject
Write. Scope: admin. Contract: route_inferred. Team Perf Clear
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Action Item Add
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Action Item Complete
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Evidence Pin
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Evidence Unpin
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Session
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Session Create
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Session Update
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Sessions
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Coaching Status
Write. Scope: admin. Contract: route_inferred. Team Perf Data
Write. Scope: admin. Contract: route_inferred. Team Perf Heatmap
Write. Scope: admin. Contract: route_inferred. Team Perf History
Write. Scope: admin. Contract: route_inferred. Team Perf Pay All Claims
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Calibration Record
Write. Scope: admin. Contract: route_inferred. Team Perf Qa Dispute Resolve
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Disputes
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Evaluation Submit
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Overview
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Scorecard Publish
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Qa Scorecard Save
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Quest Record
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Quest Save
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Quest Status
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Quests
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Recognition
Write. Scope: admin. Contract: route_inferred. Team Perf Recognition Settings Save
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Recognition Streak History
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Recognition Streaks Record
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Budget Authorize
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Claims
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Pay
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Payouts
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Period Finalize
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Reward Period History
Write. Scope: team.write, admin. Contract: route_inferred. Team Perf Reward Period Preview
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Period Reverse
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Period Void
Write. Scope: admin. Contract: route_inferred. Team Perf Reward Save
Write. Scope: admin. Contract: route_inferred. Team Perf Reward State
Write. Scope: admin. Contract: route_inferred. Team Perf Trends
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Data
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Export
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Live
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Reward Sheet
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Settings
Write. Scope: admin. Contract: route_inferred. Team Perf V2 Settings Save
Write. Scope: team.write, admin. Contract: route_inferred. Admin Users Save
Write. Scope: team.write, admin. Contract: route_inferred. Departments Save
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Ai Summary
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Analytics
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Approval Decide
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Approval Request
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Ticket Approvals Pending
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Assignment Rule Delete
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Ticket Assignment Rule List
Write. Scope: tickets.write, admin. Contract: declared_dynamic. Ticket Assignment Rule Save
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Assignment Rules Delete Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: explicit. Create or update a ticket assignment rule Required fields: name. Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Bulk Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: route_inferred. Tickets Bulk
Write. Scope: tickets.write, admin. Contract: route_inferred. Sla Calendar Delete
Write. Scope: tickets.write, admin. Contract: declared_dynamic. Sla Calendar Save
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Claim
Read. Scope: tickets.read, admin. Contract: explicit. Get the CSAT response for one ticket Required fields: ticket_id.
Read. Scope: tickets.read, admin. Contract: explicit. List ticket CSAT responses in the bound workspace
Read. Scope: tickets.read, admin. Contract: explicit. CSAT metrics for a period (the tickets dashboard numbers)
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Embed Load
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Embed Save
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Embed Secret
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Field Save
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Follower Add
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Follower Remove
Read. Scope: tickets.read, admin. Contract: source_inferred. Tickets Get
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Kb Deflection
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Kb Draft
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Kb Save
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Kb Version Restore
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Kb Versions
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Link Add
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Link Remove
Read. Scope: tickets.read, admin. Contract: source_inferred. Tickets List
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Open Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Open Guest Retry-safe with idempotency_key.
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Ticket Ops Summary
Write. Scope: tickets.write, admin. Contract: route_inferred. Sla Policy Delete
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Sla Policy List
Write. Scope: tickets.write, admin. Contract: declared_dynamic. Sla Policy Save
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Presence Leave
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Presence Ping
Write. Scope: tickets.write, admin. Contract: declared_dynamic. Ticket Quick Replies
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Quick Reply Save
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Relations Get
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Reply Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Delete
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Edit
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Outbound Convert
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Translate
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Translation Delete
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Reply Translation Save
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Rule Compose
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Side Ai Draft
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Side Assign Department
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Side Create
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Side List
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Side Mention
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Ticket Side Recipients
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Side Reply
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Sla Delete Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: explicit. Create or update an SLA policy Required fields: name. Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Split
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Split Candidates
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Tag Add
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Tag List
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Tag Remove
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Tags Add Retry-safe with idempotency_key.
Read. Scope: tickets.read, admin. Contract: source_inferred. Tickets Tags List
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Tags Remove Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: source_inferred. Update a ticket status, priority, subject, department or assignment Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket View Delete
Read. Scope: tickets.read, admin. Contract: declared_dynamic. Ticket View List
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket View Save
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Views Delete Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: source_inferred. Tickets Views Save Retry-safe with idempotency_key.
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Worklog Add
Write. Scope: tickets.write, admin. Contract: route_inferred. Ticket Worklog Delete
Read. Scope: tickets.read, admin. Contract: route_inferred. Ticket Worklog List
Write. Scope: todos.write, admin. Contract: source_inferred. Todos Add Retry-safe with idempotency_key.
Write. Scope: visitors.write, security.write, admin. Contract: explicit. Block a visitor Required fields: visitor_id. Retry-safe with idempotency_key.
Read. Scope: visitors.read, analytics.read, admin. Contract: explicit. List visitors
Read. Scope: visitors.read, admin. Contract: route_inferred. Visitors Table
Read. Scope: webhooks.read, crm.read, admin. Contract: explicit. List outbound webhook events and their payloads
Write. Scope: writing. Contract: source_inferred. Writing Analyze Retry-safe with idempotency_key.
Write. Scope: writing. Contract: source_inferred. Writing Compose Retry-safe with idempotency_key.
Write. Scope: writing. Contract: source_inferred. Writing Reply Retry-safe with idempotency_key.
Write. Scope: writing. Contract: source_inferred. Writing Rewrite Retry-safe with idempotency_key.
Write. Scope: writing. Contract: source_inferred. Writing Summarize Retry-safe with idempotency_key.
Write. Scope: writing. Contract: source_inferred. Writing Translate Retry-safe with idempotency_key.
Yes. The generated OpenAPI 3.0 document is at /api/v1/openapi.php, the generated Postman collection is at /api/v1/postman.php, and the human-readable developer docs are at /api/docs/.
Send site_key in the request body to choose a workspace. A key issued for one workspace stays pinned to it; a key with admin context can select any workspace it is permitted to see, and is refused for any it is not.
Any action marked as a read. Set the permissions mode on the key to read_only and every write is refused with read_only_key, so a reporting integration cannot change anything even by mistake.
The key is scoped to a workspace. Records in other workspaces return not_found rather than a permission error, so the API never confirms whether something exists elsewhere.
One security contract for every connector and integration: ask OpsIQ what it knows about an IP or sender, and feed back the abuse your own system sees.
OpsIQ already defends itself: the IP firewall blocks attackers, the ticket pipeline filters spam, and the Security AI classifies offenders and proposes block rules. The Security API opens that intelligence to your other systems. A billing platform, a client portal or a custom app can check a visitor before trusting it, and report what it observed so the whole install learns from every surface.
security.check answers with the firewall state, any spam rule matching the sender, and the cached AI verdict for the IP. One call, one consolidated opinion.
security.report records the observation as a security event, has the Security AI classify the IP right away, and alerts the admins when the verdict comes back high risk. Repeated reports cluster into incidents, exactly like attacks OpsIQ sees directly.
security.blocklist.add and security.blocklist.list read and write the same spam rules the Tickets page uses, so a sender blocked in one system is blocked everywhere.
POST /api/v1.php
Authorization: Bearer opq_your_api_key
Content-Type: application/json
{
"action": "security.report",
"ip": "203.0.113.7",
"kind": "spam",
"reason": "Sent 40 junk tickets in 10 minutes",
"source": "whmcs:example.com"
}Needed for security.check and security.blocklist.list. Safe to give a reporting integration.
Needed for security.report and security.blocklist.add. Give it only to systems you want feeding rules and reports in.
A blocklisted sender still lands in the Spam view where the ticket can be read and restored.
The server's own IP addresses can never be blocked, blocklisted or reported through this API, so a misconfigured integration cannot take the platform down.
Outbound sync is already automatic: when you block an IP, connected platforms are told through the connector security sync. The Security API is the inbound half. Point your connector or custom code at these four actions with a key carrying the security scopes.
One store. The Tickets page Block sender control, the spam AI in Settings, and this API all work against the same blocklist, so there is exactly one place to look.
Send custom events from your server or website to OpsIQ for analytics, experiments, CRM triggers, and webhook conditions.
window.OpsIQ = window.OpsIQ || [];
window.OpsIQ.push(["track", "button_clicked", {
button: "signup",
page: "/pricing",
variant: "green"
}]);Server-side, record activities and conversions against a contact through the action API. Use crm.activities.record for lifecycle/business activity and crm.conversions.record for conversions. There is no events.send action; the inbound CRM event receiver lives at /v1/inbound.php?t=<token> for third-party systems that push events in.
POST /api/v1.php
Authorization: Bearer opq_your_key
Content-Type: application/json
{
"action": "crm.activities.record",
"site_key": "site_abc123",
"email": "[email protected]",
"event": "subscription.upgraded",
"value": 50,
"currency": "USD"
}"order.completed" not "orderCompleted".
"button.clicked" not "button.click".
"pricing.plan_selected" not "user_action".
Understanding the data flow helps you debug integrations and optimize performance.
The JavaScript widget sends page views, clicks, and chat messages to /beacon.php.
Events stored in opsiq_events with site_key, event type, customer, and properties.
Session builder groups page views into sessions (via cron).
When identified, anonymous records are linked to the customer profile.
Connectors pull data from external platforms and store in the connector cache.
AI assembles context from: visitor history, customer profile, connector data, KB, and prompt.
Internal event fires (ticket.created, chat.message, order.completed).
Event placed in the async job queue.
Dispatcher signs and sends to all subscribed endpoints.
Failed deliveries retried with exponential backoff.
Settings is the control centre for a workspace. Everything below is scoped to the workspace you are in, so one account can run several brands with different identities, chat behaviour and retention rules.
There are around six hundred individual controls in Settings, spread across eleven tabs grouped under four menus. You are not expected to browse for them.
Press Ctrl + K, or Cmd + K on a Mac, anywhere on the Settings page. Type in plain words and press Enter to jump straight to the control. Search tolerates small typos and understands related words, so scheduler finds Cron and privacy finds the tracking controls. It only shows settings your role can open.
General and Licence.
Admin AI Assistant, Client Chat, OpsIQ Writing and Support Portal.
Tracking and Privacy, Permissions and Security.
Cron Setup (self-hosted only) and Danger Zone.
Each tab saves on its own with its own Save button. Client Chat and OpsIQ Writing pin theirs to the screen. Save before switching tabs; changes are not carried across.
The active tab is written into the page address, so a tab can be bookmarked or sent to a colleague.
The most important card on the page. The AI reads these values on every reply, report and daily brief.
Used in AI reports, daily briefs and customer-facing wording. Match your website footer.
Tailors AI analysis, lead scoring, briefs and survey presets. Choose from web hosting, e-commerce, SaaS, real estate, agency, consulting, healthcare, education, finance or general business.
The language shown to anyone who has not chosen their own. Each agent can override it in their profile.
Shows the sign-in page in the visitor own language. Once someone picks a language there, their choice wins and this never overrides it.
The zone the whole system runs in: dates, reports, schedules and the background cron. Use your operations timezone, not your customers.
Full path to GeoLite2-City.mmdb. Auto-detects on first load across cPanel, Plesk, DirectAdmin, Cloudways, Docker and plain Linux or Windows. Add GeoLite2-ASN.mmdb in the same folder for the visitor internet provider.
GeoLite2 only, GeoLite2 with a Cloudflare fallback, or Cloudflare only. Cloudflare modes require the site to be proxied through Cloudflare, with visitor location headers enabled for city and region detail.
Inactivity before a visitor session is considered finished. Default 14400, which is four hours.
How often the Live Feed refreshes. Default 30 seconds.
How long a visitor counts as live after their last page load. Default 2 minutes. This is the Live Feed drop-off, not the session length.
Deletes collected and generated records past this age: analytics, chat, tickets, feedback, transactions, AI telemetry, integration logs and CRM activity. 0 keeps everything forever. Settings, authored content and consent receipts are never removed.
Chooses how much of a deleted conversation stays on record: the full record, the record without the conversation, or the score only. Deleting always hides the chat from the inbox and the visitor history. Scheduled retention and Forget visitor always erase in full regardless of this.
Counts crawlers as visitors. Leave off; it inflates visitor counts and skews every report.
Shows the site-wide feedback widget to visitors. Separate from the chat surveys under Client Chat, Support Flow.
Master switches for each AI surface. All default to on and save per workspace.
Classifies every ticket by category, priority and sentiment, and writes a thread summary at the top of the ticket.
Shows the triage tags and summary in a tooltip when an agent hovers a row in the ticket list. Requires AI Triage.
Adds Draft AI reply, Warmer, Shorter, More formal and Apologetic buttons under the ticket reply box. Nothing sends without the agent.
The page-aware floating copilot on every admin page. Knows which customer, invoice or ticket is open.
On first open each day the copilot presents urgent tickets, overdue replies and waiting chats. Sundays produce a week in review.
Every money total in the admin is converted into this currency for display. Connectors store their own source currency; set that per connector.
Refreshes rates every six hours from a free public feed with no API key. You can add manual rates that override the feed. With auto-sync off, currencies without a manual rate are left unconverted.
Ships off. Turning it on reveals the Sales and Conversions page, the dashboard revenue cards and the Live Intelligence Feed. With it off, every price surface is hidden and the Sales page leaves the menu.
Teaches OpsIQ your wording: whether you do renewals, the word for renewing, what you sell, and what buyers are called.
Two uploads, one for light backgrounds (admin sidebar) and one for dark (sign-in page). PNG, JPG, WebP or SVG up to 3 MB.
The Auto-Implement SEO agent connects over SSH. Private, loopback and reserved addresses are blocked by default as an anti-SSRF measure. Only enable on self-hosted installs that must reach a local server.
Exports every setting and OpsIQ-owned table plus uploaded files. Restore replaces OpsIQ configuration and records only; it never touches clients, invoices, tickets, services, domains, orders or transactions.
Protection for the admin sign-in, your staff accounts and the data OpsIQ collects. Customer sign-in for the support portal is configured separately.
Stops bots and credential stuffing on the admin sign-in. Choose v3 (invisible, scored) or v2 (checkbox), set the v3 score threshold, and supply the site and secret keys. These same keys are reused by the support portal request form.
Blocks an address after a number of failures within a window, for a number of hours. You can customise the locked-page message and show a small wait-screen distraction.
Password policy with a minimum length, rejection of passwords found in known breaches, per-account lockout against credential stuffing, mandatory two-factor for every admin, password re-entry before dangerous actions, and new-device sign-in alerts.
Staff sign-in through your identity provider. Needs issuer URL, client ID and client secret. Auto-provision domains, one per line, create users automatically on first sign-in.
For providers that speak SAML. OpsIQ supplies the ACS reply URL and SP entity ID; you supply the IdP entity ID, sign-in URL, optional sign-out URL and X.509 signing certificate. Email and name attribute fields are only needed for non-standard attribute names.
Directory-driven creation, update and deactivation of OpsIQ accounts. OpsIQ supplies the SCIM base URL; you generate labelled tokens here so one can be revoked without breaking the rest.
Restricts which external hosts this workspace connectors may call. Companion to the SSH target control in General.
Blocks a visitor once their threat score passes your threshold. 0 disables it. Watch the Security Overview page for a week before choosing a number.
The message a blocked visitor sees, as plain text or your own custom HTML block screen.
Measures LCP, INP and CLS from real sessions.
Custom events queue in the browser and deliver in batches with retries, reducing loss on poor mobile connections.
Real widget embeds carry a rotating cryptographic token so forged tracking data can be rejected. Off by default; enabling changes how embeds authenticate, so test first.
Off by default. Detection and blocking run regardless. This card controls whether you are told, and how much the AI assists.
Master switch for this card.
How many failed sign-ins in a short period count as a wave worth alerting on.
Adds a threat score for visitors appearing in public abuse feeds.
Hourly uptime and TLS expiry checks, alerting before a certificate lapses.
Adds an explainable verdict to suspicious activity, and groups related attacks into a single readable incident rather than a stream of events.
Acts on its own, turning what it learns from an incident into a proposed or applied rule. Leave off until you have reviewed its proposals and agree with them.
A daily recap on the Security Overview page, and a weekly hardening checklist showing what is protected and what is still open.
A proposed block rule you never acted on expires by itself instead of accumulating.
Records visitor sessions for playback. When off the replay library is never loaded, so there is no cost to leaving it off. Recordings are sampled and privacy-masked, and are watched on the Session Replay page under Analytics.
What share of sessions to record, how long a single recording may run, and how many days recordings are kept.
What OpsIQ may collect, and how long each kind of record survives.
Addresses never tracked, one per line, exact addresses or CIDR ranges. The cleanest way to keep your own team out of your analytics, because it covers everyone at that address rather than only signed-in admins.
Page patterns never tracked, one per line, wildcards with an asterisk. For example /admin/* keeps the whole back office out of the visitor log.
Per-subsystem auto-purge in days. Separate from the overall Data Retention setting in General and from the Danger Zone purge.
Confidence telemetry holding short previews of query and response. Default 90 days. This holds the most customer text, so shorten it first when tightening privacy.
Per-call token counts for cost reporting. Default 90 days. Numbers only, no message content.
The tamper-evident action and security log. Default 365 days. Keep this longest; it is your evidence trail.
System health records. Default 30 days.
Clusters of questions the AI could not answer. Default 90 days. Work through them on the Questions the AI missed page before they expire.
Daily comparison of yesterday against the recent baseline, alerting when a metric moves more than your threshold. Default 35 percent. Off by default.
Nightly dumps of sessions, visitors, pageviews and related tables for your own BI stack, in a format you choose, kept for a number of days. Off by default.
The floating assistant your staff use inside the admin, with live read access to clients, invoices, tickets, servers and cron logs. A different assistant from the customer-facing one under Client Chat.
Shows the assistant button on every admin page. Off hides it for everyone.
Corner position, panel width (320 to 600 px), max height (400 to 900 px), corner radius (0 to 24), font size, and a frosted glass blur behind the panel.
One-click shortcut buttons under the header. The fastest way in for most staff.
Displays which model answered and how long it took. Useful while tuning cost, noise for everyday use.
Only shows the assistant to a signed-in admin whose username and email both match an OpsIQ agent assigned to this workspace. Owners always pass. Use the Check my access button before enabling or you can lock your own team out.
Display name, header tagline and a custom welcome message shown when the panel opens.
Edit the label and underlying prompt for each shortcut, add your own, or reset to defaults. The label is what staff see, the prompt is what the AI receives.
Chip shape (pill, rounded, square), chip colours, card theme and launcher shape (round, squircle, square), with a live preview.
The assistant remembers each person history across browser sessions, up to 120 messages, stored in your own database. Clear it to start fresh.
The chat widget your customers use, and the largest area of Settings. Six sub-tabs, with the master switch and Save pinned to the top of the tab.
Work through the sub-tabs in order on a new install: Identity and Copy, Appearance, Behavior, Support Flow, Knowledge Training. Advanced is infrastructure and can wait.
Widget name, tagline, AI name, the name used for system and idle notices, and how agent names appear. Agent Name Source decides between real names, a custom name or a team label.
Two greetings, one for all visitors and one for identified visitors. A question starts more conversations than a statement.
The floating message before the chat is opened, with its own name, font size and colours. The AI can write the teasers, with controls for how many to generate, how many to show per visit and the gap between them.
The full script: asking for a name and email, confirmations, requesting a human, no agents available, ticket created or cancelled, handoff pending. Around two dozen individual lines in a collapsible panel.
Three customer-visible messages: agent closes the chat, visitor has gone quiet, and agent hands back to the AI. Avoid internal wording like resolved or triaged.
Input placeholder, the talk-to-a-human button label, and the suggested opening questions. Three good suggestions deflect more tickets than a page of articles.
Launcher icon, an optional different icon when open, launcher size, and images for the human agent and the AI.
Theme mode, a premium colour preset, blur intensity and opacity, plus toggles for animations, separator lines, hiding the status row, hiding the message box card and hiding the close button. Start with a preset; it sets dozens of colours at once.
Launcher, header, help panel, links, buttons, system notices and composer, each with a start and end colour for gradients. A use default glass option ignores these and keeps the transparent finish.
Around thirty pickers covering the panel, border, text, input area and every bubble type (visitor, AI, agent, typing, system) plus suggestion chips and their hover state. Only open this for exact brand matching, and check contrast on bubble text.
Panel width and height, corner radius, font size, screen position, launcher shape, bubble style and whether avatars show. Test the width on a phone.
Master switch for AI replies. Off means every message waits for a human.
A gentle follow-up when a visitor goes quiet, and an optional short second message the way a person would send one. Tuned with max follow-ups per silence, first delay, later multiplier, presence window and maximum sequence window. Can be limited to business hours, and suppressed after a simple thanks.
Whether replies type out word by word, and how fast the assistant answers, by preset or your own minimum and maximum delay in milliseconds. A small delay reads as more human than an instant reply.
Each agent reads and writes in their own language while the visitor reads theirs.
Minutes of agent inactivity before the AI resumes the conversation.
Seconds before the widget opens itself. 0 never opens. Intrusive on mobile; leave at 0 unless tested.
Planning ahead for one-pass answers, thinking depth, an optional separate model for agent answers, showing reasoning to visitors, tolerating misspellings, long-conversation memory, restricting the assistant to your business only, prices in the visitor currency, and how links appear. Only talk about your business should be on for almost everyone.
Skips knowledge search for greetings such as hi and thanks, and caps the longest reply in tokens. Trims cost without changing answer quality on real questions.
Which languages the widget supports and how it picks one for a visitor.
Answers from a signed-in customer own account, optionally looked up live, and optionally loaded only when needed. Read-only in all cases; load-when-needed noticeably reduces cost.
Assisted refund requests where the assistant gathers detail and hands to a person. It never completes a refund itself.
Keeping past conversations, continuing a chat across your connected sites, draggable window, asking guests for an email, and letting your team turn a chat into a ticket.
Emoji picker, attachments with an optional paste-only mode, AI image understanding, inline icons, microphone, talk-to-agent button, visitor sounds, attachment preview, voice-call button and session isolation. AI image understanding is what lets a visitor paste an error screenshot and get a useful answer.
The visitor welcome popup, plus your agents alerts: inbox sounds, desktop notifications, whisper sounds, whether private whispers beep, and the inbox poll interval.
How requests for a person are assigned, the seconds an agent has to respond, whether declining returns the chat to the AI, and whether the AI resumes when the timeout expires. Configure this before going live or a visitor who asks for a human simply waits.
Opening times, timezone and the closed-hours message. Outside these hours the AI will not offer a human. A separate schedule from the ticket business hours under OpsIQ Writing.
The first reply to a new message, the reply when someone is already queued, and how long before repeating.
Shows a contact form instead of the chat.
AI ticket awareness, so a visitor quoting a ticket number gets its real status, and which departments the AI may route to. A built-in panel shows the real recipients for each department, resolved the same way the notifier resolves them, so you can see before a customer does that a department alerts nobody.
Lets visitors browse published articles without leaving the chat. You choose where the entry point appears, the bottom bar label and icon, and whether to offer a link to the full help centre. Off by default.
Star rating triggered when an agent closes the chat, when a handoff ends, or after an inactivity period you set. Pick one or two triggers, not all of them.
A short survey when the visitor closes the chat, with your question, delay, timing rule and a cap per visit. Visitors can also email or download the transcript. One question gets answered; three do not.
A follow-up survey by email after the conversation ends, optionally in the language the visitor chatted in, with control over delay, subject, intro, question, both button labels and the thank-you line.
Thumbs up and thumbs down on each AI answer, feeding the quality dashboards.
Auto-archive after days, auto-resolve after minutes of silence, and delete archived conversations after days. A third place retention is set, alongside General and Tracking.
What the assistant actually knows. Nothing else in Client Chat matters as much.
Crawls your site so the assistant can answer from it. Up to ten starting links, a page limit, a link depth, and excluded folders. A single URL can be tested before the full crawl. Exclude checkout, account and admin paths.
The API key and model that turn pages into searchable meaning rather than keyword matches.
One click and the AI reads every FAQ and crawled page and sorts them into categories.
Question and answer pairs treated as the highest priority source, each with a status, weight and category. Searchable, importable from JSON, and the AI can write them from a description of your business. When the assistant gets something wrong, write an FAQ: it outranks crawled pages, so the fix is immediate.
Polling interval, message rate limit and window, maximum attachment size, attachment attempts per window, and allowed file extensions. The extension list is a security control; keep it tight.
Instant message and status delivery instead of polling, through Pusher, Ably or Firebase, with a fallback polling interval. Polling is fine for most sites.
Device alerts for agents through Pusher Beams or OneSignal, with a device interest.
Browser push using your own generated keys with no third-party provider. Generated here, not in Danger Zone.
TURN credentials so calls connect through restrictive networks, using Cloudflare or Twilio credentials or your own TURN URL, username and credential.
Agent workspace settings rather than visitor settings: first-response SLA in minutes, saved queue views, keyboard shortcuts and the command palette, in-conversation search, and customer tickets in the inspector.
WhatsApp, SMS, Facebook Messenger, Instagram, Telegram, X direct messages and LINE, each with its own AI auto-reply switch, plus a policy switch for AI actions on channels, a reply debounce and the WhatsApp re-engagement template. Every channel lands in the same inbox as web chat.
Tickets answered in writing: automatic replies, the native ticket system, escalation, business hours, routing and the customer-facing emails.
Adds the writing helper buttons for your agents in the admin.
Queues new tickets and replies and answers them after a delay. Start with it off and review drafts for a week. Refunds, cancellations and access changes should always reach a person.
Which departments auto-reply may answer in. Anything not listed is left for a human, which is the safe default.
How long to wait before the automatic reply sends. An instant reply reads as a robot; a few minutes reads as a fast team.
A per-department cap, for example Billing 1 and Support 3. Without a cap a confused thread can loop.
Maximum writing tokens, the ticket status after a reply and after an escalation, and which admin account the automatic replies are attributed to. Use a clearly named account so staff can tell AI replies from human ones.
The ticket system built into OpsIQ, for installs without an external helpdesk.
Turns incoming email into tickets. OpsIQ supplies the endpoint URL, auth token, script path and PHP binary. Anything that can post to that endpoint can create tickets, so keep the token secret.
Whether the AI keeps replying as the conversation continues, and whether it waits a quiet window so three quick messages get one considered reply. The quiet window is the best single setting for making automated replies feel considered.
A customer-facing page where anyone can raise and track a ticket, with an optional welcome line. Its address and look are configured in the Support Portal tab.
How many random letters appear in generated ticket numbers.
Ticket emails follow the customer language. Staff email never changes language: notifications, department alerts, briefings and scheduled reports stay in your system language.
A fixed acknowledgement on new tickets, plus confirmation messages when a ticket is opened, when feedback is left and when a ticket is closed, each with a live preview. There is also a global email template wrapper and the link behind the view your ticket button.
Screens tickets from unknown senders, and can optionally move suspected spam on its own. Leave the automatic move off until you have watched its judgement.
Closes a ticket after a number of quiet days. Tell the customer in the closing message how to reopen.
Timezone, opening and closing times, working days and holidays for first-reply and resolution timers. A separate schedule from the Working Hours under Client Chat.
Automatic assignment, optionally only to agents who are online, with agent skills and a match sensitivity for skill-based routing.
Spots when a customer opens a ticket close to one they already have, with an adjustable match sensitivity.
Emails a survey a day after closing. Results appear on the CSAT page.
Emails the department when a new ticket arrives. Recipients are the members of that department, not the department mailbox address, which is the inbound address tickets arrive on.
A master switch plus individual read-only permissions for the client profile summary, invoices, transactions, credit balance, products and services, domains, linked servers and a high-level account overview. Start with the profile summary and add categories as replies need them.
Moves a ticket to a better-suited department before answering. You choose the allowed departments, the check delay, and can write your own escalation notice instructions. Turn on the internal escalation note so your team can see why a ticket moved.
Whether replies use the customer language, whether they draw on crawled links and FAQs, whether the AI reads image and PDF attachments, the knowledge reply mode, whether imported JSON knowledge is used, and whether source links may appear. Use crawled links and FAQs should be on, or the AI is guessing.
Once staff reply, the AI stops answering that ticket. Without it the AI can talk over your own agent.
Free-text instructions shaping tone and content for every reply, with a loadable worked example. Be specific about what the AI must never do.
Upload or paste a JSON knowledge file for the writing assistant.
A full designer for the customer-facing button: display style, size, label, icon, shape, minimum width, background style with primary and secondary colours, gradient angle, border, corner radius, shadow, typography, padding, idle animation, hover motion and colours, and the focus ring, plus a custom CSS box for anything the controls do not cover.
The customer-facing site where people raise and track tickets and read your help articles. This tab controls how it is reached and how customers sign in; its visual design is done in the Support Portal Studio.
These are two different products and people mix them up constantly. They solve different problems, and running both together is normal.
The Studio designs a complete support site that OpsIQ hosts for you. It has its own web address, or your own domain, and it carries the whole self-service experience: help articles with search, the request form, ticket history, customer sign-in and the assistant. Pick a template, work through Theme, Navigation, Layout, Knowledge, Footer, Brand, Tickets, Assistant, Form and CSS, preview at desktop, tablet and phone sizes, then publish.
Use it when you want one branded destination you can point every customer at, and you would rather not build or maintain a support area inside your own website.
The embed puts only the ticket experience on a page of your own website. Customers open, track and reply to support requests without ever leaving your pages, and your own header, navigation and design stay exactly as they are. Set the layout, appearance and access rules in the widget builder, preview the result, then copy the embed snippet into your page.
Use it when you already have a website or application with its own design, and you want support to happen inside it rather than handing the customer off to a different address.
The Studio builds a place you send customers to. The embed brings tickets to where your customers already are. Many businesses run both, embedding the ticket widget in their account area for in-context requests while keeping the hosted portal as the full self-service destination with articles and search. They are independent switches.
Whether the portal is open to anyone or restricted to signed-in customers. Open portals get more tickets and more spam.
Whether the portal and help centre share one hero or use two, which navigation and footer appear on both surfaces, and the navigation section label.
The address customers use. Pick a name and OpsIQ shows the resulting portal and matching help centre addresses. Changing it later breaks links you have already sent.
Serves the portal from a domain you own, such as support.yourdomain.com.
Switches on the drop-in widget described above, and opens the embed builder where you choose the layout, appearance and access rules, preview the result and copy the snippet for your page. This is not the Portal Studio: the Studio designs the hosted portal, this puts tickets inside your own site. Both can be on at once.
These are your customers sign-in options. Staff sign-in is configured under Settings, Security.
Which options appear on the sign-in page. Connector and email sign-in work automatically.
Consumer account providers, each needing a client ID and secret, with the redirect address supplied by OpsIQ to register with that provider.
Customer sign-in through an identity provider, with issuer URL, client ID, secret and an optional allowed email domain list.
The SAML equivalent. OpsIQ supplies the ACS reply URL and SP entity ID; you supply the IdP entity ID, sign-in and sign-out URLs, X.509 certificate and optional attribute names. Turn SAML on in Sign-in methods or it will not appear.
A signed deep link so a customer already signed in to your application lands in the portal without signing in again. OpsIQ supplies the signing secret, portal URL and workspace key, plus a generator for a signed test link. Use the generator before writing any code.
Signing out of the portal also signs the customer out of your application.
Which structured fields the request form collects. Every extra field loses submissions, so ask only for what you need to triage.
A honeypot and rate limiting always protect the public form. On top you can block disposable email addresses, add your own blocked domains, and add a CAPTCHA using Google reCAPTCHA or Cloudflare Turnstile. reCAPTCHA reuses the keys already set under Settings, Security; Turnstile keys are entered here.
A read-only summary of portal activity over the last thirty days.
The System group, plus the team access controls that decide who can see which Settings tab.
Each admin gets an explicit set of permissions covering chat inbox access, which Settings sections they may edit, and their departments. Anyone with the Full Administrator role always has every permission. Settings permissions decide which tabs a person sees, so grant the narrowest set that lets them work.
Shows your current licence, what it entitles you to and its status.
Self-hosted installs only. On the OpsIQ cloud the scheduled tasks run for you and the tab is hidden. One line of crontab drives every scheduled task: ticket auto-reply, escalation routing, exchange-rate refresh, mailbox polling and connector sync.
The tab shows the exact crontab line for your server with the correct PHP binary already chosen.
Run crontab -e as the user that runs PHP and paste the single line. On cPanel use the Cron Jobs tool instead.
Within a minute the heartbeat tiles light up. Use Run now to test immediately rather than waiting.
The heartbeat panel shows the last run, duration and what was processed for both the auto-reply queue and the email and connector poll. It warns when the last run came from the manual web button rather than a real server cron, and when a heartbeat has gone stale.
Wipes everything OpsIQ collected or generated. You tick what to include and type the confirmation phrase exactly. Settings and site configuration, blocked addresses, everything your team wrote (knowledge base, FAQs, translations, portal designs, action definitions) and consent receipts are all preserved.
The same sweep limited to records older than 30, 60, 90 or 180 days, or a year. For automatic rolling retention use the retention values in General and Tracking instead and let the scheduled task do it.
Invite team members and assign roles to control who can access what.
Full access including license, billing, and danger zone. One per installation.
Full access except license and danger zone. Can manage admins.
Limited to assigned departments. Tickets, chats, and analytics only.
Navigate to Team in the sidebar.
Enter the team member's email.
Choose Owner, Full Admin, or Agent.
For Agents, select accessible departments.
They receive an email with a setup link.
How your support team is performing. Access is by permission, not by role: the view permission opens the page, the manage permission unlocks targets, QA and the colleague-identifying reads, and the reward-financials permission is what adds the Rewards tab. A team lead can be given any of these without becoming a full administrator.
Team Performance is five tabs. Each answers a different question, and they are ordered by how urgently they usually need you.
Live queue state, customer outcomes against your targets, how capacity was spent, situations needing a decision, and the evidence-adjusted per-teammate index.
The leaderboard, recognition (most improved and streaks), quests, and the opt-in control for who may see the ranking.
Scorecards, recorded evaluations, chance-corrected reviewer agreement, reviewer drift, and evidence disputes.
Token value, payout claims, and the governed period allocation: authorise a funded ceiling, review the preview, finalise.
How the workspace has moved over time: trend metrics with a chart, and a 28-day coverage heatmap showing when the team was actually working. Each card hides itself until there is enough history to draw it.
A teammate without enough handled volume — or whose dimensions carrying evidence add up to less than half the configured weight — is shown as Unscored. Their score, rank and band are empty and their breakdown is hidden. This is deliberate: rendering an absent measurement as a zero puts someone at the bottom of a ranking for having a quiet week. Evidence thresholds are configurable per workspace in Targets & scoring.
The two evidence thresholds do different jobs and it is worth keeping them apart. Minimum handled decides whether someone is scored at all. Minimum ratings does not affect the score: it decides award and reward eligibility. So a teammate can be fully scored and ranked and still be ineligible for that period, because too few customers rated them.
A composite of five dimensions, each measured against a target you set rather than against colleagues, then pulled towards the middle when the evidence behind it is thin. Note the direction: the adjustment moves the figure towards 70, so a thin excellent score is pulled down and a thin poor score is pulled up. A bad first week on four conversations is not a settled verdict either. As evidence accumulates the adjusted figure converges on the raw one.
Customer satisfaction from verified feedback. Supplemented by QA scorecard results where those exist and are governed.
First response times at the P50 and P90 percentiles, against your targets.
Resolution time and one-touch resolution rate.
Attainment against the SLA you configured, plus at-risk and breached counts.
Reopen and transfer rates — the work that comes back.
Occupancy, productive time, solved per productive hour and online share of the window. Utilisation is deliberately not reported: it needs scheduled hours as a denominator, OpsIQ has no roster or shift source, and a substituted denominator would be a guess wearing a percentage sign. It reads as unavailable with that reason attached.
A scorecard is the rubric reviewers score real conversations against. Only a published version can receive an evaluation, and publishing a new version never rewrites what was already scored. A review is evidence about one conversation, not a verdict on a person.
Reported as a chance-corrected statistic (Cohen's and Fleiss' kappa), not a raw agreement percentage. Two reviewers who pass everything agree 100% of the time while carrying no information.
Whether a reviewer scores systematically harder or softer than their colleagues on the same conversation — a comparison against the rest of the panel, not a trend over time. It needs an interaction reviewed independently more than once.
A teammate can formally dispute evidence recorded about them. An open dispute blocks reward-period finalisation until it is resolved.
Refused. A teammate cannot submit an evaluation of themselves.
Ranking alone has documented failure modes: metric gaming, burnout, and public shaming of whoever is last. Three alternatives sit alongside it.
Measured against a teammate's own earlier record, never against colleagues, with shrinkage so a tiny denominator cannot buy a win.
Consecutive periods meeting a fixed, declared bar — average rating, handled volume, ratings count and negative-feedback rate, all absolute figures. Everyone can hold a streak simultaneously, so it creates no ranking, and a colleague having an exceptional month cannot break yours.
Off by default. A teammate always sees their own index; whether they see colleagues is a workspace decision. Percentile bands can be published instead of absolute positions.
A target the team works towards, measured against a fixed declared bar rather than against each other — so everyone can clear the same quest in the same period.
Individual or team; one-off, repeatable, or seasonal with an explicit window.
Conversations handled, ratings received, active days, average rating, or negative feedback rate. All absolute — no metric whose value depends on what colleagues did.
Required on any quest with a volume target. Hitting the number while quality falls below the floor withholds the quest rather than completing it, and it is shown as withheld, not unfinished.
A per-period cap, driven by the slowest criterion, plus an optional cooldown before a repeat can count.
Shared progress with no per-teammate attribution published, so a team quest cannot become a leaderboard.
A coaching session is a record, not a chat. It has a coach, a teammate being coached, a scheduled time, agreed talking points, and a summary written afterwards. Real chats, tickets and QA evaluations are pinned to it as evidence, so the conversation is anchored to work that actually happened rather than to a remembered impression.
Agreed before the session, so the teammate is not walking into a surprise.
Chats, tickets and QA evaluations attached to the session. A pin stores a reference — a type and an id — not a copy, so it always points at the live record. OpsIQ does not verify the id before accepting it.
Each with an owner and a due date. An item past its date is shown as overdue — a derived state, not a status somebody has to remember to set.
The coach's own note. The teammate being coached can never read it — not as an agent, not as a manager, not as the owner. That check runs before every other permission and cannot be overridden.
The coach, the teammate, and anyone with the manage team performance permission. Nobody else, including other teammates in the same department.
Every create, update, pin, unpin and completion is recorded with what changed, by whom.
Recorded activity converts into tokens with a cash value you set. The path to a payment is deliberately slow and every step is recorded.
How many tokens equal how much money, and what each activity is worth.
For a closed calendar period, a full administrator states the maximum tokens it may pay. Saving the settings form does not authorise a budget, and it cannot alter a ceiling that has already been authorised.
Recipients, reserve, and the reason anyone is ineligible. Open evidence disputes block this step.
The allocation is recorded permanently with the evidence behind it. A period that allocated nothing can be voided and re-run outright. One that issued tokens must be reversed first: OpsIQ writes a compensating entry against each wallet and never deletes the original, so the ledger still shows what happened and why, and only then is the period released. The reversal refuses if anyone has already cashed out more than the amount being recovered, and names who and by how much.
Everyone else takes part by default, team leads and co-owners included. To leave someone out, open them in Team & Departments and switch off the Takes part in awards and rewards option. Their work is still scored and shown; they stop being a candidate from that point on, and nothing already finalised is touched.
The board, live state, capacity and quality overview for the workspace.
Targets and scoring, exports, QA scorecards and evaluations, coaching, quests, and the reads that carry colleague-identifying data such as per-admin history and award history.
Balances, cash values, claim notes and payment references — separated from performance evidence because it is payroll-adjacent.
Every money mutation: paying a reward, paying or rejecting a claim, authorising a budget, finalising, voiding or reversing an allocation, and setting the token-to-cash rate. These cannot be delegated by granting a permission.
The performance index is management evidence, not an automatic employment decision. Open the source conversations behind a number before acting on it, and weigh case complexity, schedules, leave and accessibility needs. A single difficult week looks nothing like a sustained pattern.
Sites (workspaces) let you manage multiple websites from one OpsIQ installation. Each has its own tracking, AI, connectors, and team access.
Navigate to Connected Sites.
Enter name, domain, and description.
Each site gets a unique key (site_xxx) for the widget snippet.
Each site has its own AI, connectors, and settings.
Depends on your license plan. Check your license details.
Your OpsIQ license controls features, site limits, and AI credit balance.
Enter in Settings > License. Validated against the OpsIQ licence server.
OpsIQ normally reads its signed local licence cache and refreshes validation when required. Use Force remote check when you need an immediate result; Diagnostics identifies DNS, HTTPS or server-time problems.
Determines feature availability and limits.
Maximum number of workspaces.
If using Managed AI, your credit balance is shown here.
Renew before expiration to avoid service interruption.
Tracking, tickets, and CRM continue. AI features pause until renewal. Data is preserved.
Each administrator can maintain their own identity, working preferences, password and two-factor authentication.
Profile settings belong to the signed-in administrator and do not change workspace branding. Use a unique password and enable two-factor authentication. Changing an email or authentication setting may require re-verification or a fresh sign-in.
Notification preferences control which operational events reach an administrator in the product or by email.
Preferences cover ticket assignment, customer replies, SLA warnings, chat handoff and AI approval events. Keep urgent operational signals enabled somewhere; turning off email does not necessarily turn off the in-app notification.
The Security Overview is the first screen for assessing blocks, login attacks, threat sessions, security trends and event integrity.
Use the headline cards for triage, then open the related Audit, Failed Logins, Blocked IPs or JavaScript Errors page for record-level work. The 14-day trend is more useful than a single spike. High-threat sessions should be investigated against visitor, request and authentication evidence before a permanent block is applied.
The audit log records who did what, when, to which object, at what risk level and whether it succeeded.
Filter by action, risk and actor; export CSV or JSON for an investigation. The hash chain helps detect missing or altered audit rows, but it does not replace protected backups and restricted database access. Treat audit exports as sensitive because they may identify users, records and security actions.
Diagnostics turns subsystem checks into plain-English health results and direct next actions.
The page checks Site Speed, rank/keyword/backlink/local data, AI and action gateway, tickets, crawler/audits, integration/event intake, background tasks, CRM automations, licence, widget and related product services. It intentionally reports operator-readable causes rather than exposing raw secrets.
After a change, Refresh and confirm the affected subsystem returns healthy. A green diagnostics page is necessary but not sufficient for launch; complete the Pre-launch checklist as well.
OpsIQ includes multiple security layers to protect your admin, data, and API access.
Email/password with optional 2FA.
Temporary lock after too many failed attempts.
Block IPs or CIDR ranges from accessing tracked sites.
Behavior-based threat scores. High-threat visitors can be auto-blocked.
Required for all connections. HTTP redirects to HTTPS.
Strict-Transport-Security prevents downgrade attacks.
All admin forms include CSRF tokens.
All user input is escaped. CSP headers restrict script execution.
Outbound webhooks block private/internal IP addresses.
For all admin accounts.
Minimum 12 characters, mixed.
Remove access for former team members.
Check weekly for suspicious patterns.
Apply updates promptly for security patches.
Role-Based Access Control lets you control what each team member can do.
Everything including license, danger zone, and installation management.
Everything except license and danger zone. Can manage team.
Respond to assigned-department tickets and chats, view analytics. No settings, team, or security access.
Not currently. Three built-in roles plus department assignment gives granular control.
Manage IP addresses blocked from accessing your tracked sites.
Example: 203.0.113.42 or 203.0.113.0/24
Document why: spam, abuse, scraping, etc.
If customers share a corporate IP or VPN, blocking that IP blocks everyone on it. Use narrow blocks.
All unsuccessful login attempts to your OpsIQ admin.
When the attempt happened.
Email address used.
Source of the attempt.
Geographic location.
Wrong password, locked, or not found.
Password guessing. Ensure 2FA is enabled.
Automated attack. Block the source IP.
If your team is local, foreign attempts are likely attacks.
An opt-in analyst layer over the Security pages: verdicts, incident briefs, a daily digest, a weekly posture check, Ask Security, and 0-token block policies. It never runs in the visitor request path.
Every Security page records what happened, but reading it still takes judgment. The AI security analyst adds that judgment in place, and it is built to spend almost nothing: it never sits in the beacon or login path, deterministic rules settle the obvious cases with no AI call, verdicts are cached, and the analyst's best output is a deterministic rule that then enforces forever at zero tokens. Turn features on in Settings → Security; all default off.
Blocked IPs and Failed Logins rows show a benign / suspicious / hostile chip with a confidence score. Explain opens the reasoning, the facts used, and one-click Block / Release actions. Cached 24h, so re-viewing an IP is free.
Related events cluster into one incident (login wave, URL scan, auto-block burst) with a plain-English timeline and one recommended next step. Ongoing attacks fold into the same incident.
One recap per day: yesterday versus your baseline, blocks, incidents, and the single thing to do. Quiet days send a deterministic all-clear at zero tokens.
A Monday hardening checklist (2FA gaps, lockout threshold versus real attack volume, alerts off) with a severity, effort and exact fix per item.
A question box on the Security Overview that answers from your live security state. Deep server questions are handed to the admin engineer chat rather than guessed.
The analyst proposes concrete block rules as Approve / Dismiss cards; approved rules enforce at zero tokens with a live hit counter. Optional autopilot approves only the safest rules automatically.
Master switch. Enables verdict chips, Explain, and Ask Security. Only ambiguous IPs reach the model, batched into one call.
Clusters events into incidents and writes each new story. Runs on the existing hourly security cron.
One security recap per day on the bell and the Overview. Quiet days cost nothing.
Monday hardening checklist on the Overview. The checklist is fully deterministic.
Lets the analyst activate its safest proposals unattended: reversible time-limited blocks only, single IPs or ranges no wider than /24, never shared/mobile/private, capped 10 per hour, always audited and undoable.
OpsIQ uses one product scheduler to run email polling, ticket automation, analytics rollups, retention, AI queues, CRM work, reports and connector jobs.
Add this single line to the crontab for the same server and PHP environment that runs OpsIQ:
* * * * * php /path/to/opsiq/opsiq/cron/all.php >> /tmp/opsiq-cron.log 2>&1
Replace /path/to/opsiq with the installation root. Use the full PHP CLI path when the host requires one, for example /usr/bin/php8.4.
Do not use the top-level /cron.php for product work. In this repository that runner belongs to a separate non-product service outside this handbook. The OpsIQ product runner is opsiq/cron/all.php.
Processes due auto-replies, escalations, approvals and other queued product work.
Polls configured mailboxes where polling is the selected intake method.
Assembles sessions and refreshes scheduled aggregates when they are due.
Runs scoring, lifecycle, workflow, campaign and scheduled-report tasks that are enabled.
Performs due cleanup, archive, expiry and integrity work.
Dispatches connector cron subscribers and polling only for installed, enabled and configured connectors.
/tmp/opsiq-cron.log or the log path you selected when a manual run fails.Keep connector handlers short, idempotent and workspace-scoped. Batch long synchronisations and store a cursor/checkpoint so the next run can continue safely.
A hosted OpsIQ deployment uses the same product screens and workflows while the hosting operator manages the server layer. Commercial sign-up, plans, billing and account-portal procedures are outside this handbook.
Do not assume that a managed service means every product integration is healthy. Confirm the latest backup evidence and retention policy with the hosting operator, and use OpsIQ Diagnostics after changes to DNS, email, AI providers, websites or connectors.
This section covers product operations only. Commercial onboarding, subscriptions, billing and customer-account administration remain outside the OpsIQ handbook.
A self-hosted OpsIQ installation runs on infrastructure you control. You are responsible for the runtime, database, TLS, product cron, backups, updates and monitoring.
PHP 8.4 or newer. Required extensions: curl, pdo_mysql, mbstring, json, xml, openssl, zip, intl and gd.
MySQL 5.7+ or MariaDB 10.3+ using InnoDB. Create a dedicated database and least-privileged application user.
Apache or Nginx configured for the OpsIQ front controller, static assets and required rewrites.
Required for admin sessions, widget traffic, API keys, webhooks and provider calls.
Allow DNS and HTTPS access to the AI, email, connector and licence endpoints you actually enable.
The web and CLI users must be able to read application files and write only to the documented runtime/storage locations.
Run the OpsIQ product scheduler every minute with the same application configuration and database access as the web process.
* * * * * php /path/to/opsiq/opsiq/cron/all.php >> /tmp/opsiq-cron.log 2>&1
Checklist and best practices for running OpsIQ in production.
SSL installed, HTTP redirects, HSTS enabled.
Verify via diagnostics page.
Chat as a customer. Verify accuracy and tone.
On all website pages. Verify with Live Feed.
Automated daily database and file backups.
PHP error log enabled and monitored.
All members have accounts with correct roles.
At least 5-10 articles.
Run the source gates and complete real product checks before a release or first production launch. A command being available is not evidence that it passed in your environment.
Run the repository checks from the installation root and keep their complete output with the release record.
php tools/preflight.php
php tools/release_gate.php
The preflight checks the PHP 8.4 runtime and required extensions, performs a PHP syntax sweep, runs the AI evaluation ship gate and full PHPUnit suite, and runs PHPStan/Node checks when those tools are installed. The extended gate also includes smoke, clean-install/schema and browser end-to-end checks when their environment is configured.
A skipped check is not a pass. Record why it was unavailable, install the missing dependency or run it in the correct CI/staging environment before release.
Sign in as each intended role; verify allowed and denied pages/actions.
Load a real site in a private browser; verify beacon traffic, Live Feed, visitor and session records.
Ask representative questions; verify knowledge grounding, safety, escalation and AI history.
Create, assign, reply, escalate, close and reopen through every enabled intake path.
Test outbound delivery and each configured inbound mailbox or webhook path.
Create a controlled contact/deal/conversion and verify dashboards, funnels, scoring and reports.
Run connection tests, one read, one safe write/dry run and webhook/polling paths for each enabled connector.
Verify narrow scopes, rate limits, idempotent retries, signatures and duplicate handling.
Run the unified product scheduler and confirm all required heartbeats in Cron Setup/Diagnostics.
Verify 2FA, CSRF/session controls, audit entries, key revocation and workspace isolation.
Restore a current backup into a separate test environment and verify data and configuration.
Confirm logs/alerts, preserve request IDs and prove the rollback procedure.
Browser push notifications (including OpsIQ Push Campaigns) need a service worker served from the SAME ORIGIN as the page. The OpsIQ widget loads from your OpsIQ deployment, so a third-party site cannot register OpsIQ's worker directly. Host one small file on the site's own domain to enable push there. Campaigns deliver through BOTH supported methods.
Browsers only let a page register a service worker from its own origin. The widget loads cross-origin from your OpsIQ deployment, so it cannot install the push worker on a customer site, until you host the worker on that site's origin, the widget silently skips push (no error, no subscription). You have two options below; OpsIQ Push Campaigns publish through both.
1. Download the worker from your OpsIQ deployment: https://YOUR-OPSIQ/opsiq/opsiq-push-sw.js
2. Upload it to your web root so it is reachable at https://yoursite.com/opsiq-push-sw.js. The widget auto-detects this path on the page's own origin and registers it, no snippet change needed. (It uses a narrow scope, so it never replaces a service worker you already run.)
Optional: if you must host it at a non-standard path, point the widget at it before the snippet. It is only accepted when same-origin:
<script>window.OpsIQ=window.OpsIQ||{};window.OpsIQ.pushSwUrl="/custom/opsiq-push-sw.js";</script>3. In OpsIQ, generate VAPID keys (Settings → Client Chat AI → Advanced → Web Push). The widget then asks visitors for notification permission and subscribes them.
/opsiq-push-sw.js returns HTTP 200 (purge the cache if it was 404 before you uploaded; a cached 404 will block registration).1. In OpsIQ settings set the push provider to Pusher Beams and enter your Beams Instance ID and Secret Key.
2. Host the Beams service worker on the site's root as /service-worker.js. Copy https://YOUR-OPSIQ/opsiq/pusher-beams-service-worker.js, or merge this line into your existing root worker:
importScripts("https://js.pusher.com/beams/service-worker.js");3. That's it. The widget auto-loads the Beams SDK and subscribes each visitor to the per-site interest opsiq-site-<your-site-key>. No other wiring needed.
Push Campaigns publish through both methods at once: visitors on the self-hosted VAPID worker get the encrypted Web Push, and visitors subscribed via Pusher Beams get the Beams publish. Each visitor is reached through whichever they subscribed to, so you can run same-origin VAPID on some sites and cross-origin Beams on others.
HTTPS is required for service workers and Web Push (localhost is exempt for testing). The admin chat inbox already uses the same Beams interest mechanism for operator alerts.
Common issues and how to fix them.
Check PHP error logs. Causes: old PHP (need 8.4+), missing extension, DB connection failed, wrong file permissions.
Check: widget installed? Cron running? Date range correct? IP excluded?
Check: provider configured? API key valid (use Test connection)? Budget exhausted? Workspace AI config correct?
Check: knowledge base up to date? Prompt clear? Connector lookups returning correct data? Review conversation in AI History.
Depends on: provider API speed, context size (large KB = more tokens = slower), network latency. Try a faster model.
Check: script in page source? JS errors in console? CSP blocking? Ad blocker?
GeoIP not configured. Use Cloudflare (automatic) or MaxMind GeoLite2 database.
Check: mailbox connected? Cron running? App password changed? IMAP settings correct?
Check: enabled? Department allowed? AI configured? Cron running? Human replied first?
Check: credentials correct? Key expired? API accessible from server? Base URL correct?
Check: API key scopes? Webhook sync enabled? Cron running?
Check: database performance (SHOW PROCESSLIST), PHP memory (increase to 1GB), enable opcache, reduce retention period.
Use this focused check when the widget loads incorrectly or Live Feed stays empty.
When the widget is not logging visits, verify the site key, load the page in a private browser, check the browser Network/Console panels for blocked beacon or widget requests, review Content-Security-Policy and ad blockers, confirm the site is active in OpsIQ, and open Diagnostics. A visible chat bubble does not by itself prove that the analytics beacon was accepted.
Definitions for terms used throughout OpsIQ.
Something the AI can do through a connector or the platform.
A team member with limited access, or an AI agent.
Bring Your Own Key, you provide your own AI API key.
A plugin integrating an external platform with OpsIQ.
Customer Satisfaction score.
A revenue opportunity in the CRM.
A ticket category for routing and access control.
Moving a ticket to a different department or from AI to human.
Visitor location detection from IP address.
Transferring a conversation from AI to human.
Signed token identifying a website visitor.
Articles the AI uses to answer questions.
A visitor showing buying intent.
0-100 number indicating conversion likelihood.
Where a customer is: Lead, Prospect, Customer, At Risk, Churned.
AI provided as part of your OpsIQ plan.
Visual board of deal stages.
Role-Based Access Control.
A series of page views within a timeout window.
Unique identifier for a tracked website.
Service Level Agreement, target response times.
Unit of AI text. Roughly 4 characters = 1 token.
Safety system controlling AI autonomy.
HTTP callback for event notifications.
JavaScript code embedded on your website.
A site with its own tracking, AI, connectors, and team. Same as "site."
If this documentation does not answer your question:
Click "Ask OpsIQ" in the admin. Has access to this documentation and your platform data.
Include: what you tried, what happened, what you expected, and any error messages.
Email support with your license key and issue description.
Which admin page (URL or name).
Exact setting name and current value.
Exact error message with codes.
What you did, step by step.
What should happen vs what did happen.