App Purchase Vault Get Pro — €3.49
Takeout · Technical

Google Play Purchase History.json Explained

Purchase History.json is the heart of a Google Play Takeout export: the machine-readable list of what you acquired and when. This page explains its role and general structure — with an important caveat about guarantees.

Updated: September 2026 · By the App Purchase Vault project · 6 min read

First, the caveat: no published schema

Google does not publish a formal, versioned schema for the Play Takeout files. Everything below describes the structure as observed in real exports — ours and those documented by the community. Fields can differ between accounts, content types and time periods, and Google can change them without notice. Any statement here is "typically present", never "contractually guaranteed".

What the file is for

Within the Google Play Store folder of your export, Purchase History.json records acquisitions: apps and games you got, in-app purchases you made, subscriptions you started. Think of it as the what and when. The how much typically lives in the sibling file, Order History.json, which holds the transaction ledger — amounts, currency, payment and refund related fields.

General structure

The file is a JSON array of records. Each record describes one acquisition and typically carries:

Price and payment details are usually not in this file — that's Order History's job. Joining the two is how you get "name + date + price" for a purchase.

A fictional example

The snippet below is invented for illustration — it is not real user data, and it is a simplified sketch, not a promise about field names. A real export may nest or name things differently:

[
  {
    "purchase": {
      "document": {
        "type": "Android App",
        "title": "Example Launcher (fictional)"
      },
      "purchaseTime": "2019-04-12T14:23:00Z",
      "purchaseType": "App"
    }
  },
  {
    "purchase": {
      "document": {
        "type": "In-app item",
        "title": "Example Game - Coin Pack (fictional)"
      },
      "purchaseTime": "2021-11-02T09:05:00Z",
      "purchaseType": "In-app purchase"
    }
  }
]

Apps, IAP, subscriptions

In observed exports, the purchase-type information is what lets you separate the three big categories people care about:

CategoryWhat a record representsWatch out for
Apps & gamesOne-time acquisition of an app or game (paid or free)Free apps may appear too — acquisition ≠ payment
In-app purchasesItems bought inside an appThe record names the item; the parent app may need inference from the title
SubscriptionsSubscription-related eventsRenewals vs. the initial subscription can be recorded differently; check Order History for amounts

Fields a viewer should ignore

Order History.json can carry payment-method related fields. A well-behaved viewer or parser should drop these during parsing — never display them, never store them. The useful history is "what, when, how much". Card details add nothing to that and everything to the risk.

The same discipline applies to sharing: a purchase history is personal data. Keep exports local, and treat any tool that wants to upload them with suspicion.

How we use thisApp Purchase Vault (in pre-launch) parses exactly these files on your phone: Purchase History for items and dates, Order History for amounts — with sensitive payment fields discarded at parse time. The tolerance for schema variation described above is a design requirement, not an afterthought.

Skip the JSON.

App Purchase Vault is in pre-launch: pick the ZIP, get a searchable archive. On-device only.

See the idea