---
title: "Report Transaction"
method: POST
path: "/v0/bitcoin/transaction/report"
tags: ["Bitcoin"]
deprecated: true
---

# Report Transaction

`POST /v0/bitcoin/transaction/report`

> **Deprecated.**

Submit an appeal or false-positive report for a Bitcoin transaction scan. Use when you believe a scan result was incorrect (e.g. should_be_benign, should_be_malicious, wrong_simulation_result).

## Request body

- BitcoinReportTransactionRequest
  - `event` 'should_be_malicious' | 'should_be_benign' | 'wrong_simulation_result', required — Reason for the appeal: false positive (should_be_benign), false negative (should_be_malicious), or incorrect simulation (wrong_simulation_result).
  - `report` union, required — Either a prior scan request ID or the full transaction parameters being reported.
    - BitcoinAppealRequestId
      - `type` 'request_id' — Discriminator; use "request_id" when referencing a prior scan.
      - `id` string, required — Request ID from a previous transaction scan response.
    - BitcoinAppealTransactionDataReport
      - `type` 'params' — Discriminator; use "params" when supplying full transaction data.
      - `params` BitcoinTransactionScanRequest, required
        - `chain` 'bitcoin', required
        - `options` BitcoinOptions[] — Which parts of the response you need: - **validation** — Security verdict (Benign/Warning/Malicious) and risk explanation. Use when deciding whether to block or warn. - **simulation** — Predicted summary of balance and asset changes (e.g. "You will send 0.01 BTC to bc1q..."). Use when showing the user what the transaction does. You can request one or both; default is both.
        - `account_address` string, required — The Bitcoin address that owns the UTXOs being spent.
        - `transaction` string, required — The raw unsigned transaction in hexadecimal, as produced by the wallet or your app. This is the same payload the user would sign.
        - `metadata` union, required — Context of where the transaction was initiated: use wallet metadata when the user is signing in a wallet for an external site; use in-app metadata when the transaction is created within your own app. Choosing the correct type improves risk analysis and reporting.
          - BitcoinWalletRequestMetadata
            - `type` 'wallet', required — Identifies the request as a wallet signing a transaction on behalf of an external dApp. The type improves threat context and helps attribute risk to specific origins.
            - `url` string, required — The full URL of the dApp or page where the user initiated the transaction (e.g. https://app.example.com/swap).
            - `account` RoutersChainAgnosticModelsRequestAccount
              - …
            - `connection` RoutersChainAgnosticModelsRequestConnection
              - …
            - `non_dapp` boolean, nullable — Indicates that the transaction was not initiated by a dapp. Use false when the transaction is from a dapp.
          - BitcoinInAppRequestMetadata
            - `type` 'in_app' — Identifies the request as coming from your own app (e.g. in-app send, swap, or internal flow).
            - `account` RoutersChainAgnosticModelsRequestAccount
              - …
            - `connection` RoutersChainAgnosticModelsRequestConnection
              - …
            - `non_dapp` boolean, nullable — Indicates that the transaction was not initiated by a dapp. Use false when the transaction is from a dapp.
  - `details` string, required — Free-text explanation or context for the report.

## Response `200`

Report accepted; response body is the HTTP status code (e.g. 201).

- integer

## Other responses

- `422` — Request validation failed (e.g. missing or invalid request body fields).

---

[API](https://skmtc.net/blockaid-official/apis/blockaid-api.md) · [All operations](https://skmtc.net/blockaid-official/apis/blockaid-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/blockaid-official/blockaid-api/revisions/17c41f337b2e/schema)