[Breaking Changes] Aptos Event APIs Added, Aptos Webhook Improvements & Transaction API Updates

Posted on January 15, 2026

Update on February 3, 2026

🚧

Schedule Change

We apologize for the delay. We’re taking additional time to validate the update for stability and data accuracy.
The changes in this notice will now take effect on February 20, 2026.

Aptos event querying and Webhook payload formats are being updated to improve developer experience and data clarity. This update introduces two new Event APIs and provides more accurate fee payer signature information in Aptos Webhooks.

What’s Changing

✅ New: Aptos Event APIs Added

The following APIs are newly added:

• Get Events By Type
• Get Events By Account

The Event schema previously available through the Aptos Indexer API will no longer be provided for event queries.
Instead, you can query events using the new Event APIs with a unified experience across event types.

The Aptos Indexer API Event schema is not being removed on February 3, 2026.
Any deprecation timeline and removal plan will be shared in a separate announcement.

Recommended Actions

• Migrate Aptos event queries to the new Event APIs
• Remove dependency on the Indexer Event schema

✅ Improved: More Accurate Webhook (Transaction Event Only)

Aptos Webhook payloads will return more accurate fee payer signature details and cleaner payload structures:

• signature.type is normalized for transactions that include a fee payer
• For some signature types, public_key and signature can be returned as structured objects
• Multisig payloads return actual values and omit unnecessary empty fields

This update affects only Aptos Webhook subscriptions that include the Transaction event type.
If you subscribe to the Event event type only, no action is required.

Recommended Actions

• Update Webhook parsers to handle signature.type = fee_payer_signature
• Support public_key / signature fields as either a string or an object depending on signature type
• Optionally leverage the new fee payer and secondary signer fields if needed

✅ Updated: Aptos Data API Transaction Field Type Unified

For consistency across Aptos Data APIs, the data types of the following fields in transaction responses will be updated:

• blockHeight: string → integer
• blockTimestamp: string → integer

This change applies to the following APIs:

• Get Transactions By Versions
• Get Transaction By Version
• Get Transaction By Hash
• Get Transactions In Block
• Get Transactions By Hashes
• Get Transactions By Account

Recommended Actions

• Update client-side parsers to expect integer values for blockHeight and blockTimestamp
• Review any logic that assumes these fields are strings (e.g., serialization, comparisons)

1. New Aptos Event APIs

Aptos Events have historically required different query methods depending on event type:

• Module event types → Indexer API
• Legacy event types (event-handle) → Node API

With the new Event APIs, you can query both module events and legacy(event-handle) events through the same interface.

As-is

To fetch Aptos Events, you needed to choose APIs based on event type:

• Module events → use Indexer API
• Legacy (event-handle) events → use Node API

As a result, event querying often required maintaining multiple query paths and separate response handling.

To-be

Events can now be queried via the new unified Event APIs:

• Get Events By Type
• Get Events By Account

These APIs support both module-based and legacy(event-handle) event types, so you no longer need to switch between Indexer and Node APIs.

Action Required (Aptos Event APIs)

If your integration currently queries Aptos Events:

1. Replace event queries with the new APIs:
   • Use Get Events By Type when the event type is known
   • Use Get Events By Account when you want events scoped to an account
2. Remove dependency on the Indexer Event schema for event queries
3. Simplify event-query logic by using the new Event APIs only (no need to branch by module vs. event-handle event types)

2. Aptos Webhook Changes (Transaction Event Only)

These changes apply only to Aptos Webhook subscriptions that include the Transaction event type.
They provide more accurate fee payer signature information and a more explicit structure for certain signature and multisig payload fields.

Changes Summary

2-1) type (Fee Payer Transactions)

When a transaction includes a fee payer, the signature type is now returned as fee_payer_signature.

2-2) public_key, signature (Keyless/Fee Payer Transactions)

For keyless transactions that include a fee payer, the signature object becomes more explicit and structured.

As-is

{
  "type": "single_sender_keyless_signature",
  "public_key": "0x1b68...",
  "signature": "0x0000c69c..."
}

To-be

{
  "type": "fee_payer_signature",
  "fee_payer_address": "0x6d3e0c4576274ce99f20958925edaf74412b850ce01fb933deb4b70509f62d0a",
  "fee_payer_signer": {
    "public_key": "0xcac0431f...",
    "signature": "0x19abd661...",
    "type": "ed25519_signature"
  },
  "secondary_signer_addresses": [],
  "secondary_signers": [],
  "sender": {
    "public_key": { "type": "keyless", "value": "0x1b68..." },
    "signature": { "type": "keyless", "value": "0x0000c69c..." },
    "type": "single_key_signature"
  }
}

Key updates:

• New fee payer fields are included:
  • fee_payer_address
  • fee_payer_signer
• Secondary signer fields are included when applicable:
  • secondary_signer_addresses
  • secondary_signers
• For special signature types (e.g., keyless), public_key and signature can be returned as {type, value} objects

2-3) type_arguments (Multisig Payload Transactions)

For multisig_payload transactions, type_arguments now returns actual values instead of an empty array.

As-is

{
  "payload": {
    "type": "multisig_payload",
    "transaction_payload": {
      "function": "0x1::aptos_account::transfer_coins",
      "type_arguments": [],
      "arguments": []
    }
  }
}

To-be

{
  "payload": {
    "type": "multisig_payload",
    "multisig_address": "0xba1b149ab806c3e9d5573fa697b54d228f159dfeee9cef84bbba9710aa9d9e4e",
    "transaction_payload": {
      "function": "0x1::aptos_account::transfer_coins",
      "type_arguments": ["0x1::aptos_coin::AptosCoin"],
      "arguments": [...]
    }
  }
}

2-4) transaction_payload (multisig_payload null case)

When transaction_payload is null, unnecessary empty fields(e.g., type_arguments, transaction_payload) are no longer included.

As-is

{
  "payload": {
    "type": "multisig_payload",
    "multisig_address": "0xaea4...",
    "type_arguments": [],
    "transaction_payload": {
      "function": "",
      "arguments": []
    }
  }
}

To-be

{
  "payload": {
    "type": "multisig_payload",
    "multisig_address": "0xaea4..."
  }
}

Action Required (Aptos Webhook)

If your integration parses Aptos Webhook payloads:

1. Update logic to handle signature.type = fee_payer_signature
2. Parse public_key and signature as either:
   • a string ("0x..."), or
   • an object ({type, value}) for special signature types
3. Optionally adopt the new fields when fee payer transactions are relevant:
   • fee_payer_address
   • fee_payer_signer
   • secondary_signers

3. Aptos Data API Transaction Field Type Change

To improve consistency across Aptos Data APIs, the data types of certain transaction fields are updated.

Changes Summary

Examples

As-is

...
"blockHeight": "384675329",
"blockTimestamp": "2025-07-15T06:21:36.293Z",
...

To-be

...
"blockHeight": 384675329,
"blockTimestamp": 1752560496293,
...

Affected APIs

This change applies to the following APIs:

• Get Transactions By Versions
• Get Transaction By Version
• Get Transaction By Hash
• Get Transactions In Block
• Get Transactions By Hashes
• Get Transactions By Account

Action Required

If your integration consumes transaction responses from Aptos Data APIs:

1. Update parsers to treat blockHeight and blockTimestamp as integers
2. Review any logic that relies on string-based timestamps (e.g., ISO 8601 parsing)