Free plan first

The system supports a free-plan onboarding path. A user can start without entering a credit card during account creation, and the account is taken to the dashboard after registration instead of being blocked at checkout.

What happens after registration

Once the account is created, the customer workspace becomes the home base. From there, users can open CRM setup, request leads, view subscription status, and manage their profile and settings.

When a paid plan is needed

Paid plans are managed separately through the checkout and billing flows. Users can browse packages, activate a free plan when available, or move into Stripe or PayPal checkout for paid subscriptions.

The five setup steps

The current form is structured in five stages: business basics, business description, pricing details, differentiators, and customer journey. Each step is saved into the client profile and contributes to setup completion.

Attachments and reference links

Pricing, differentiators, and customer journey steps support both file attachments and reference links. This lets a client give the system richer context than plain text alone.

Progress and completion

The dashboard and sidebar expose CRM completion state so users can see whether setup is still pending or ready for review. The goal is to finish CRM setup before leads begin arriving.

Workspace summary

The top summary cards show total leads, lead requests, active orders, and current workflow status. That makes the dashboard the fastest place to check whether lead delivery and automation setup are moving correctly.

CRM and billing shortcuts

Customers can jump directly into CRM setup and billing management from the dashboard cards. CRM progress, profile completion percentage, and plan status are all visible without leaving the page.

Invitations and next actions

The dashboard can also surface account-manager requests, including social media account submission invitations. When those invitations are active, the dashboard provides a direct path to complete the requested submission.

Where requests can be submitted

Users can open the lead request modal from the dashboard, the sidebar lead menu, and the calendar page. Each request collects a platform, a location, and a requested number of leads.

Supported lead sources

The live interface lists Google Maps, Upwork, Reddit, and LinkedIn. Those labels are used consistently across the sidebar, dashboard actions, and calendar request modal.

What happens after submission

Lead requests are tracked in the dashboard and can be reviewed later from the lead workspace. This build does not present lead-source OAuth setup screens on the public docs page because the customer-facing flow is request-based inside the workspace.

Table tools

Users can search by name, email, phone, or company. Additional filters narrow the list by platform, source, and status. The table exposes lead status, score, assigned teammate, and created date.

Import and export

The workspace includes dedicated import and export actions. The backend also provides an import template download route, so importing lead data can follow the expected structure.

Lead detail activity

Each lead can have emails and activities attached to it through the authenticated customer endpoints. The UI already includes email history and activity tracking hooks for the lead detail workflow.

Inbox layout

The page is split into a thread list on the left and the active thread on the right. Customers can open a thread, read history, and post replies from the same screen.

Lead workspace connection

The inbox hero links back to the lead workspace, keeping conversations and CRM navigation connected rather than isolated in separate tools.

Reply flow

Replies are handled through the authenticated conversation reply route. From a documentation standpoint, this means customers can expect thread-by-thread messaging inside the dashboard, not a separate external inbox product.

Scheduling activities

The current UI lets a customer select a lead, confirm a time, and create a calendar activity directly from the workspace. Activity creation is wired to the lead activity store endpoint.

Lead-aware events

Events can link back to the related lead, so the calendar behaves as an extension of the CRM instead of a standalone availability tool.

Lead requests from calendar

The same page also exposes the lead request modal, which means customers can request new leads while planning follow-ups and scheduled work.

Supported payment methods

Stripe card checkout and PayPal checkout both exist in the current system. Stripe supports card entry through Stripe Elements, while PayPal remains available as an alternative payment tab when enabled.

Free plan activation

If a package is flagged as the dedicated free plan, the checkout page exposes an activation button instead of card entry. That path starts the free plan without asking for payment details.

Coupons and renewal choice

Coupon validation is built into checkout, and Stripe checkout can present a choice between one-time payment and auto-renewing billing when the package supports recurring payments.

Subscription summary

The billing portal shows the current package name, billing period, plan type, and renewal state. Free plans, recurring subscriptions, and one-time subscriptions are all presented differently so the customer can see which kind of plan they are on.

Cancellation behavior

The cancellation panel is built into the billing portal. Free plans can be cancelled without refund creation, while paid plans can trigger refund review messaging for admin follow-up.

Upcoming invoices

If the system has already generated the next invoice, the portal shows the upcoming amount and due date before the charge happens.

Statuses and metrics

The dedicated invoice screen summarizes pending, paid, and overdue counts along with the total amount paid. Each invoice row also includes billing period and package information.

Available actions

Customers can open invoice details, preview the PDF in a new tab, or download the PDF directly from the action buttons.

Where invoice history also appears

