Magento 2 Wishlist REST API: Options, Setup and Auth

Magento 2 wishlist REST API access isn't something you get out of the box. The sources we checked say core Magento has no native wishlist REST endpoint, so you pick one of four routes: Adobe's built-in GraphQL wishlist mutations, a custom REST module, an open-source module, or a paid extension. This guide compares them and explains authentication.

Key takeaways

• Two independent sources say Magento 2 has no native REST endpoint for wishlists. We couldn't confirm a core one in Adobe's documentation either.
• Adobe's documentation does list a full set of GraphQL wishlist mutations, including add, remove, update, copy, move, clear and create.
• Wishlist calls are customer calls. They need a customer token, and a guest can't change a wishlist.
• Magento Open Source allows one wishlist per customer. Adobe Commerce allows several.
• A custom REST module is the most flexible route and also the one you'll have to maintain yourself.
• Prices and listings for paid extensions change, so check each vendor page before you decide.

Does Magento 2 have a native wishlist REST API?

No, not according to the sources we read. A third-party tutorial published in May 2025 states plainly that there's no native API endpoint for wishlist functionality in Magento 2, and a Magento Stack Exchange question from 2018 says the same. We couldn't confirm a core REST wishlist endpoint in Adobe's documentation, so treat "none" as well supported but not officially stated.

That sounds like a dead end, but it isn't. The wishlist feature itself is part of Magento, and Adobe exposes it through GraphQL. What's missing is a ready-made REST route you can call from a mobile app or an ERP. The rest of this guide is about filling that gap sensibly.

If you've ever searched for a "free" wishlist API module, this is why the results look so scattered. Developers have been asking for a REST wishlist for years. A GitHub issue opened in April 2016 on the core Magento repository asks for REST APIs for both wishlist and product reviews, and a Stack Exchange question from November 2020 is titled as a hunt for a free extension. The demand is old, and the options are a mix of tutorials, community code and commercial products.

Why would a store need a wishlist API?

Because the storefront isn't the only place a wishlist lives anymore. If your customers use a mobile app, a progressive web app or a headless front end, those clients need to read and change the same wishlist the website shows. They can't click a button on a Luma or Hyvä page, so they call an API instead.

There are a few common situations where this comes up:

• A native mobile app. The app needs to show saved items, add a product from the product screen, and move an item to the cart.
• A headless or decoupled storefront. The front end is a separate application that talks to Magento only through APIs.
• Back-office and ERP integrations. A sales or merchandising system wants to read what customers are saving, or clean up stale lists.
• Marketing tools. A team wants to trigger a reminder when a saved product goes on sale or returns to stock.

Notice that these are different jobs. A mobile app acts on behalf of one logged-in customer. An ERP integration may act on behalf of the whole store. That difference drives a lot of the authentication decisions later in this guide, so keep it in mind as you read.

If you're still deciding how your clients should talk to Magento in the first place, our plain-English comparison of REST API vs GraphQL is a good companion to this post.

What are your options for a Magento 2 wishlist API?

You have four realistic options: use Adobe's GraphQL wishlist mutations, write a custom REST module, start from an open-source module, or buy an extension. Each trades cost, control and maintenance differently. The table below summarizes them, using only what we verified.

None of these is best for everyone. The right choice depends on who the client is, how much customization you need, and who will look after the code in a year. We'll go through each option in turn, then finish with a decision guide.

Option 1: Use the built-in GraphQL wishlist mutations

Adobe's GraphQL schema includes a dedicated wishlist section. Its documented mutations are addProductsToWishlist, addWishlistItemsToCart, copyProductsBetweenWishlists, clearWishlist, createWishlist, deleteWishlist, moveProductsBetweenWishlists, removeProductsFromWishlist, updateProductsInWishlist and updateWishlist. That covers most of what an app or headless store needs, and it's part of the product rather than something you'd add.

