Alternative API/SDK to the Shopify Ajax API

Alternative API/SDK to the Shopify Ajax API

Zelf
Shopify Partner
40 0 17

I'm currently using the Shopify Ajax API, but have confirmed with Shopify that they have issues that randomly occur, with this API, that may cause the line item properties on items programmatically added to the Shopify cart to just disappear at some point during the checkout. We cannot replicate and have been trying for well over a year. We can only confirm that our line item properties exists when they are added to the cart and then at some point during the Shopify checkout process that Shopify is removing line item properties randomly on their side.

 

We've been using the Shopify Ajax API for years and can confirm that this behavior, where line item properties (not line items) on items just disappear, during the checkout process, after having successfully added to the cart is happening. Out of several hundred orders/day it happens less than a dozen times a day and there is no rhyme or reason to why this is happening. Again, Shopify support has confirmed this is an issue on their side.

 

Further, Shopify support has told me that because the issue happens so randomly, that they do not intend to commit any resources to the small dev team at Shopify that work on this the Ajax API to resolve it.

 

The suggestion I received is to poll the community here for a more current alternate API to the Ajax API for programmatically adding line items to the cart that have line item properties. That  being said, below is my current flow for adding items, from a 3rd party site, using the Shopify Ajax API and an app proxy url. Please lmk if you have a suggestion for a replacement using a more current API then the Ajax API to do what I need. The most important point here, that I've put in bold, is that the line items have specific line item properties. So I'm not just adding line items to the cart.

 

Why line item properties are critical for my use case: These line item properties are used by back end systems that require specific data on the line items to be able to manufacture a given line item, such as a name or a link to programmatically created image the user designed for the line item.

 

Current flow using the Shopify Ajax API and an app proxy url:

 

1. Users come from a 3rd party (not Shopify) site, where they have tapped a button that POST's data to a Shopify app proxy url on our Shopify store.

2. The proxy url loads our proxy app, which parses the POST data and then uses the Shopify Ajax API to first remove (Update endpoint /cart/update.js) any items coming from the 3rd party site that are no longer valid, then we (Add endpoint /cart/add.js) to add line items with their line item properties to the Shopify cart. We do not clear any items that were added on Shopify, just items with specific line item property flags coming from the 3rd party site.

 

Hope that makes sense. Any thoughts on alternatives to the Shopify Ajax API to accomplish our flow coming from a 3rd party site? Think Buy Now button, but on steroids.

 

E.g. can I use the Storefront API with an app proxy url to POST line items and their properties and create a cart using a customer's session?

Replies 4 (4)

PaulNewton
Shopify Partner
6910 619 1455

