GraphQL API Regression – Missing Posted Date on Refunds & Transaction Visibility Issues

GraphQL Admin API Troubleshooting
1

1) Missing Posted Date in GraphQL (Possible API Regression?)

  • In the REST API, I can retrieve a posted date for refunds.
  • In the GraphQL API, however, the posted date is missing.
  • This occurs on the overall refund object, not on refund line items.
  • The refunds in question are standard webshop refunds initiated in Shopify.

Is this an intentional difference between the APIs, or has this been a regression? If intentional, is there another way to retrieve the posted date via GraphQL?

2) No Transactions for Certain Refund Events

  • I understand that some refund events may not have an associated transaction.
  • However, how can I determine why a refund has no associated transaction?
  • Is there a specific way to confirm whether a refund was a non-monetary refund (e.g., store credit, manual adjustment)?
2

Hi,

For question 1, is this the posted date field that you’re not able to access data for with GraphQL:

638×187 25.8 KB

For 2:

Would querying the SuggestedRefund object get you info on non-monetary refunds?

3

Hi @Liam-Shopify thanks for the quick reply

  1. Yes that is correct field we are looking for.
    But that field does not exist within the Order - GraphQL Admin in GraphQL even though it is in the rest API. see link.

Rest API

image
image827×365 66.3 KB

The only way to find it is to refunds.refundLineItems.Transactions BUT that is not always present so can not be relied on, hence my 2nd question.

Querying the Order.Refunds to get all refund events that have taken place

image
image485×149 9.25 KB

  1. I do not think suggested refunds help, as this is before the refund has taken place.
    For context we are only trying to read information in an external system not write anything. My situation is I am trying to read all refund events and only some have a transaction.
4

So in the docs, the suggested alternative for refunds.processed_at is orderTransaction.procesedAt - but you’re using the Refund object which has a transactions field that lets you access processedAt.

So first off, maybe our docs need to be corrected to use this as the alternative instead of orderTransaction.procesedAt?

On REST is there always be a value for refund.processed_at even if it’s a store credit transaction?

5

Hi @Liam-Shopify

Not sure I understand what you are saying on part 1.

Re Part 2, yes there is always a refund.processed_at
I can give you a specific Order to validate it your end as I have the JSON in both rest and graphql which shows the same order shows up differently depending on the data set.

Just let me know what details you need.

6

Hi again,

So we recommend using orderTransaction.procesedAt as a replacement for refund.processed_at - can confirm this won’t work for you?

548×151 45.6 KB

7

Hi @Liam-Shopify but Order.transactions are not always available for refunds. So what should we do in this situation? This is why I say this is a large regression between Rest & GraphQL

In Rest API, there is always a Refunds.ProcessedAt

  • The Transactions existed in rest API, but at least if not present the user can rely on the Refunds.ProcessedAt

How are we supposed to handle this then in GraphQL.

Also I still do not have an answer to my first post point 2 please.

8

This does seem like a gap in the GraphQL API - I’ve connected with the relevant team and will ask for their recommendation.