Adobe's own page on the wishlist schema also notes that the older wishlist query has been deprecated. Wishlist information is now returned by the customer query instead. So if you find an old tutorial that reads a wishlist with the dedicated query, expect it to be out of date.

How the add-to-wishlist mutation behaves

The addProductsToWishlist mutation adds one or more products to a specified wishlist and, according to Adobe, it supports all product types. A few details from the documentation are worth knowing before you write any client code.

First, it needs a valid customer authentication token. Second, you pass a wishlist ID, and you can find the right value by running the customer query and reading the wishlist ID from the response. Third, Adobe notes you can check whether wishlists are enabled on a store by requesting the magento_wishlist_general_is_enabled attribute in the storeConfig query. That's a handy first call for an app, because it lets the client hide the wishlist button on stores where the feature is switched off.

Adobe's example request adds a simple product, a configurable product and a bundle product in one call. The configurable item is identified with a parent SKU plus the child SKU, and the bundle item carries its selected options. The example also includes a deliberately invalid SKU, and the response handles it gracefully: the valid products are added, and the bad one comes back as an entry in a user_errors object with a PRODUCT_NOT_FOUND code. In practice that means your client should always read user_errors, not just check that the call returned something.

The Open Source versus Adobe Commerce difference

This one trips people up. Adobe's documentation says that in Magento Open Source a customer can have only one wishlist, while in Adobe Commerce a customer can have multiple wishlists.

There's also a first-use quirk in Open Source. The createCustomerV2 mutation doesn't create a default wishlist for the customer there. To add the first item, you specify a wishlist ID of 0, and the application creates the customer's default wishlist and returns its ID. Adobe adds that customers created by other means, or in Adobe Commerce, don't have this limitation.

If you build a client that has to work on both editions, plan for both behaviors. A multi-wishlist screen makes no sense on Open Source, and a "create my first wishlist" flow needs the ID-0 handling.

Errors you should handle

Adobe lists two error cases for the add mutation. One is that the current user can't perform operations on the wishlist, which happens when a guest tries to add an item or when a customer tries to touch another customer's wishlist. The other is that the wishlist wasn't found, meaning the ID is invalid or doesn't exist for that customer.

Both are worth turning into clear messages. "Please sign in to save items" is a better experience than a raw error string, and it's the honest answer when the cause is a missing token.

When GraphQL is enough

If your app or headless storefront already uses GraphQL for products and cart, adding wishlist calls through the same channel is the least work. You don't add code to Magento, you don't carry a module through upgrades, and you use operations that Adobe documents.

GraphQL is less convenient when the consumer can only speak REST. Some ERP connectors, older mobile codebases and low-code tools fall into that group. For those, you'll want one of the next three options. Our overview of what Magento's APIs can do explains where REST and GraphQL each fit.

Option 2: Build a custom REST module

A custom module lets you expose exactly the wishlist routes your client needs. Magento's web API layer is built for this. Adobe's documentation says you define web API resources and their permissions in a webapi.xml file inside a module, and its architecture notes say any service contract can be exposed as REST and SOAP endpoints through that configuration.

A third-party tutorial from Meetanshi, published in May 2025, walks through a complete example. We read it, and the approach is worth understanding even if you never copy its code.

The moving parts

The tutorial's module has the usual pieces of a small Magento module: a module declaration, a registration file, a webapi.xml with routes, a dependency-injection configuration that maps an interface to its implementation, an interface describing the operations, and a model class that does the work. It defines four operations: get items, add an item, delete an item, and move an item from the cart to the wishlist.

The routes are attached to "self" permission rather than to an admin resource. That matters. Adobe's authentication documentation explains that "self" is a special access level for resources a logged-in customer owns, and its own customer example uses it for a "me" route, where the customer's ID is filled in from the authenticated session rather than trusted from the request.

The tutorial follows the same idea. It forces the customer ID to come from the token, so a client can't ask for somebody else's wishlist by changing a number in the URL. If you build your own module, copy that principle even if you change everything else.

What the example routes look like

