Our Partner & Developer boards on the community are moving to a brand new home: the .dev community forums! While you can still access past discussions here, for all your future app and storefront building questions, head over to the new forums.

Re: Set date for fulfillments and refunds through Admin API

Solved

Set date for fulfillments and refunds through Admin API

brandon_k
Shopify Partner
8 0 2

I'm importing historical data from a different ecommerce system into Shopify via the Admin REST API, but am running into an issue with the dates for fulfillments and refunds. I'm able to set the `processed_at` value on the order to properly represent when the order was placed, but when adding in our fulfillment and refund data, there doesn't seem to be any such field according to the docs for Fulfillment and Refund. I tried manually setting the `created_at` and `updated_at` fields in hopes that might get around it (especially since the Fulfillment docs don't mark them as read-only), but they're set at the date and time that the API request was made. This ends up creating inconsistent data and completely throws off any reporting.

 

How can I manually set these dates for fulfillments and refunds?

Accepted Solution (1)

Liam
Community Manager
3108 342 884

This is an accepted solution.

Hi Brandon,

 

After looking into this, it does seem that it's not possible to update the created_at and updated_at timestamps for Fulfillments and Refunds via the API. These timestamps are automatically assigned by Shopify at the time the API request is made and can't be manually changed.

 

I believe this limitation is in place to maintain the integrity of the transaction history in Shopify. The created_at and updated_at fields are designed to accurately reflect the timeline of events as they occur within the Shopify system. If the exact timing of historical fulfillments and refunds is critical for your reporting, I'd suggest storing this data externally and then merging it with your Shopify data for reporting purposes.

 

Hope this helps,

Liam | Developer Advocate @ Shopify 
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution
 - To learn more visit Shopify.dev or the Shopify Web Design and Development Blog

View solution in original post

Replies 4 (4)

Liam
Community Manager
3108 342 884

This is an accepted solution.

Hi Brandon,

 

After looking into this, it does seem that it's not possible to update the created_at and updated_at timestamps for Fulfillments and Refunds via the API. These timestamps are automatically assigned by Shopify at the time the API request is made and can't be manually changed.

 

I believe this limitation is in place to maintain the integrity of the transaction history in Shopify. The created_at and updated_at fields are designed to accurately reflect the timeline of events as they occur within the Shopify system. If the exact timing of historical fulfillments and refunds is critical for your reporting, I'd suggest storing this data externally and then merging it with your Shopify data for reporting purposes.

 

Hope this helps,

Liam | Developer Advocate @ Shopify 
 - Was my reply helpful? Click Like to let me know! 
 - Was your question answered? Mark it as an Accepted Solution
 - To learn more visit Shopify.dev or the Shopify Web Design and Development Blog

brandon_k
Shopify Partner
8 0 2

Thanks, Liam.

It's unfortunate to find there's no way to set the date for those historical transactions, but it definitely makes sense to not be able to set the `created_at` and `updated_at` fields. I appreciate you looking into this and confirming.

docasar
Shopify Partner
10 0 1

Hi, while it seems that for fulfillment there is not process_at, for refunds it is there. Have you tried to used the processed_at instead of created/updated_at? For orders works. I am finding the same issue for transactions for payments, that it is not taking the processed_at.

brandon_k
Shopify Partner
8 0 2

Thanks for pointing out the processed_at on the refunds. I don't know how I overlooked that. For my use case, we've taken a different approach to refunds since we encountered some other issues that brought about other problems that couldn't be overcome. It's great to see the processed_at option for refunds, though.