# Transaction and wallet audit records, compressed payloads, and `jsonData` deprecation

**Published September 21, 2026.**

Audit records delivered to your AWS Data Firehose stream now carry their payload as Brotli-compressed bytes in a new `compressedJsonData` field, on every record type. Production records have carried it since September 17, 2026.

The same contract covers two record types beyond the access records (`type: 1`) your stream carries today: transaction (`type: 3`) and wallet (`type: 4`) lifecycle records. Lifecycle records are active in Development, and Ripple enables them in Sandbox and then Production.

This notice **deprecates** the uncompressed `jsonData` field.

Action required for Firehose consumers
Read the payload from `compressedJsonData`. Consumers that read `jsonData` keep working during the deprecation window, but only for access records. Transaction and wallet records never carry `jsonData`, so a `jsonData`-only consumer misses the new lifecycle payloads without seeing an error.

## New transaction and wallet records

When Ripple enables transaction (`type: 3`) and wallet (`type: 4`) records in your environment, they start to arrive in your Firehose stream alongside access records. Prepare your consumer before they arrive:

- Wallet-as-a-Service doesn't backfill historical events. Lifecycle records start from activation.
- All record types arrive on the same stream. Filter on `type`, and don't assume that every record is an access record.
- Expect higher record volume. One transaction can produce a record for each status change.


For the `source` values that each record type uses, see [Source values](/products/wallet/admin-guide/firehose-audit-log-reference#source-values).

## What changed in the record format

| Field | Status |
|  --- | --- |
| `compressedJsonData` | **New.** Base64-encoded Brotli-compressed JSON payload bytes. The canonical payload for access, transaction, and wallet records. |
| `compressionAlgorithm`, `compressionVersion`, `compressionQuality` | **New.** The codec (`br`), contract version (`1`), and encoder quality (`6`). |
| `originalJsonDataSize`, `originalJsonDataSha256` | **New.** The byte length and SHA-256 of the uncompressed payload, for integrity checks. |
| `legacyJsonDataTruncated` | **New.** Present and `true` only when Wallet-as-a-Service rebuilt an oversize access payload without `request.body`. |
| `jsonData` | **Deprecated.** Base64-encoded uncompressed JSON payload bytes. Wallet-as-a-Service emits it on access records only, it might be absent, and Ripple removes it after the deprecation window. |


The envelope fields `id`, `orgId`, `type`, `userId`, `deviceId`, `requestId`, `source`, `receivedAt`, and `createdAt` keep the same meaning.

## Deprecation timeline

- **Deprecation starts on publication of this notice, September 21, 2026.**
- **Removal is no earlier than October 21, 2026**, a minimum of 30 days after publication, and happens only after Ripple confirms that known consumers have migrated.
- Ripple announces the removal date before it takes effect.


## Migrate

1. Base64-decode `compressedJsonData`.
2. Brotli-decompress the result.
3. Parse it as JSON — the payload is identical to what `jsonData` carried for access events.
4. Optionally verify the decompressed length against `originalJsonDataSize` and its SHA-256 against `originalJsonDataSha256`.
5. Stop reading `jsonData`, and handle records where it's absent.


For worked examples in Node.js and Python, the full field reference, and the before-and-after record shapes, see [Firehose audit log reference](/products/wallet/admin-guide/firehose-audit-log-reference#decode-the-payload).

## Size limits and delivery behavior

A Firehose record must stay below 1,000,000 encoded bytes, counting the complete record with both payload representations.

- When a complete encoded access record reaches 1,000,000 bytes, Wallet-as-a-Service clears `request.body`, rebuilds both payload representations from the reduced payload, and sets `legacyJsonDataTruncated` to `true`. The compression metadata then describes the reduced payload.
- If the record still doesn't fit, Wallet-as-a-Service can't deliver it, and you need to contact support.
- If delivery keeps failing, Wallet-as-a-Service disables the Firehose configuration until you re-enable it in **Settings** > **Audit logs**.


## Related

- [Firehose audit log reference](/products/wallet/admin-guide/firehose-audit-log-reference) — full record reference, decode examples, and delivery guarantees
- [Configure audit logging](/products/wallet/admin-guide/configure-audit-logging) — set up and manage the Firehose connection