In the tutorial's example, the routes sit under a version prefix and a wishlist path. Reading items is a GET to the wishlist path, adding is a POST to the same path with a product identifier and quantity in the body, deleting is a DELETE that includes the item ID, and moving from cart uses a POST to a move path with a quote ID and item ID. All of them expect a customer bearer token in the authorization header.

These are that author's routes, not core Magento's. If you write your own, you're free to name them differently. Just keep them consistent, and document them for whoever builds the client.

What the model has to get right

The example's add operation does a few things that any serious implementation needs. It loads or creates the customer's wishlist, loads the product, and refuses to add a product that isn't visible in the catalog. It builds the purchase request for configurable and bundle products from the options the client sends. It adds the item, saves the wishlist if it's new, and dispatches Magento's wishlist add-product event so other modules can react.

That last step is easy to forget and it's worth keeping. Other extensions sometimes listen for that event, and skipping it can make your API behave differently from the storefront button.

The tutorial's read operation returns product details for each wishlist item, such as name, SKU, price, quantity and image URLs, and it builds image URLs from the store's media path. If your store serves media from a CDN or strips the pub path, that piece needs adapting. We can't say how the example behaves on every setup, so test it on your own configuration.

The cost of owning the code

A custom module is free to license but not free to run. You're responsible for testing it on each Magento upgrade, fixing it when a dependency changes, and handling edge cases such as out-of-stock items, configurable options that no longer exist, and deleted products. If your team doesn't have developers who do that routinely, weigh that cost honestly.

If you'd rather hand that work to specialists, our Magento development team builds custom modules, and our application support and maintenance service covers keeping them healthy after launch.

Option 3: Start from an open-source module

Searching for a free Magento 2 wishlist REST API turns up community code. One result we saw is a GitHub project described as a Magento 2 module that exposes the customer wishlist through REST APIs, letting you read the wishlist, add and remove items, move items to the cart or back, and empty it.

We only saw that project's description, so we can't vouch for its code quality, license, Magento version support or how actively it's maintained. Those are exactly the things you'd check before using it.

A quick checklist before you adopt community code

Open-source code is a good starting point, but it isn't a finished product. Before you install anything, look at these points:

• Compatibility. Does it state which Magento versions it supports, and do those match yours?
• License. Does the license allow your use?
• Activity. When was the last commit, and are issues answered?
• Security. Does every route tie the customer ID to the token, or does it accept an ID from the client?
• Tests. Are there any automated tests you can run?
• Fit. Does it cover product types you sell, such as configurable and bundle products?

If the answers are mostly good, you can use it as-is or fork it. If they're mixed, treat it as a reference and write your own module with the same outline.

Option 4: Buy a wishlist REST API extension

Several vendors sell packaged wishlist REST API extensions. In Google results on 30 September 2026, we saw listings from MageComp, Magecurious, WebbyTroops and an Adobe Commerce Marketplace entry, with prices shown from $29 to $198. Prices and terms change, so check each vendor page before you decide.

The listings describe similar ground. One vendor says customers can add, remove and view wishlist products through the Magento REST API. Another describes endpoints that let administrators interact with user wishlists. A third says its plugin covers almost all the features wishlist functionality should have.

WebbyTroops' own Wishlist REST APIs extension

WebbyTroops sells a Wishlist REST APIs extension for Magento 2. Its listing describes managing the Magento 2 wishlist through REST APIs: add, update, delete and share items, and move items between the cart and the wishlist, with integration into ERP systems and mobile apps. The listing showed a $35 price in the Google result we read.

We only verified that description. Details beyond it, such as the exact endpoint list, supported product types and compatible Magento versions, are not confirmed here, so read the product page before you buy, and check the terms in the same way you would for any vendor.

How to compare paid options fairly

When two extensions look similar, the differences are in details the listing may not spell out. A short comparison list helps:

