Integrations and developer tools

Orders sync on checkout, status change, admin edit and refund, idempotently, so re-syncing never duplicates. Each order becomes two things at once: a ledger record with order number, status, total and currency, item count, payment method, billing country, created and paid dates and every line item; and a deal in an auto-created Orders pipeline whose stages mirror WooCommerce statuses, with completed counting as won and cancelled or refunded as lost.

Customers become contacts carrying lifetime value and configurable RFM segments, and a one-click batched backfill imports your existing order history. See the WooCommerce page for the full behaviour.

If your storefront is not WooCommerce — Shopify, a headless cart, a custom checkout — post a normalised order payload to the token-protected order intake endpoint at /stillpoint-crm/?page=ecom_intake. Orders arriving this way behave like synced orders: ledger record, deal in the Orders pipeline, contact with lifetime value and RFM segment.

{
  "wc_order_id": 10482,
  "status": "completed",
  "total": 249.00,
  "currency": "USD",
  "customer_email": "ada@example.com",
  "items": [
    { "name": "Annual licence", "sku": "SP-PRO-1Y", "qty": 1, "price": 249.00 }
  ]
}

curl -X POST "https://example.com/stillpoint-crm/?page=ecom_intake" \
  -H "Content-Type: application/json" \
  -H "X-Stillpoint-Token: YOUR_INTAKE_TOKEN" \
  --data @order.json

Two options, depending on whether you are wiring from outside or inside WordPress. From outside, POST to the token-protected lead intake endpoint at /stillpoint-crm/?page=intake.

curl -X POST "https://example.com/stillpoint-crm/?page=intake" \
  -H "Content-Type: application/json" \
  -H "X-Stillpoint-Token: YOUR_INTAKE_TOKEN" \
  -d '{"name":"Ada Lovelace","email":"ada@example.com","phone":"+27 21 555 0100","message":"Pricing for 4 seats?","source":"Contact form"}'

From inside WordPress, call the PHP helper from any form plugin's submission handler — Contact Form 7, WPForms, Gravity Forms, Fluent Forms or your own theme code. No token needed, because you are already in the application.

add_action( 'wpforms_process_complete', function ( $fields ) {
    if ( ! function_exists( 'stillpoint_crm_capture_lead' ) ) {
        return;
    }

    stillpoint_crm_capture_lead( array(
        'name'    => $fields[1]['value'],
        'email'   => $fields[2]['value'],
        'message' => $fields[3]['value'],
        'source'  => 'WPForms — contact page',
    ) );
}, 10, 1 );

Captured leads are scored and can be routed round-robin to an owner, so an inbound enquiry lands on someone's board rather than in a shared inbox.

Register a URL per event and Stillpoint fires an HTTP request when that CRM event happens — a deal created, a deal moving stage, an invoice paid. That is enough to push into anything that accepts an inbound request: Slack, a data warehouse loader, an internal service, or an automation platform's catch hook.

A token-authenticated GET endpoint for reporting and dashboards: /stillpoint-crm/?page=api&type=deals|contacts|companies&token=…. Point Google Sheets, Looker Studio, Metabase or a spreadsheet import at it and you have live CRM reporting without exporting anything by hand.

curl "https://example.com/stillpoint-crm/?page=api&type=deals&token=YOUR_API_TOKEN"

To be explicit: this API is currently read-only. There are no write endpoints yet, so you cannot create or update records through it. A write API is the first item on the roadmap. Until it lands, writes come in through the intake endpoints above.

A native bridge to FluentCRM syncs contacts both ways and applies tags on sales events — a deal marked won or lost, or a customer's RFM segment changing after a purchase — so a FluentCRM journey can react to what actually happened in the pipeline or the store, not just to a form submission. Engagement flows back too: opens, clicks and journey stage from FluentCRM show up on the CRM contact, so a rep can see who has been nurtured before they call.

This works alongside FluentCRM, not instead of it. Stillpoint still does not send bulk or broadcast email itself — FluentCRM (or another marketing tool) remains the thing that composes and sends the campaign. See marketing automation for how segments, journeys and consent fit together, and Stillpoint vs FluentCRM for category fit.

