Create draft order via POS extension

Hi,

I need to create a draft order from an existing order via a POS extension. I’m currently using the draftOrderCreateFromOrder admin API endpoint to do this, but am unable to see the new draft in the POS app.

I saw some old posts indicating that this might be due to the source value of the draft order causing it to be filtered out. Can anyone confirm if this is the root of the problem? If so, is there any way I can modify the draft order so that it becomes visible in the POS?

Thanks,

Paul

Hey @P_Mac - thanks for reaching out.

Just confirming what you found in those older threads. The Drafts list in POS only surfaces drafts that were created in POS or directly in the admin (that’s the “Sale type: POS / Admin” filter you see there). Anything created through the Admin API, including draftOrderCreateFromOrder, gets attributed to the app that made the call, so it’s filtered out. Liam confirmed this a while back here as well: Creating POS Orders via API / Draft Order Visibility - #2 by Liam-Shopify

Right now, there’s not way to change that after the fact unfortunately. DraftOrderInput and draftOrderUpdate don’t expose a source field, so right now, you can’t flip an API-created draft into one POS will pick up. I definitely get that’s not super ideal.

That said, since you’re working from inside a POS extension there may be a way around it depending on what you’re actually trying to accomplish. A few questions so I can point you in the right direction:

  • What’s the end goal for the draft once it’s created? For example, is staff meant to load it and take payment right away on the same device, or does it need to sit there so someone can pick it up later (possibly from a different register or location)?
  • Which target is your extension rendering from - pos.order-details.action.render, a home tile/modal, or something else?
  • Is there anything the draft needs to carry over from the original order beyond line items and the customer - things like custom items, discounts, notes, or shipping?

Depending on the answers, one direction that might work is skipping the draft entirely and using the Cart API to rebuild the cart from the original order directly in POS (if that would work for you) - staff could then check out or save it as a POS-sourced draft from there. But I’d rather understand the flow first before suggesting that, since it doesn’t fit every case.

Hope to hear from you soon!

Thanks for the quick response @Alan_G. Just a pity it’s not the answer I was hoping for.

Unfortunately, I’m not sure the alternative approach you suggested will work for us. Our extension is rendering from the pos.purchase.post.action.render target which, as far as I can tell, doesn’t have access to the Cart API.

Out of interest, do you happen to know why app source drafts are filtered from the POS? Also, are there any plans to alter this behaviour?

Hey @P_Mac - you’re right: pos.purchase.post.action.render doesn’t have access to the Cart API, so the approach I mentioned wouldn’t work directly from that screen, apologies for the confusion there.

I also need to correct one detail from my earlier reply: DraftOrderInput does expose a sourceName field. It’s documented for sales-channel attribution, though—not as a way to make an app-created draft appear in the native POS Drafts list. So that doesn’t give us a supported workaround for the visibility issue.

On why app-created drafts are excluded, I don’t have a confirmed explanation to share, and I can’t confirm whether a change is planned. I’ll check on our end rather than speculate about the reasoning or give you an expectation I can’t back up.

To help with that follow-up and understand whether another approach could fit:

  • Does this need to happen directly from the post-purchase screen, or could staff reopen the completed order and trigger the action from its order-details screen?
  • What’s the draft used for after creation—another purchase straight away, or something staff need to retrieve later, potentially from another register or location?
  • Does it need to preserve the original pricing, discounts, custom items, notes, or shipping, rather than just the products and customer?

The order-details target does support the Cart API, so rebuilding a cart there may be an option if that workflow fits. I definitely get that adding another staff step isn’t equivalent to making your existing drafts visible, though, and I don’t want to steer you toward it if it won’t meet your needs.

Hope to hear from you soon on this.

Hi @Alan_G,

we’re using the post-purchase screen to automatically present a modal that highlights any issues with a newly created order and allows staff to easily cancel and recreate it. We were hoping to streamline this process by creating a draft from the original order so that staff don’t need to manually re-add all relevant details. Triggering this process from the order-details screen won’t work unfortunately as it requires a manual step that can easily be forgotten.

Ideally we’d like to add validation to the checkout process so that invalid orders don’t get created in the first place but the POS doesn’t currently allow this.