Magento 2 Instagram Feed
Instagram is one of the most popular social networks around. It’s becoming more and more ecommerce-friendly with its seamless shopping experience. Expanding your presence on the network is an excellent business opportunity. However, seamless shopping means you have to get your products there first.
Magento 2 Instagram Feed lets you create a product feed for Instagram, schedule feed generation and delivery, analyze its results with an analytics suite, and more.
- Generate an Instagram product feed
- Create as many feeds as possible
- Use ready templates and clone for similar catalogs
- Use conditions to filter products
- Validate feeds before upload
- Automate the generation and delivery
ℹ️ Important: This sub-module is included in the Advanced Product Feeds extension.
Buying this item gives you access to all feeds including Facebook, Instagram, Google Shopping, and others in one powerful package.
Magento Cloud
The extension is compatible with Magento Cloud.
Compatible with:
Community:
2.3.* - 2.4.9 Enterprise:
2.3.* - 2.4.9 Save time with a Free Installation
Check the "Free installation" box on the module page to get Free installation and custom configuration
Business Value
- Opportunity: Instagram says it has more than 1 billion users. This social network is gaining the lead in ecommerce, too. Its shoppable posts let users buy products without even leaving the app. 70% of shoppers in the US use Instagram for product discovery, according to Facebook. In other words, Instagram is perfect for sales and advertising.
- Problem: Seamless shopping experience means you have to export your products to Instagram before you can sell there. You also have to be able to update them regularly.
- Solution: Magento 2 Instagram Feed lets you quickly and easily generate a product feed for Instagram, tweak its content and automate its generation and delivery.
How It Works
Instagram takes its products from Facebook Shops. This feature lets you create a feed with a ready-to-go template for Facebook which you can then use in your Instagram account.
Main Advantages
Create as Many Feeds as Possible
There are no limits to the number of feeds or products inside them. You can generate as many of them as you need, which can be as large as required for your business.
Get Straight to Business
This feature offers a preconfigured Facebook template so you don’t have to waste time setting it up. However, we also offer advanced pattern and variable customization options if your business requires them. You can clone a preset for similar catalogs while keeping the source unchanged, and quickly locate templates using the A–Z index and name search. If your channel requires a unique structure, you can build a feed from a blank setup instead of using a template.
Use Conditions to Filter Products
You may not need to export the entire catalog. You can single out only the exact products you need with Magento conditions. They support both product attributes and product performance data.
Validate Feeds Before Export
Make sure your file meets platform rules before upload. Set checks in Content Settings > Validation Rule, generate the feed, and run validation. You will get a clear report with line numbers and plain-language messages. Fix values, regenerate, and publish with confidence.
Automate Generation and Delivery
If you update your catalog often, you can set the feed generation to a specific date. You can also automate feed delivery to Facebook via FTP or SFTP.
See it in action!
Pick a quick tutorial to learn about various aspects of this extension
Customer Reviews 0
Earn points for your review about this extension modules. $1 = 10 points
Write Your Own Review
Manual & Support
Documentation
Need more help?
Save time by starting your support request online and we'll connect you to an expert.
Frequently asked questions
Can I generate the feed for a different service?
Yes, you can. Besides manual generation, this module includes templates for **50+** ecommerce services, including Amazon and Google Shopping.
Changelog
Version 1.15.11Sep 16, 2026
Feed cron no longer piles up idle PHP processes until the server runs out of memory. The feed cron group runs each due job in its own PHP process, and nothing stopped a second one from starting while the first was still working: an export that ran longer than its schedule interval was joined by a fresh process at every interval, and the one-minute queue job re-read the pending queue and started exporting the same items again alongside itself. Each of those processes costs 300–400 MB just to boot, so on a store with a long export they accumulated faster than they finished and the box eventually ran out of memory — the symptom was several feed processes sitting at 0% CPU and ~330 MB each. Both the scheduled export job and the generation-queue job now check whether a run is already in progress and simply do nothing until it finishes, and the marker is released even if a run crashes, so the next scheduled tick always gets its turn.
A feed that is already being exported now says so straight away instead of hanging, and a failed export no longer blocks the feed afterwards. When an export was already running for a feed, a second attempt waited on it indefinitely rather than reporting the feed as busy:
bin/magento mirasvit:feed:export --id=N printed nothing at all instead of "already locked by another process", and a fully booted Magento process sat idle for as long as the other export took. On top of that, an export that ended in an error left the feed marked as in progress, so the next queued generation of that feed waited on a lock that would never be released and the cron run stalled. A busy feed is now reported within a second, and the marker is always cleared when an export ends, successfully or not — so the run moves on to the next feed. Stores whose media directory sits on a filesystem without file locking (NFS, AWS EFS) keep generating feeds as before.
Version 1.15.10Sep 15, 2026
Admin pages belonging to other extensions no longer fail with "The element with the '…' ID wasn't found". To keep its own admin screens from tripping a PHP deprecation notice, the extension quietly gave a name to any admin panel that had been left unnamed — including panels that belong to other extensions. When such an extension later named that panel itself, Magento could not find the name we had invented and the page died with that error instead of loading; Firebear Improved Import & Export's import job edit screen was one of them. Naming is now limited to this extension's own panels, so everyone else's pages are left alone and load normally, while our screens stay free of the deprecation notice.
Version 1.15.9Sep 14, 2026
A sale that is live on the storefront is now priced as a sale in the feed. The feed decided for itself whether a special price was still inside its from/to window, and it asked the server's UTC clock — while Magento judges that same window on the wall clock of the admin timezone, deliberately, so one special price means the same thing in every store view. The two disagree by exactly that timezone's offset, so on a store ahead of the server the storefront was already charging the sale price while the feed still published the full one, at every hour of the day. That is the "mismatched value" disapproval in Google Merchant Center and its equivalents elsewhere. The window is now Magento's to judge, so the feed and the storefront always quote the same price. An open-ended special (no end date) still applies, a window that has closed or has not opened still exports no sale price at all — not a
0, which would advertise the product as free.A fractional stock quantity is no longer rounded down. Quantity was exported as a whole number, so a product stocked by weight or volume — 0.5 kg of something, 2.5 m of cable — shipped a quantity of
0 and read as out of stock in every channel that trusts that column. Fractional quantities, and the summed quantity of a configurable's or grouped product's children, now export as they are actually stocked. A whole-number quantity is unaffected: 5 still exports as 5.{% if a and b and c %} now checks every condition in a feed template. A template condition joining three or more comparisons with and / or only ever evaluated the last two — everything before them was silently discarded, so a three-part rule guarding a column emitted the wrong branch with nothing in the log. Conditions are now folded left to right across the whole statement. Two-condition ifs, which is what most templates use, behaved correctly before and are unchanged.The feed statistics chart no longer drops days with no traffic. A day with no recorded clicks was left out of the sparkline entirely rather than drawn as a zero, so three active days in a fortnight rendered as three adjacent bars and a sporadic feed read as one with steady traffic. Every day in the selected period now contributes a point, a quiet day as a genuine
0, so the shape of the chart matches the period it covers.Feed generation and AI optimisation survive a media mount that has dropped out. The advisory lock file that keeps the admin, cron and CLI export paths from colliding was created under
pub/media/feed/tmp, and the AI optimisation run kept its own lock in the same place. Where media is a remote or network mount (NFS, AWS EFS) that has lost its transport — after an OOM kill, say — opening that file failed before a single product was exported, and every feed on the store stayed broken until the mount came back. Both locks now live in var/mst_feed/tmp, next to the export's scratch and progress files, which already moved there: a transient coordination file has no business on shared storage. Nothing about how you use the extension changes; if a monitoring check watches for a stale .lock, point it at the new directory.The AI profile template picker is no longer empty on stores that keep media on remote storage (Amazon S3 and compatible). The bundled profile templates ship inside the extension's own directory, but were being read through the remote-storage driver, which answers for a key that has never existed in the bucket with an empty file rather than an error. Every template then parsed as broken and was quietly skipped, so the picker offered 131 entries on an ordinary store and none at all on an S3 one, with no exception anywhere to explain it. They are now read from the local disk they actually live on.
Google category mapping works again on PHP 7.x. An empty search was read as "match nothing" rather than "match everything" on PHP 7, so the taxonomy came back empty with nothing logged: the category-mapping autocomplete in the admin offered no suggestions when opened with an empty box, and validation rejected every real Google category as invalid. Both work as they do on PHP 8 now.
A CSV template saved without a format no longer breaks the feed. A template is allowed to carry just a name and a type, and one saved that way reached generation with no column delimiter at all — a fatal error on PHP 8 and a run-together line on PHP 7. Such a template now renders with no separator rather than failing, and no delimiter is invented on your behalf.
The feed history grid remembers your Columns choice. The Columns dropdown rendered and worked, but the selection — along with filters and page size — was gone on the next load, with no error and nothing in the log. The grid now saves its view the way every other grid in the extension does.
An empty product selection no longer ends in a database error. Previewing a feed whose store view belongs to a website with no products assigned answered with a raw MySQL syntax error instead of an empty preview — the empty list of products was handed to the database as an empty condition. An empty selection is a legitimate answer and is now treated as one: the preview simply comes back empty. In the same vein, a feed left with no filter rule at all now explicitly clears its product set, so detaching the last rule no longer leaves the previous run's products attached to it.
The Order # column in the SKU report resolves again. The column is now backed by a direct link from the report row to the order it was attributed to, so it shows the order number rather than nothing.
Feed columns in the reports no longer go through a temporary table. The relationship between a report row and its feed was declared the wrong way round — the reporting engine believed one report row could have many feeds — so adding a Feed column pushed the data through a temporary table instead of joining it directly. Reports that group or filter by feed are now built with a plain join.
Version 1.15.8Sep 7, 2026
An empty feed now tells you it is empty. A generation that matched no products used to finish with a green Feed file was generated., a blank or negative Products in feed count and a stray Valid 0 — with an empty file and no hint as to why. Such a run now ends with a warning that names the usual causes (the product filter matched nothing, the chosen store view has no products assigned, the catalog indexes are invalid) and links the troubleshooting guide, and the count always reads as a real number, including a genuine
0. ([#757]())Category filters now select the products they describe. With Enable fast mode filtering on — the default on every feed — four of the Category operators compared the single category id stored per product against the whole comma-separated list you picked, so Category is 5, 7, 12 produced an empty feed and Category is not 5, 7, 12 exported the entire catalog. Does not contain was wrong in a second way: it matched the ids as text, so excluding categories 3 and 4 also quietly excluded 13, 23, 30, 34 and every other id containing those digits. Is, is not, contains and does not contain now all ask the indexed category-membership question — a positive operator means "in one of these categories", a negative one "in none of them" — in both filtering modes, so saved rules match correctly and both modes agree. Is one of / is not one of are unchanged. ([#756]())
A filter that combines conditions with ANY no longer empties the feed in fast mode. Fast mode narrows the catalog with a database query before checking each product, and a condition that has no database equivalent — Quantity, Is Salable, the image fields, a PHP condition and a dozen more — was simply left out of that query. Inside an ANY group that made the query stricter than the rule: measured on a 2,046-product store, Quantity is greater than or equal to 0 OR SKU is NO-SUCH-SKU kept all 2,046 products with fast mode off and exported none with it on, with nothing in the log to explain it. An ANY group is now used to narrow the catalog only when every condition in it can be expressed as a query; otherwise the feed checks the full candidate set — slower on such a rule than before, and correct, where before it was fast and wrong. Rules that are a plain ALL list of ordinary attributes, the common case, keep exactly the speed they had, and stock filters keep selecting the same products as always.
Final Price filtering in fast mode is exact again. 1.15.7 started reading Final Price from Magento's price index to narrow the catalog, and that is not the same number the filter itself computes: on stock sample data 26 of 147 configurable products disagreed, and because the narrowing runs first, a product the rule keeps was never even looked at — Final Price is greater than or equal to 25 silently left out a product priced at 28.00. The index also holds enabled products only, and under a per-website or per-customer-group price index it can be empty altogether, which would have emptied every Final-Price feed. Final Price is now decided by the same per-product calculation the slower mode uses, in both modes, for simple, configurable, bundle and grouped products alike. ([#764]() follow-up)
Filters left with an empty value now match exactly what they match with fast mode off. 1.15.7 gave three of them a fast-mode condition, and two of those did not agree with the slower mode: is not one of with nothing selected kept every product that has a value for the attribute, where the filter in fact matches no product at all — on the sample catalog that was 47 of the 81 products the admin preview offered for a rule that selects nothing — and is one of with nothing selected built no condition, so fast mode let the whole catalog through. Both now select nothing, as they do with fast mode off. Is not with an empty value — the "is not empty" filter — keeps its meaning and no longer drops a product whose value is
0. ([#772]() follow-up)forloop.first and forloop.last work in feed templates. Both were computed from the product's internal id rather than its position in the loop, so {% if forloop.first %} never once matched and forloop.last fired on whatever product happened to carry the matching id — the documented way to write a feed-level value into a header produced nothing. Both flags, and forloop.notlast, now follow the loop's own position. ([#746]())A value captured out of the product loop now reaches the header and footer. The documented pattern —
{% capture %} around {% for p in context.products %} — came out blank: the end of the product loop stopped the rest of the document for that pass, so the field that reads the captured value was never rendered, and on the next pass the exhausted loop overwrote the value with an empty string. The captured value is now kept and carried between the passes of a chunked export, so a footer rendered only in the final pass still sees it, while a capture inside a {% for %} still recalculates per row. A capture interrupted part-way — by the export's time limit or by Stop — no longer publishes the half-built value it had accumulated, in a header, in an {% if %}/{% else %} branch or inside another capture: the field stays empty for the rest of that export rather than shipping a plausible-looking but truncated value. Very large captured values (over 64 KB) still reach the feed file in the pass that produced them, they are just not carried across passes. An export already in progress keeps running across the update.The exported product count no longer goes blank on a store view that is not in English. The export runs in the store view's language and the count was looked up by the export step's translated label, so on a Spanish or Romanian store view — 42 of the 45 shipped locales translate the word — the Count column in the Feeds grid, the status bar and the generation panel all showed nothing, and a spurious Valid 0 appeared beside a green success. Verified on a store view in Spanish: a 346-product feed now reports 346. The lookup also keeps working when another extension plugs into one of the export steps. ([#757]())
Version 1.15.7Sep 3, 2026
A filter on Final Price is no longer ignored. With Enable fast mode filtering on — which it is by default on every feed — a condition such as Final Price is greater than 50 was silently dropped: the rule matched the whole catalog, so the feed shipped every product instead of the selection you asked for, while the same rule with fast mode switched off filtered correctly. Final Price is now taken from Magento's price index for the feed's store and website, and bundle, configurable and grouped products are compared against the same price the slower mode uses, so both modes now produce the same feed. ([#764]())
Filters left with an empty value now do what they say in fast mode. Three operators built no usable condition when their value was blank, so instead of filtering they let every product through: is not with the value left empty — the "is not empty" filter — kept products that have a value and products that have none, the exact opposite of what it asks for; is not one of with nothing selected did the same; and does not contain with an empty value, which excludes every product, excluded none. All three now give the same result as they do with Enable fast mode filtering turned off. ([#772]())
We are committed to being open and transparent with our customers. When you purchase our module, you automatically receive one year of free support service and free updates.
Why is this important?
- Seamless Installation and Configuration: We understand that setting up a new module can take time to configure according to your specific needs. That’s why we offer a full year of free support. Our experienced team is here to assist you with installation, configuration, and any questions you might have. We're eager to share our expertise to ensure you get the most out of your purchase.
- Stay Updated with Magento (Adobe Commerce) Releases: Magento releases new versions approximately every three months. These updates can sometimes introduce compatibility challenges. To keep your store running smoothly, we provide a year of free access to the latest versions of our modules, ensuring that you can upgrade Magento and our modules without encountering any obstacles.
- Subscription Included: Renewing your subscription ensures continued access to the latest updates and support from our team. This means you can be confident that any issues you encounter with the extension will be resolved quickly and efficiently. You can cancel your subscription at any time without any additional fees.
Reasons to choose Mirasvit
Client focusing and satisfaction
These are our primary. A major portion of our new clients come from referrals from our existing clients. Our professional team of developers, marketers and support staff have invested the best knowledge and experience in the field into our work, so you know you can come back to us again and again.
Remarkable support
One year free and high quality support. We go to great lengths to provide maximum satisfaction with every module you have purchased in our store. By helping you with installation, configuration, answering your every question, we do all our best to eliminate any possible problems.
Risk-free Investment
30-days money back guarantee. If you are not satisfied with our extension performance for any reason, we provide a full refund.
Constant improvements and upgrades
We constantly add new features to all our modules, and are always interested in hearing your opinion and implementing your suggested features in our future developments.
Comprehensive Documentation
We provide an expanded user guide for every aspect of our extension, so you can find answers for all your burning questions.
Unencrypted source code of our products
You can customize extension according to your needs and requirements.
Usability and Performance
The Module is easy to install and upgrade, just follow our step-by-step user guide.
Ready for Magento Cloud
No core modifications. The extension has been tested in a Magento Cloud environment and is fully compatible with it.