Marketing sends go out through a real transactional/bulk provider over SMTP — SendGrid, Mailgun, Postmark or Amazon SES — or through a capped direct SMTP connection for small lists, or by handing the send off to FluentCRM. Stillpoint does not operate its own outbound mail infrastructure, because reliable bulk delivery depends on reputation and infrastructure a single WordPress install cannot credibly provide.

Deliverability still comes down to your domain's authentication — SPF, DKIM and DMARC records — and keeping your spam-complaint rate under roughly 0.3%. Provider webhooks feed bounces and spam complaints back into the suppression list automatically, so an address that bounces hard or complains stops being mailed without anyone having to notice and act on it by hand. Full detail is on the marketing automation page.

A token-protected POST endpoint turns a public form submission into a work item on a board, with mapped fields carried across as item fields — a client request form that lands directly on the right board rather than in an inbox someone has to triage and retype.

curl -X POST "https://example.com/stillpoint-crm/?page=work_intake"   -H "Content-Type: application/json"   -H "X-Stillpoint-Token: YOUR_INTAKE_TOKEN"   -d '{"board":"Client requests","title":"New logo request","fields":{"Requested by":"Ada Lovelace","Due":"2025-01-01"}}'

See work management for boards, forms and the rest of the work item model.

Scheduled work — recurring work items, journey step timers, and campaign sends — needs WordPress cron to run reliably even when nobody is browsing the site. WordPress's default “pseudo-cron” only fires on a page visit, which is fine for small sites but unreliable for anything time-sensitive. Disable it and call the real cron endpoint on a schedule instead:

// wp-config.php — stop WordPress relying on page-visit "pseudo-cron"
define( 'DISABLE_WP_CRON', true );

# System crontab — hit wp-cron.php on a real schedule every 5 minutes
*/5 * * * * curl -s "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null 2>&1

Every five minutes is a sensible default; tighten it if you need journey steps or scheduled campaign sends to fire closer to their scheduled time.

Each user connects their own IMAP account for reading and SMTP for sending, with their own from-name and HTML signature. Because it is plain IMAP and SMTP, it works with Google Workspace, Microsoft 365, Fastmail or the mailboxes your host already gives you — no OAuth app to register and no provider-specific connector to wait for. Credentials are encrypted at rest with OpenSSL.

Honest requirement: reading the inbox needs the PHP imap extension enabled on your host. Without it, sending, templates and the sent log still work.

Needs your own credentials: you register an OAuth application in your own Google Cloud tenant and authorise the mailbox. Stillpoint stores a refresh token and never asks for your Google password. If you would rather skip the app-registration step, a Google app password over plain IMAP works immediately instead. Used for both the service desk and per-user team email — see email-to-ticket for the connector detail.

Needs your own credentials: an application registered in your own Microsoft Azure tenant, authorised for the mailbox by a tenant administrator. As with Google, IMAP remains available if you want to start collecting mail before that tenant admin work happens. See email-to-ticket for how this feeds the service desk.

Works out of the box — no app registration, no OAuth consent screen. Host, username and password is enough for a cPanel mailbox, Zoho, Fastmail, or a Google or Microsoft mailbox with an app password. TLS certificate verification is always on, with no setting to switch it off. This is the fastest route into both per-user team email and the service desk.

Needs an account and API key with the provider of your choice. For outbound, point your mailbox's SMTP configuration at the provider as a relay and your From address stays yours. For inbound support mail, the same three providers can be configured to post the raw message to Stillpoint's inbound webhook, which feeds email-to-ticket without touching a mailbox at all. Marketing sends use the same providers over SMTP — see marketing automation.

Needs your own AWS SES credentials. Configure your mailbox or marketing send adapter to use SES as an SMTP relay and Stillpoint sends through it like any other provider — there is no separate SES-specific setup inside the plugin beyond the SMTP credentials themselves.

Every user gets a tokenised ICS feed URL. Subscribe to it from Google Calendar, Outlook or Apple Calendar and CRM follow-ups and scheduled activity appear alongside the rest of the day, on the phone as well as the desktop.

CSV import and export for contacts, companies and deals; a per-contact GDPR export for subject access requests; and PDF export for quotes and invoices, generated inside the plugin with no third-party service in the path. Your data is never held hostage by a format.

Single sign-on is just the normal WordPress login — no second account system, no separate password. Access is controlled by the manage_stillpoint_crm capability, so your existing role editor decides who gets in, and CRM users are provisioned automatically from their WordPress account.