How to sync data manually
The extension syncs your store data to the eChat knowledge base automatically via a daily cron job (at 2:00 AM). However, you can trigger a manual sync at any time using the CLI.
Products are synced incrementally: the first run sends the whole catalog, and every run after it sends only the products that changed since the run before. See What a product run sends. The other sources are sent in full on every run.
Sync all data types
bin/magento mirasvit:echat:sync
This command syncs all data sources: store information, products, categories, CMS pages, Mirasvit Knowledge Base articles and blog posts from Mirasvit Blog MX, Mageplaza Blog or Magefan Blog. Each source lands in its knowledge base category, which the extension creates on the first document; the blogs share one, Blog.
One failing source is logged and skipped rather than stopping the run, and a source with nothing to send creates no empty category.
Sync a specific data type
Use the --type option to sync only a specific data type:
bin/magento mirasvit:echat:sync --type=product
bin/magento mirasvit:echat:sync --type=category
bin/magento mirasvit:echat:sync --type=cms_page
This is useful when you've made changes to only one type of content and want a faster sync.
Blog posts
When Mirasvit Blog MX, Mageplaza Blog or Magefan Blog is installed and enabled, its posts are synced into the Blog category with no setting to turn on. Each blog is its own source - blog_mx, mageplaza_blog, magefan_blog - so a store running two blogs gets both, and they never overwrite each other.
Only the posts your store's blog shows are sent, by that blog's own rules: published (or enabled), with a publish date that has passed, and assigned to the store view or to all store views. A post scheduled for later is sent on the first run after its publish date. When the blog itself is switched off for a store view, nothing is sent for it. Each post carries its text, URL, author, publish date, categories and tags.
Each eChat workspace gets the posts of its own store view, with that store view's URLs, and with its own titles and content where the blog keeps them per store view, as Blog MX does.
bin/magento mirasvit:echat:sync --type=magefan_blog --dry-run
Send every product again
Add --full to send every product, not just the changed ones:
bin/magento mirasvit:echat:sync --type=product --full
A full run is never required to keep the knowledge base current, but it is the quickest way to refresh every product document at once, for example after editing synced documents by hand in the eChat backend.
Preview a sync without sending anything
Add --dry-run to see what would be sent, without creating or updating anything in the knowledge base:
bin/magento mirasvit:echat:sync --dry-run --limit=5
Each document is listed with its identifier, name and content length. --limit stops after the given number of documents per source, which keeps the output readable on a large catalog.
For products, a dry run lists what the next run would send: the changed products, or the whole catalog when the next run is a full one.
What a product run sends
Each product run starts with a line that says what it will send, for example:
Delta run since 2026-11-02 02:00:01 (change #5120): 14 changed product(s), 160 refreshed.
A product is sent when anything its document shows changes in Magento:
- its own attributes, prices, tier prices, images, stock, websites or categories;
- a variant of a configurable product, or a product inside a bundle or grouped product - the parent is sent too;
- the label of an attribute option it uses, or the name of a category it is in;
- a category it is in being deleted or moved;
- a catalog price rule that applies to it being added, edited or removed, or the product entering or leaving a rule;
- a special price or catalog price rule starting or ending, by your store's calendar date.
Changes made by imports, the REST API, mass actions and other extensions are caught the same way as changes saved in the admin.
When a product run is full
A product run sends the whole catalog when:
- it is the first run for that eChat workspace;
- you add
--full; - something that shapes every product document changes: the attributes shown on the storefront, tax display settings or rates, the store URL or URL settings, the Display Out of Stock Products setting, the store's root category or base currency;
- product change tracking was switched off and on again since the last run, or the record of changes was cleared past where that workspace's last run stopped - this happens to a workspace that was switched off while other workspaces kept syncing.
The first line of the run names the reason.
Every product is sent again within 30 days
Each day's run also sends a thirtieth of the catalog that did not change, so every product document is rewritten at least once every 30 days. This catches, without a full run, the rare change the tracking above cannot see.
Products waiting for Magento's indexes
When Magento's stock or catalog price rule indexers are set to Update by Schedule, a product saved a moment ago may not have its stock or rule price indexed yet. The run does not guess:
- a product the store does not show yet because its stock is not indexed is retried on the next run, instead of being left out;
- a product whose catalog price rule is not indexed yet is sent now and sent again once the rule price is current;
- an edited catalog price rule reaches the documents on the first run after the rule index has run, with the new rule price.
The run reports how many products it held back. A product still waiting after three runs is dropped from the retry list with a warning that an indexer is not keeping up - check that Magento's cron is running. The 30-day refresh still sends it later.
Where to see what a run did
Every run of every source writes a summary line to var/log/mst_echat_sync.log, with the number of products changed, refreshed, built, sent, failed and removed, plus each document that failed to upload. The same line is printed at the end of a manual run, so the nightly cron run leaves the same trace.
Documents are matched by identifier, and each source owns its own identifiers (product.42, cms_page.7, and so on). Anything stored under those identifiers is replaced whenever the sync sends it again, so an edit made by hand in the backend's Knowledge Base screen does not last. Categories, CMS pages, store information and Knowledge Base articles are sent on every run, at 2:00 AM at the latest. A product document is sent again when the product changes, and in any case within 30 days.
The product sync also removes what the store no longer shows. A product that goes out of stock (when Display Out of Stock Products is set to No), is disabled, is hidden from the catalog or is deleted loses its knowledge base document on the next run, so the chatbot stops offering something your store cannot sell.
To add content that the sync leaves alone, give it an identifier of your own. See Knowledge Base.
When the sync removes nothing
For products, what to keep is read from the catalog itself, not from what the run sent: every product your store shows stays, every other product document is removed. So a run that sends a handful of changed products, one capped by --limit, or one where some uploads failed still removes exactly the products that left the store. A product run removes nothing when the store shows no products at all.
Blog posts are removed like products, but from what the run collected: a post that is unpublished or deleted leaves the knowledge base on the next run. A blog run removes nothing when it was capped by --limit, when any post failed to upload, or when it collected no posts at all.
Store information, categories, CMS pages and Mirasvit Knowledge Base articles are only added and updated, never removed: a page you delete or disable in Magento keeps its knowledge base document until you delete it in the eChat backend.
--dry-run never removes anything, and does not preview removals either: it contacts eChat for nothing at all.
Your store's own content can be added to the chatbot's knowledge base as well - see How to add a custom data source.