What You Can Actually Automate on a Neto Store, and What the API Will Not Let You Do

The Neto API is RPC-style, not REST, and that one fact explains most of the friction people hit automating a Neto store. Maropost's engineer documentation describes a single fixed endpoint per merchant: a `/do/WS/NetoAPI` path appended to the store's own domain. You send XML or JSON, and you get JSON back when you ask for it with an Accept header. The operation itself is selected by an HTTP header called `NETOAPI_ACTION`, so a customer lookup and an order update hit the same URL with the same method and differ only in that header value. Most current tooling assumes the opposite. REST clients, schema generators and a lot of no-code connectors are built around the idea that the resource lives in the path and the verb lives in the HTTP method. Point them at Neto and there is nothing to introspect: one path, one method, and the meaning hidden in a header. In practice that means a generic HTTP request step with hand-written headers, or a small client of your own, rather than picking Neto from a dropdown. Budget for it. The work is not difficult, but it is real, and it is the first thing an automation quote for a Neto store tends to miss. It also dates the platform, which is useful context when you are deciding how much to invest in integrations that sit on top of it.

The limit is 500 requests per minute, monitored per account, and it does not increase with your plan. Maropost's API best practices page states the cap and says a breach returns HTTP 429, too many requests. An Essential store at $199 a month and an Enterprise contract get the same ceiling, so you cannot buy your way out of a chatty integration. Five hundred a minute is roughly eight requests a second. That is generous for event-driven work and tight for anything that loops. A nightly job that fetches each order one at a time, then a product record for every line item, will run up a four-figure request count on a few hundred orders and start colliding with everything else that talks to the store: the accounting sync, the shipping app, the reporting pull. A 429 does not care which integration was careless, and the failure lands on whichever one asked next. The design consequence is straightforward. Batch wherever the API lets you ask for a set instead of a record. Cache the slow-moving data, such as product details, categories and warehouse lists, and refresh it on a schedule rather than re-reading it inside a loop. Use webhooks to learn that something changed instead of polling to find out. Put retry with backoff behind every call, because a 429 in the middle of an unattended job at 2am is a silent failure unless something handles it.

The documented surface covers most of the store's operational data. Maropost's engineer documentation lists resource groups for orders and invoices, payments, RMA, products, categories, warehouses, content, currency, customers, shipping, suppliers, vouchers, abandoned cart, accounting and notification events for webhooks. That is wide enough that most back-office automation on Neto is a question of effort rather than possibility. | Resource group | What it makes possible | |---|---| | Orders and invoices | Status notifications, dispatch updates, order export to accounting or reporting | | Payments | Reconciliation checks and payment-state driven workflows | | Products and categories | Bulk edits, feed generation, catalogue tidy-ups | | Warehouses | Stock position reads, reorder-point alerts, multi-location logic | | Customers | Segmentation, marketing list sync, duplicate detection | | Suppliers | Generating purchase orders from live stock rather than a spreadsheet | | RMA | Automated returns acknowledgement, routing and logging | | Abandoned cart | Recovery messaging run from your own system on your own timing | | Vouchers | Programmatic promo codes tied to a campaign or a service recovery | | Notification events | Webhook subscriptions, so you react to change instead of polling | What that contents list does not tell you is which actions inside each group are readable, writable or both, or what the field names look like in your store. Verify against your own account before promising a flow. A resource group in the documentation is a starting point, not a guarantee that the specific write you need exists, which is the same trap covered in why a listed integration still does not work.

Yes, and they are called Notification Events. Maropost's documentation treats them as the preferred way to react to change: use webhooks rather than polling, and validate payloads on receipt rather than trusting whatever posts to your listener. Both points matter more here than usual, because of the 500 requests per minute cap. Every poll you replace with a push is headroom you get back for the work that actually needs it. We could not confirm the individual event names, so this guide does not list any. Pull the current list from your own store's notification event settings, or ask Maropost support, and build against what you can see rather than what an article claims. Whatever the names turn out to be, treat the listener as a public endpoint on the internet. Verify the payload, respond fast, queue the work for processing elsewhere, and make the handler idempotent so a duplicate delivery does not create a duplicate purchase order. Log every delivery with its raw body for a fortnight. When a customer says they never got the dispatch email, that log is the only thing that settles it.