The billing portal includes an invoice history table with invoice numbers, amounts, due dates, statuses, and download actions.

Profile and contact information

The profile and settings pages expose editable name and email fields, along with profile-facing summary cards. Settings is the primary form for updating personal information.

Password changes

Password updates are handled from the settings page through a current password, new password, and confirmation form. The UI includes a visibility toggle for each password field.

Account deletion

The settings screen includes a destructive delete-account action with confirmation messaging. This permanently removes the account and should be treated as irreversible.

Provisioning triggers

Workflow cloning is dispatched after qualifying plan activation flows, including Stripe, PayPal, and onboarding-driven subscription creation when the package has a configured master workflow ID.

Customer-facing status

The dashboard already shows workflow status for the current customer. Typical states include active, cloning, pending, failed, or not set, depending on the package and provisioning result.

Why this matters in setup

CRM setup feeds context into the customer workflow, so business information entered during setup helps the downstream automation behave more accurately once the workflow is active.

Authentication model

Create a bearer token by posting email and password to the login endpoint. After that, send Authorization: Bearer YOUR_TOKEN with each API request. Logging out revokes only the current token.

Authentication endpoints

POST   /api/v1/auth/login
    GET    /api/v1/auth/me
    POST   /api/v1/auth/logout

Login payload example

POST /api/v1/auth/login
Content-Type: application/json

{
  "email": "client@example.com",
  "password": "password",
  "device_name": "Postman"
}

Login response example

200 OK

{
  "token": "1|sanctum_plain_text_token_here",
  "token_type": "Bearer",
  "user": {
    "id": 12,
    "name": "John Client",
    "username": "johnclient",
    "email": "client@example.com",
    "company_name": "Acme Growth",
    "industry": "SaaS",
    "phone_number": null,
    "is_active": true,
    "email_verified_at": "2026-05-14T13:30:00.000000Z",
    "created_at": "2026-05-14T13:30:00.000000Z",
    "updated_at": "2026-05-14T13:30:00.000000Z"
  }
}

Lead workspace endpoints

The public API exposes listing, creating, viewing, updating, importing, exporting, and downloading import templates for leads.

GET    /api/v1/leads
    POST   /api/v1/leads
    POST   /api/v1/leads/import
    GET    /api/v1/leads/import-template
    GET    /api/v1/leads/export
    GET    /api/v1/leads/{lead}
    PUT    /api/v1/leads/{lead}

Create lead payload example

POST /api/v1/leads
    Authorization: Bearer YOUR_TOKEN
    Content-Type: application/json

    {
      "name": "API Lead",
      "email": "api-lead@example.com",
      "phone": "+123456789",
      "company_name": "API Company",
      "website": "https://api-company.test",
      "industry": "SaaS",
      "status": "new",
      "source": "other",
      "lead_score": 64,
      "notes": "Created via public API."
    }

Create lead response example

201 Created

    {
      "message": "Lead created successfully.",
      "lead": {
        "id": 41,
        "user_id": 12,
        "name": "API Lead",
        "email": "api-lead@example.com",
        "phone": "+123456789",
        "company_name": "API Company",
        "website": "https://api-company.test",
        "industry": "SaaS",
        "status": "new",
        "source": "other",
        "lead_score": 64,
        "assigned_to": null,
        "converted_to_client_id": null,
        "converted_at": null,
        "notes": "Created via public API.",
        "custom_fields": null,
        "lead_request_id": null,
        "created_at": "2026-05-14T13:40:00.000000Z",
        "updated_at": "2026-05-14T13:40:00.000000Z"
      }
    }

Lead list response example

200 OK

    {
      "data": {
        "current_page": 1,
        "data": [
          {
            "id": 41,
            "user_id": 12,
            "name": "API Lead",
            "email": "api-lead@example.com",
            "status": "new",
            "source": "other",
            "lead_score": 64,
            "created_at": "2026-05-14T13:40:00.000000Z",
            "updated_at": "2026-05-14T13:40:00.000000Z"
          }
        ],
        "per_page": 15,
        "total": 1
      },
      "summary": {
        "total": 1,
        "new": 1,
        "contacted": 0,
        "won": 0
      }
    }

Lead request endpoint

Lead acquisition requests can also be submitted through the public API.

POST   /api/v1/lead-requests

Lead request payload and response example

POST /api/v1/lead-requests
    Authorization: Bearer YOUR_TOKEN
    Content-Type: application/json

    {
      "platform": "google_maps",
      "num_leads": 10,
      "location": "London"
    }

    201 Created

    {
      "message": "Lead request submitted successfully! We will process it shortly.",
      "lead_request": {
        "id": 7,
        "user_id": 12,
        "subscription_id": 4,
        "platform": "google_maps",
        "num_leads": 10,
        "location": "London",
        "status": "pending",
        "created_at": "2026-05-14T13:42:00.000000Z",
        "updated_at": "2026-05-14T13:42:00.000000Z"
      }
    }

