Purge Order Data

What you’ll learn

In this article you’ll learn how to use the GraphQL purgeOrderData mutation to purge PII and other forms of sensitive information from orders and their associated entities. We’ll cover

• Solution specifics
• The data that you can purge
• How to run the mutation to purge data

Solution Specifics

Before reading further, there are some important call outs on the solution that you should be aware of:

• This is an API only solution - there is currently not an equivalent feature in the Operator Portal
• Only Full Admins can execute this mutation (this privilege is derived from the account that created the API key being used)
• You cannot “un-purge” data, it is a 1-way operation
• We don’t ever purge the order / transaction, only relevant attributes on the order (and associated objects, e.g. invoices and line items etc.)

Purgeable Data

The following classifications of data can be purged:

ExternalIDs

By setting the purgeExternalIds input to true, we purge:

• ExternalIds on the Order
• ExternalIds on the associated Invoice objects
• ExternalIds on the associated LineItem objects
• ExternalIds on the associated Shipment objects

Metadata

By setting the purgeMetaData input to true, we purge:

• Metadata on the Order
• Metadata on the associated Invoice objects
• Metadata on the associated LineItem objects
• Metadata on the associated Shipment objects

Notes

By setting the purgeNotes input to true, we purge:

• Notes on the Order (this field is not retrievable via GraphQL but is nonetheless purged)
• note field on the Shipment objects associated to the Order
• Set the value of the content field on the InvoiceAnnotation object to “purged”
• attachments on the RefundRequest objects associated to the Order
• attachments on the ReturnShipment objects associated to the Order
• attachments on the RefundRequestNote objects associated to the Order
• note field on the RefundRequestNote objects associated to the Order
• reason on the RefundRequestLineItem objects associated to the Order
• denyRefundReason on the RefundRequestLineItem objects associated to the Order

Order Details

By setting the purgeOrderDetails input to true, we purge:

• address on the Order
• billingAddress on the Order
• emailAddress on the Order
• firstName on the Order
• surname on the Order
• phone on the Order
• companyName on the Order
• billingAddress on the Order
• billingCompanyName on the Order
• billingEmailAddress on the Order
• billingFirstName on the Order
• billingPhone on the Order
• billingSurname on the Order

Running the Mutation

The following example details:

• Purging data for 1 order, (you can supply multiple ids if you like)
• Purging data for all 4 of the category types (you have to provide at least 1)

mutation{
  purgeOrderData(input:
    {
      orderIds:["T3JkZXItMTEzODM="]
      purgeNotes: true
      purgeMetadata: true
      purgeExternalIds: true
      purgeOrderDetails: true
    }
  )
  {
    errors{
      field
      messages
    }
  }
}

Aside from returning any potential errors, there isn’t a dedicated return object type for this mutation. To understand the effect of running this mutation you can use any number of the existing queries that return orders. An example node query is shown below that returns a selection of the impacted fields for the order id we supplied above:

query {
  nodes(ids: ["T3JkZXItMTEzODM="]) {
   ... on Order {
    id
    surname
    address {
      address
    }
      companyName
      phone
    }
  }
}

And the example return payload looks as follows:

{
  "data": {
    "nodes": [
      {
        "id": "T3JkZXItMTEzODM=",
        "surname": "",
        "address": null,
        "companyName": null,
        "phone": ""
      }
    ]
  }
}