The automations worth building on Neto are back-office ones, because that is where the API surface is deepest and where a small retail team loses its unpaid hours. The six below are reasoning from the resource groups that exist, not promises about your store. Order status notifications. Orders, invoices and shipping are all documented, so telling a customer their order has moved without anyone typing it is a solved problem rather than a project. Abandoned cart follow-up. There is a dedicated cart resource group, which is unusual to expose at API level. It means recovery messaging can run from your own system with your own timing and copy instead of whatever a plugin decides. Supplier purchase ordering. Suppliers, products and warehouses together let you draft a purchase order from live stock positions rather than from someone reading a spreadsheet on a Friday afternoon. Stock threshold alerts. The cheapest useful automation in retail: read stock on hand, compare against a reorder point you set, message the person who can act. Start here if you have never automated anything. Returns triage. The RMA group means returns can be acknowledged, routed and logged automatically, which is the difference between a returns process and an inbox. Getting order data out. Pushing orders and invoices into accounting or into your own reporting on a schedule removes the most common manual export in a retail business, and it is the one most likely to be quietly wrong when a person does it.

Four things about the Neto API we could not verify, and each one can change a quote. First, the authentication scheme. The documentation has an authentication page, but the pages we could read did not state the method, so this guide does not tell you how to authenticate. Second, the individual notification event names, so nothing here invents one. Third, whether any API versioning or deprecation policy exists, which decides how long your integration lives before someone has to revisit it. Fourth, whether Neto has a true app marketplace in the Shopify sense as opposed to an integrations directory plus a partner network. The vendor claims more than 100 integrations on its own site, which is a directory claim, not a marketplace claim. That list is short and deliberate. A page that guesses at an authentication scheme costs you a day proving it wrong. Send Maropost support four specific questions before anyone scopes work: how do we authenticate, which events can fire, what is the deprecation policy, and is there an environment we can develop against without touching live orders. Get the answers in writing and attach them to the scope.

Neto is a live product, not a stranded one, which is the first thing to settle before spending money on it. Maropost publishes dated release notes for Neto, including one dated 12 January 2026 alongside a 2026 releases overview, and the product's own site was offering a 14-day free trial with no credit card required at the time of writing. There is no announced end of life. Anyone telling you the platform is dead is wrong, and it matters, because the answer changes whether you automate now or move first. The published subscription pricing, all AUD per month and excluding tax, is Essential at $199 for one sales channel and up to $250,000 of revenue a year, Professional at $789 for three channels and up to $1 million, and Enterprise on a custom quote above that. Add-ons are priced separately: $99 a month for each extra sales channel, Neto Ship at $99, Pick and Pack at $99, Neto Inventory at $199 and Glew Analytics at $199. Neto charges no transaction fee of its own, so your payment processor bills you separately. Those add-on prices are the useful part of the decision. A reporting need that Glew Analytics would cover at $199 a month is worth weighing against pulling orders and invoices through the API into something you already pay for. Sometimes the add-on wins because somebody else maintains it. Sometimes $199 a month funds a build that answers the question you actually have. Do that arithmetic before either.

Does Neto have a REST API? No. Maropost's documentation describes a single fixed endpoint per merchant, a `/do/WS/NetoAPI` path on your own store domain, with the operation selected by an HTTP header called `NETOAPI_ACTION` and payloads in XML or JSON. That is RPC-style. It works, but generic REST tooling and schema generators have nothing to introspect, so expect hand-written requests. What is the Neto API rate limit? Five hundred requests per minute, monitored per account, returning HTTP 429 when you exceed it. Maropost's best practices page states that the limit applies regardless of plan tier, so an Essential store and an Enterprise contract share the same ceiling. Design for batching and caching rather than looping per order. Can I connect Neto to Zapier or a similar no-code tool? We did not verify which no-code platforms ship a maintained Neto connector, so check before you assume. The reliable route on any of them is a generic HTTP request step where you set the endpoint, the action header and the payload yourself. Anything that expects a REST resource path will need custom handling. Does Neto support webhooks? Yes, under the name Notification Events. Maropost's guidance is to prefer webhooks over polling and to validate payloads when they arrive. We could not confirm the individual event names, so pull the current list from your own store settings or from Maropost support rather than from an article. Is Neto being discontinued? There is no announced end of life, and there is positive evidence of development, including release notes dated 12 January 2026 and an open 14-day free trial. The merchant base is shrinking, though: StoreLeads detection data shows a peak of 2,401 active stores in the third quarter of 2022 against 1,790 in the second quarter of 2026. Should we automate Neto or replatform first? It depends on which Neto features you rely on. If you lean on the bundled marketplace sync, warehouse management or B2B portals, automate where you are. If you are using Neto as a storefront and little else, work through what a Neto to Shopify move actually costs before you build integrations you would rebuild anyway.