Lead communication and activity endpoints

Lead detail endpoints also cover email history, sending emails, replying, and storing lead-linked activities.

GET    /api/v1/leads/{lead}/emails
    POST   /api/v1/leads/{lead}/emails
    POST   /api/v1/leads/{lead}/emails/reply
    GET    /api/v1/leads/{lead}/activities
    POST   /api/v1/leads/{lead}/activities

Common error response example

422 Unprocessable Entity

    {
      "message": "The email field is required. (and 1 more error)",
      "errors": {
        "email": [
          "The email field is required."
        ],
        "password": [
          "The password field is required."
        ]
      }
    }

Status codes used in this API

200 for successful reads and logout, 201 for created resources, 401 for unauthenticated requests, 403 for unauthorized resource access, and 422 for validation failures.

What remains internal

Checkout, billing, invoice payment, calendar rendering, workflow context, and scheduler endpoints remain internal web or operational interfaces. They are not part of the public bearer-token API surface yet.

Shared API setup

First create a Sanctum bearer token with the API login endpoint, then use that token from the website backend proxy. Keep this token server-side only.

POST /api/v1/auth/login
Content-Type: application/json

{
  "email": "client@example.com",
  "password": "password",
  "device_name": "Website Lead Capture"
}

Lead payload contract

The create-lead endpoint validates each lead against the customer account. Email addresses must be unique per customer, and status/source values must match the supported CRM options.

{
  "name": "Jane Carter",
  "email": "jane@example.com",
  "phone": "+1 555 0100",
  "company_name": "Acme Studio",
  "website": "https://acme.example",
  "industry": "Marketing",
  "status": "new",
  "source": "website",
  "lead_score": 64,
  "notes": "Submitted from website contact form"
}

Embed code for external websites

Clients can embed a lead form on any website. The browser form should post to a backend proxy on that website, and the proxy should forward the lead to Qonsistic. This keeps the bearer token out of public JavaScript.

<form id="qonsistic-lead-form">
  <input name="name" placeholder="Full name" required>
  <input name="email" type="email" placeholder="Work email" required>
  <input name="company_name" placeholder="Company">
  <input name="website" type="url" placeholder="https://company.com">
  <button type="submit">Submit</button>
</form>

<script>
document.getElementById('qonsistic-lead-form').addEventListener('submit', async function (event) {
  event.preventDefault();

  const form = event.currentTarget;
  const payload = {
    name: form.name.value,
    email: form.email.value,
    company_name: form.company_name.value || null,
    website: form.website.value || null,
    status: 'new',
    source: 'website'
  };

  const response = await fetch('/lead-proxy', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(payload)
  });

  if (response.ok) {
    form.reset();
  }
});
</script>

Backend proxy example

The proxy can be implemented in any backend language. The key requirement is that it reads the public form payload, adds the CRM defaults, and calls Qonsistic with the server-side bearer token.

<?php
$input = json_decode(file_get_contents('php://input'), true) ?: [];

$payload = [
    'name' => $input['name'] ?? null,
    'email' => $input['email'] ?? null,
    'company_name' => $input['company_name'] ?? null,
    'website' => $input['website'] ?? null,
    'status' => 'new',
    'source' => 'website',
];

$ch = curl_init('https://your-domain.com/api/v1/leads');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST => true,
    CURLOPT_HTTPHEADER => [
        'Authorization: Bearer ' . getenv('QONSISTIC_API_TOKEN'),
        'Content-Type: application/json',
        'Accept: application/json',
    ],
    CURLOPT_POSTFIELDS => json_encode($payload),
]);

$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

http_response_code($httpCode >= 200 && $httpCode < 300 ? 200 : 400);
header('Content-Type: application/json');
echo json_encode(['ok' => $httpCode >= 200 && $httpCode < 300]);

Security notes

Do not put bearer tokens in public HTML or browser JavaScript. Store them in a server environment variable or backend secret store, then forward only validated lead data to Qonsistic.

Authentication

Create a Sanctum bearer token with the API login endpoint, then configure the external system to send it in the Authorization header.

POST /api/v1/auth/login
Content-Type: application/json

{
  "email": "client@example.com",
  "password": "password",
  "device_name": "Webhook Integration"
}

Webhook request

External CRMs, form tools, automation platforms, and custom apps can treat POST /api/v1/leads as their webhook destination.