1. Operations covered. Does it include update and share, or only add, remove and view?
2. Authentication. Does it use the standard customer token, and does it tie the customer to the token?
3. Product types. Does it handle configurable, bundle and custom-option products?
4. Versions. Does it support your Magento version and your PHP version?
5. Support. Is there a documented way to get help, and for how long?
6. Returns and refunds. What happens if it doesn't fit your setup?

Ask the vendor for API documentation before you buy. A good extension has a clear list of routes, request bodies and responses you can read in advance.

How does authentication work for a wishlist API?

Wishlist calls are customer calls, so they use a customer token. Adobe's documentation says token-based authentication is a good fit for customers and admin users in third-party apps. The token service returns a token in exchange for a username and password, and you then send that token in the Authorization header of each request.

Adobe also recommends using this kind of authentication over HTTPS. That's a sensible rule for any call that carries a customer's identity, and wishlists are no exception.

Who can do what

Adobe describes four kinds of API user: administrator, integration, customer and guest. Which resources each can reach depends on the permissions defined in the module's webapi.xml. A customer can reach resources marked with "anonymous" or "self" permission. A guest can reach only those marked "anonymous". All customers share the same permissions.

Two consequences follow for a wishlist. First, a wishlist route should use "self", so only a signed-in customer can reach it and only for their own data. Second, a guest can't have a server-side wishlist through these routes, so your app needs a sign-in step or a local fallback for guests.

Tokens versus sessions versus OAuth

Adobe describes three approaches. Token-based authentication suits mobile apps. Session-based authentication suits JavaScript widgets on the storefront, where the browser already has a session cookie. OAuth-based integration suits third-party systems that register with the store.

For a mobile app reading one customer's wishlist, tokens are the natural choice. For an ERP that needs to read many customers' wishlists, the situation is different, because a customer token only represents one customer. That kind of integration needs admin-level or integration-level access, which carries more risk. Keep such routes separate from the customer routes, limit them to the smallest permission that works, and don't expose them to apps.

Keep the customer ID out of the request

The single most important design point is this: never let the client tell you whose wishlist to load. Derive the customer from the token. The approach in Adobe's "me" example and in the tutorial we read does exactly that, and it's what prevents one customer from reading or changing another's list. Adobe's add-to-wishlist documentation describes the same protection on its side, returning an error when a customer tries to touch another customer's wishlist.

What should a wishlist API cover?

A complete wishlist API lets a client read the list, add items, change quantities, remove items, and move items to the cart. Depending on your store, it may also need multiple lists, sharing, clearing the whole list, and copying items between lists. Start with the basics and add the rest only when you have a real use case.

Here's a practical checklist for a REST design, modeled on the operations Adobe documents for GraphQL:

• Read. Return items with product name, SKU, price, quantity, image and selected options.
• Add. Accept a product identifier, quantity and, where needed, the options that define a configurable or bundle choice.
• Update. Change quantity or notes for an item.
• Remove. Delete one item by its wishlist item ID.
• Clear. Empty the list in one call, if your app needs it.
• Move to cart. Turn a wishlist item into a cart item, and handle the case where the product is unavailable.
• Move from cart. Save a cart item for later, as the tutorial's example does.
• Multiple lists, copy and move. Only on Adobe Commerce, where customers can have more than one list.

Notice that Adobe's GraphQL list includes copying and moving between lists and creating, updating and deleting lists. Those only make sense on Adobe Commerce, since Open Source allows one list. If you serve Open Source stores, skip them.

How do you test a wishlist API before you ship it?

Test it with a real customer token against a staging store, and try the cases that break things: a guest, another customer's list, an invalid product, an out-of-stock product and a configurable product with options. A wishlist API is small, but its mistakes are quiet, and they show up as confused customers rather than errors.

Here's a simple order of work:

