External systems can feed ASI. They do not get to become ASI.
Advanced Subscriber Intelligence uses a controlled integration model. WooCommerce remains the protected direct commerce module. Other external systems connect through the canonical ASI API.
Connected systems can submit useful subscriber, customer, commerce, campaign, consent, source, lifecycle, support, or account evidence. They can request approved actions and retrieve reporting results. ASI Core still decides what is accepted, held, rejected, validated, suppressed, queued, sent, classified, and reported.
The integration opens a controlled doorway into ASI Core. It does not create a second database truth, bypass the operator, mutate protected audiences directly, or wake the Freight Train on its own.
Canonical API for Other Systems
ASI Core Owns Truth
Protected Sending Only
Integrations submit evidence and requests. ASI Core makes the decisions.
A purchase, CRM stage, support ticket, audience file, campaign payload, customer status, or external instruction may be useful. None of those things automatically creates lawful permission, active eligibility, a sendable audience, or authority to start sending.
Two integration routes, one protected Core
WooCommerce is the deliberate direct-module exception. Other integrations use the canonical API contract.
WooCommerce
WooCommerce uses its existing protected direct pipe to provide store, order, product, customer, refund, coupon, consent, and related commerce evidence to ASI Core.
The individual WooCommerce module on-or-off control remains available. Turning the module on does not hand WooCommerce control of ASI truth or sending.
ASI API
Commerce platforms, CRM systems, payment systems, private applications, internal databases, and future integration surfaces use the same protected API contract.
The external dashboard or application may submit requests and display results. ASI Core remains the only place where subscriber, eligibility, campaign, sending, and reporting decisions become authoritative.
The connector never becomes its own decision engine.
SQL remains ASI’s permanent Truth Engine. Connected systems can contribute evidence, but they cannot create an alternative subscriber state, consent state, campaign state, or send state.
→
Woo Pipe or ASI API
→
ASI Core
→
Protected Review
→
Queue, Send, Report
Identity resolution
ASI Core resolves imported or connected identities against canonical subscriber truth rather than trusting the latest external record blindly.
Consent and suppression
External consent claims are evidence. Core compares them with source, jurisdiction, unsubscribe, complaint, suppression, and other protected records.
Eligibility and validation
Address quality, bounce state, provider holds, jurisdiction, list health, purpose, and campaign-specific eligibility remain ASI decisions.
Sending and reporting
Preflight, Queue Safety, provider pacing, queue creation, Freight Train movement, event capture, heuristics, and reporting remain inside Core.
Useful evidence and controlled requests.
The exact contract depends on the integration, but the external system remains a source of evidence or requests rather than the final authority.
Subscriber and identity evidence
Names, addresses, source identifiers, account references, customer relationships, and other mapped identity evidence.
Consent and source evidence
Consent flags, collection source, timestamp, jurisdiction, customer relationship, B2B documentation, and other supporting context where available.
Commerce evidence
Orders, products, categories, spend, refunds, coupons, purchase timing, customer value, and repeat-purchase behaviour.
CRM and lifecycle evidence
Account stage, relationship state, lead source, lifecycle position, ownership, opportunity context, and other mapped commercial evidence.
Support and service evidence
Open cases, recent complaints, service state, support status, or other context that may make a planned campaign inappropriate.
Audience source files
Subscriber or audience files can be submitted for protected intake, validation, jurisdiction routing, consent review, suppression, and Core-owned transfer.
Campaign payloads
Approved integrations may submit campaign content, permitted fields, sender context, audience requests, scheduling intent, or other bounded campaign instructions.
Action requests
External systems may ask ASI to validate, preview, build, review, queue, report, or return a result. Core decides whether the request is permitted.
Results and evidence returned from Core.
Approved integrations can display ASI results without becoming the system that calculated or authorised them.
Validation results
Accepted, held, quarantined, suppressed, rejected, or transferred outcomes with bounded reason and evidence context.
Audience and eligibility results
Protected audience identifiers, counts, exclusions, jurisdiction routing, consent outcomes, and current send eligibility.
Campaign and Preflight results
Campaign status, Draft Content Review evidence, Preflight findings, queue state, holds, rejections, and permitted next actions.
Reporting evidence
Campaign totals, event evidence, recipient drilldown, human-confidence reporting, links, bounces, provider outcomes, and scoped exports.
The external dashboard chooses the campaign. ASI Core owns the campaign.
Embedded integrations can display the ASI template library and allow permitted operators to choose a saved campaign, preview it, adjust approved fields, select an audience, run review, and request a send. The authoritative template and sent version remain in ASI.
Template library
Campaign templates, approved HTML, subject, preview text, permitted variables, and template status are stored and versioned in Core.
Review evidence
Draft Content Review, Preflight, sender identity, audience eligibility, and approval results remain attached to the Core-owned campaign version.
Creator, approver, sender
ASI records who created, changed, approved, requested, and sent the campaign rather than letting an external screen blur those roles.
Exact version sent
The final subject, preview text, HTML, audience scope, sender identity, review result, and template version remain part of the campaign evidence.
Commerce evidence without handing the shop the send engine.
WooCommerce proves the integration principle in the messiest useful place: real customer records, guest orders, duplicates, missing consent, conflicting legacy hints, refunds, odd addresses, role emails, and changing purchase behaviour.
Buyer evidence
Products, categories, order values, purchase dates, repeat buying, refunds, coupons, and customer history can support audience planning.
Identity conflict
Duplicate or conflicting Woo records are resolved against Core truth rather than allowing one convenient customer row to win.
Consent protection
A purchase does not automatically create marketing permission. Explicit no-consent, unknown consent, suppression, complaints, and source evidence remain protected.
Operator-reviewed action
Woo evidence can help create a proposed audience. ASI still validates, checks eligibility, runs Preflight, and controls the send.
Receive, validate, decide, act, return evidence.
The exact steps depend on the request, but Core remains responsible for every decision that affects subscriber truth or sending.
Receive the request
ASI authenticates the integration and receives the bounded payload, evidence, source context, requested action, and idempotency or replay information.
Validate the contract
Core checks the payload shape, permitted fields, source identity, duplicate or replay risk, authority, scope, and required evidence.
Apply ASI truth
Identity, consent, suppression, validation, bounce state, jurisdiction, audience, campaign, Preflight, Queue Safety, and operator permissions are applied.
Return the result
ASI returns accepted, held, rejected, pending, queued, sent, or reporting results with the permitted reason and evidence context.
Integration access should be narrow, visible, and revocable.
An API connection is not a permanent skeleton key to the client’s subscribers, campaigns, reports, or sending infrastructure.
Authenticated source
Each integration is identified and authorised so Core can distinguish trusted sources, permitted actions, environments, and clients.
Least privilege
The integration receives only the actions and data access required for its approved purpose rather than broad platform authority.
Replay protection
Duplicate, stale, repeated, or replayed requests are bounded so the same payload cannot silently trigger repeated protected actions.
Auditable changes
Source, request, actor, payload scope, Core decision, resulting action, returned status, and relevant evidence remain traceable.
Connected does not mean authorised to override Core.
These boundaries prevent a useful connector from becoming a hidden second platform with weaker controls.
No independent database truth
The connector cannot keep an authoritative subscriber, consent, suppression, audience, campaign, send, or reporting state outside ASI Core.
No direct audience mutation
External systems cannot silently add, remove, reactivate, suppress, or reclassify subscribers in protected audiences without Core processing.
No consent or suppression bypass
A purchase, account stage, payment, support event, or external consent flag cannot overrule protected withdrawal, complaint, suppression, or jurisdiction evidence.
No independent send trigger
The connector cannot bypass Draft Content Review, Preflight, Queue Safety, provider pacing, operator permissions, or queue creation to wake sending directly.
ASI provides protected infrastructure, not unrestricted access to the client’s business.
The integration architecture is designed around bounded data flows, client-controlled permissions, audit boundaries, and least-privilege support access.
Bounded payloads
Only the information required for the approved integration purpose should be submitted or returned.
Client permissions
The client controls which systems connect, what they may request, which users may act, and when access is changed or revoked.
Support boundaries
ASI staff do not receive unrestricted direct access to client data. Any assisted support, migration, or investigation remains authorised and auditable.
Source-specific retention
Imported commerce, CRM, support, API, and private-system evidence may have different retention, deletion, replay, and audit requirements.
Brings useful evidence closer to the decision.
It reduces dashboard jumping, preserves source context, supports better audience planning, keeps campaign and template truth in Core, and returns clear ASI results to the external workflow.
Creates a second system with fewer brakes.
It copies truth, trusts external consent blindly, mutates audiences directly, fires campaigns without Core review, and leaves nobody certain which system owns the final decision.
Explore the surrounding ASI rails
Continue into Woo E-Commerce Module, Subscriber Validation Pipeline, Email Compliance, Sending Engine & Queue Control, Campaign Reports & Insights, and ASI Operations Control Room.
Connect the workflow without surrendering the truth.
Talk to ASI about connecting a commerce platform, CRM, payment system, internal application, private database, or external campaign workflow while keeping identity, consent, suppression, eligibility, sending, reporting, and evidence inside the protected Core.