curl -X POST "https://your-domain.com/api/v1/leads" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "name": "Webhook Lead",
    "email": "webhook.lead@example.com",
    "status": "new",
    "source": "other",
    "notes": "Sent from partner system webhook"
  }'

Expected responses are 201 when a lead is created, 401 when the token is missing or invalid, and 422 when validation fails. If a sender retries webhooks, use the same email for the same logical lead so duplicate records are blocked by validation.

Supported lead fields

{
  "name": "Jane Carter",
  "email": "jane@example.com",
  "phone": "+1 555 0100",
  "company_name": "Acme Studio",
  "website": "https://acme.example",
  "industry": "Marketing",
  "status": "new",
  "source": "other",
  "lead_score": 64,
  "notes": "Sent from partner system webhook"
}

Plugin code

For WordPress sites, install a small connector plugin that stores the API base URL and token in WordPress settings, then exposes a shortcode form that posts leads into Qonsistic.

<?php
/*
Plugin Name: Qonsistic CRM Connector
Description: Sends WordPress form leads to Qonsistic CRM.
Version: 1.0.0
*/

if (!defined('ABSPATH')) {
    exit;
}

add_action('admin_init', function () {
    register_setting('qonsistic_crm_group', 'qonsistic_crm_base_url');
    register_setting('qonsistic_crm_group', 'qonsistic_crm_api_token');
});

add_action('admin_menu', function () {
    add_options_page('Qonsistic CRM', 'Qonsistic CRM', 'manage_options', 'qonsistic-crm', function () {
        echo '<div class="wrap"><h1>Qonsistic CRM Settings</h1>';
        echo '<form method="post" action="options.php">';
        settings_fields('qonsistic_crm_group');
        echo '<table class="form-table">';
        echo '<tr><th>Base URL</th><td><input type="url" name="qonsistic_crm_base_url" value="' . esc_attr(get_option('qonsistic_crm_base_url')) . '" class="regular-text"></td></tr>';
        echo '<tr><th>API Token</th><td><input type="password" name="qonsistic_crm_api_token" value="' . esc_attr(get_option('qonsistic_crm_api_token')) . '" class="regular-text"></td></tr>';
        echo '</table>';
        submit_button();
        echo '</form></div>';
    });
});

add_shortcode('qonsistic_lead_form', function () {
    if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_POST['qonsistic_submit'])) {
        $base = rtrim(get_option('qonsistic_crm_base_url'), '/');
        $token = get_option('qonsistic_crm_api_token');

        $payload = [
            'name' => sanitize_text_field($_POST['name'] ?? ''),
            'email' => sanitize_email($_POST['email'] ?? ''),
            'company_name' => sanitize_text_field($_POST['company_name'] ?? ''),
            'status' => 'new',
            'source' => 'website',
        ];

        $response = wp_remote_post($base . '/api/v1/leads', [
            'headers' => [
                'Authorization' => 'Bearer ' . $token,
                'Content-Type' => 'application/json',
                'Accept' => 'application/json',
            ],
            'body' => wp_json_encode($payload),
            'timeout' => 20,
        ]);

        echo !is_wp_error($response) && wp_remote_retrieve_response_code($response) === 201
            ? '<p>Lead submitted successfully.</p>'
            : '<p>Lead submission failed.</p>';
    }

    return '<form method="post">
        <p><input type="text" name="name" placeholder="Full name" required></p>
        <p><input type="email" name="email" placeholder="Work email" required></p>
        <p><input type="text" name="company_name" placeholder="Company"></p>
        <p><button type="submit" name="qonsistic_submit" value="1">Send</button></p>
    </form>';
});

WordPress setup checklist

Security notes

Store the bearer token only in the WordPress admin settings. Rotate the token from Qonsistic if it is exposed or if an administrator who had access leaves the project.

Public API is now available for core lead operations

The app now exposes a real bearer-token API under /api/v1 for login, user identity, lead requests, leads, lead emails, and lead activities. Broader billing and workflow interfaces still remain internal-only for now.

Two-factor authentication is not active

The profile UI currently shows a two-factor block, but there is no live backend implementation, route flow, or user-table support for real 2FA in this build. Customers should rely on password security until that feature is implemented properly.

Additional customer request flows

This codebase also includes customer-facing request flows for custom work and social media submissions. Those flows are available from their dedicated pages or dashboard invitations when enabled, but they are supporting workflows rather than the main CRM navigation described above.

Support and next steps

For plan questions, CRM setup help, invoice issues, or workflow failures, use the contact page. For plan browsing or upgrades, use the packages page or the upgrade links inside the customer workspace.