Be sure to ask in the partners slack channel(found through partner dashboard, or the shopify devs discord. 

 

Using the draft orders api and just sending them directly to checkout is probably the sanest approach.

Or test if LIPs can somehow be put into a checkout-link ,formerly cart-permalink's , then just build those links and probably skip the proxy-app all together; tho afaik LIPS dont work with permalinks 🤔.

There's also just constructing the full single ajax cart using the /add endpoint to create a cart > then send customers to the some interstitial page on the shopify site >  then redirect to checkout.

 

Have you experienced this data loss behavior with cart attributes or checkout attributes?

 

Using cart-attributes as a fallback would be the first things I'd put in place along with a backend process that edits invalid orders that don't match a checksum of those attributes. This approach is based on an assumption that the shopify online-sales channel isn't really meant to be used for editing the cart by the visitor, otherwise it can become a chore to create frontend checks to keep both cart-attributes and LIP's in sync with each other.

 

Some other questions to test against while figuring out if a rework is going to happen:

  • Have you experienced this data loss behavior for line item properties(LIPs) when a third party site(3PS) or proxy app is not involved? Assuming the 3PS sends directly to checkout.
  • Does this correlate to when the user is not just on the third party site itself but also on the shopify site itself and may have a page/tab/window with a cart-drawer or be on the /cart page itself?
  • Does this correlate to when different ajax endpoints are used i.e. /change vs /update vs /add
  • Does this behavior still happen if you just completely clear the cart with /clear  
  • What type of LIPS are involved: characters and what length of text, unicode, emojiis,  or  files(image uploads), etc.
  • Are LIP inputs being sanitized or normalized.

 

 

 

 

Contact paull.newton+shopifyforum@gmail.com for the solutions you need


Save time & money ,Ask Questions The Smart Way


Problem Solved? ✔Accept and Like solutions to help future merchants

Answers powered by coffee Thank Paul with a Coffee for more answers or donate to eff.org


Zelf
Shopify Partner
40 0 17

Some really great thoughts here. No, I've not tried adding cart attributes or checkout attributes via the Shopify AJAX API, only adding LIPS. That is certainly the easiest fix if that doesn't get randomly stripped out like line item properties. I will definitely be testing that theory. If cart attributes persist we'd be able to retrieve them on each order for our backend systems no problem.

 

The 3PS does not send the user directly to checkout. It dumps the user to their cart. Reason being, we want the user to be able to add products from the Shopify store that are not required to be custom built on the 3PS. For this reason we have not gone the create permanent checkout link route. We also want the user to have that Cart with all the line items and LIPs to serve as an echo that the 3PS has added all the right data to fulfill their order.

 

Shopify support said they were able to replicate this issue when certain conditions existed like different tabs with the Shopify cart open. We attempted a couple of fixes they recommended, but were unsure about and both failed to handle this session issue. And they were not entirely sure that sessions and tabs were the root cause either.

 

We have not tested completely clearing the cart with /clear, because users often have added items from Shopify that are not coming from 3PS to their cart. So our app proxy url parses the current cart and only handles items added by the 3PS leaving non-3PS items alone.

 

The LIPS have minimal data and include information such as first and last name and short url links to images that were built on the 3PS, as well as a nonce id that is used to attach completed Shopify orders to the verbose data required to manufacture a product coming from the 3PS. So very minimal data in the LIPS and mostly for customer service to quickly see info about what the user created on the 3PS.

 

One workaround we created is that on the 3PS we now require the user to enter their email, which becomes part of the nonce data, in the hopes that the user will use the same email to checkout on Shopify as they entered on the 3PS. So, when an order comes through missing LIPS we can then easily reattach the Shopify order with the nonce on our backend systems by matching emails, but the user's Shopify email does not always match the email they enter on our 3PS.

 

All LIPs are being sanitized and normalized. 99% of the orders coming from the 3PS have zero issues, and we also have validation that the LIPS exist as part of the Shopify AJAX API /add, when the user is dumped to their Shopify cart. We also have realtime reporting if a user ever has a failed attempt adding LIPs from the 3PS using Slack webhooks on the app proxy url, and this webhook never fires, because it never happens. The LIPS are being lost by Shopify or something the users are doing during the checkout process, but not as a result of the 3PS using the Shopify AJAX API to update/add to the Shopify cart. It is probably the worst bug I've had to deal with because we don't have access to Shopify logs and can't debug their systems. If we did, this would have been resolved long ago.

 

I'm going to test cart attributes using the Shopify AJAX API, in addition to LIPS and I'll post here if that works.

 

Do you have any experience with the Storefront API? It appears to create a permanent checkout url only, so that probably wouldn't work for our use case anyway, where we want users to be able to add Shopify products, in addition to line items with LIPs coming from the 3PS. I.e. the user needs to be able to shop on Shopify after adding items from the 3PS to their cart, including the ability to return to the 3PS, make adjustments on the 3PS, and update their Shopify cart leaving Shopify directly added products alone. Users often bounce back and forth between the the 3PS and their Shopify items.

 

I will make a post in Slack Partner community to this issue and checkout discord as well. Again, thanks for taking time to provide some great food for thought on this issue.

Zelf
Shopify Partner
40 0 17

FYI, @PaulNewton, we have updated our Shopify AJAX API script to add, in addition to current LIPs, cart attributes with our nonce id's. Now we just have to wait until Shopify randomly removes LIPs to see whether the cart attribute will persist. Again, thanks for the food for thought. We'll post an update here once we can verify this is a solid workaround for this Shopify issue or not.

Zelf
Shopify Partner
40 0 17

@PaulNewton adding cart attributes did not work. We just had an order come in where the LIPs are stripped and the cart attribute is stripped as well. So back to the drawing board.