1. Get a token. Sign in as a test customer through the token service and keep the token for your test calls.
2. Read an empty list. Confirm the API returns an empty result, not an error, for a customer with no wishlist yet.
3. Add a simple product. Check that it shows up on the storefront wishlist page too.
4. Add a configurable and a bundle product. Verify the chosen options survive.
5. Add an invalid product. Confirm you get a clear error, and that valid items in the same request still behave the way you designed.
6. Try to reach someone else's list. This should fail. If it doesn't, stop and fix it before anything else.
7. Call without a token. The call should be refused.
8. Move an item to the cart. Then check the cart, the quantities and the stock handling.
9. Delete an item. Confirm it's gone on both the API and the storefront.

The storefront comparison in steps 3 and 9 is the quickest way to catch behavior differences, because the storefront wishlist is the reference behavior your customers already know.

Common mistakes to avoid

Most wishlist API problems come from a handful of repeat mistakes. These are practical points rather than documented failures, so weigh them against your own setup.

• Trusting a customer ID from the request. Always derive it from the token.
• Ignoring the response's error list. With GraphQL, a call can succeed overall and still report a failed item in user_errors.
• Assuming every store has one list. Open Source and Adobe Commerce behave differently.
• Forgetting the first-list case on Open Source. The default wishlist may not exist until the first add.
• Skipping the add-product event in custom code. Other modules may depend on it.
• Returning image paths that don't work on your setup. Media paths differ between stores and CDNs.
• Letting guests in. A wishlist belongs to a customer, so require sign-in.
• Using a tutorial's module unchanged in production. Review it, test it and adapt it.
• Disabling GraphQL modules you rely on. Hyvä's documentation lists the wishlist GraphQL module among those its theme needs, and notes that stores coming from Luma often have unused GraphQL modules disabled. If you use a Hyvä storefront, check that they're enabled. Our post on Hyvä going open source covers the current licensing picture.

What most guides miss

Most wishlist API guides jump straight to code. After reading the current results, three gaps stand out.

They skip the GraphQL route. Many tutorials assume you must build a REST module, and never mention that Adobe documents a full set of wishlist GraphQL mutations. For a client that can use GraphQL, that's often the least work.

They ignore the edition difference. The one-list-versus-many-lists rule and the ID-0 first-use behavior on Open Source affect real client code, yet they're easy to miss.

They don't separate customer access from integration access. A mobile app and an ERP need different kinds of credentials. Treating them the same either breaks the app or over-exposes the store.

There's a fourth point that's less about code. Several of the pages we read were written years ago, including the Stack Exchange answers and the original GitHub request. The wishlist query's deprecation in Adobe's docs is a reminder to check the date on whatever you follow.

How do you choose the right option?

Choose GraphQL if your client can use it, a custom module if you need exact routes and have developers to maintain them, community code if you want a head start and will review it carefully, and a paid extension if you'd rather buy a packaged solution and rely on vendor support. Match the choice to who maintains it.

A simple way to decide:

• Your client speaks GraphQL already. Use Adobe's wishlist mutations and add nothing to Magento.
• Your client is REST-only and your needs are standard. Compare paid extensions, or review a community module.
• Your client is REST-only and your needs are unusual. Commission a custom module and plan for upgrade testing.
• You have no developers to maintain code. Prefer a supported extension, or a maintenance agreement for a custom module.
• You're building a headless store. Decide once which API style the whole front end will use, then fit the wishlist into it.

If you're planning something larger around a mobile app or headless store, our Hyvä vs PWA Studio comparison explains how two common front-end paths differ.

Conclusion

The short version: Magento 2 has no documented core wishlist REST endpoint, but it does have a documented GraphQL wishlist API, and there are three more routes if you need REST. Start by asking what your client can speak and who will maintain the code.

If GraphQL fits, use it. If you need REST, compare a custom module, community code and paid extensions using the checklists above, and test every route with real tokens before launch. If you'd like a packaged option, look at WebbyTroops' Wishlist REST APIs extension, and read its product page in full before buying.

Last verified: 30 September 2026. Prices, listings and documentation change, so re-check vendor pages and Adobe's documentation before you build.