create_transactions

Submits one or more fully built transactions. The request body is a UTXO-style object: inputs (with previous_out and a script_signature such as Pay2PkH), outputs (value, locktime, script_public_key), version, and optionally druid_info. This call assumes a full transaction in the request body, which can make raw HTTP calls difficult; for convenience, it may be easier to use a library or SDK that abstracts this route.

Endpoint

POST https://mempool.lineage.to/create_transactions

Headers

Request body (full JSON shape)

application/json body. Each input uses previous_out (transaction hash t_hash and output index n). For script_signature / Pay2PkH, signable_datais the data to sign for verification: a SHA3 hash of all the transaction outputs and this input's previous output (for example "{output1}{output2}{previousOut}" as concatenation, per the public reference spec).

Complete example (with optional druid_info)

{
  "inputs": [
    {
      "previous_out": {
        "t_hash": "<32-byte-hex-tx-id-of-utxo-spent>",
        "n": 0
      },
      "script_signature": {
        "Pay2PkH": {
          "signable_data": "<hex: digest the node asks you to sign (e.g. outputs + previous out)>",
          "signature": "<hex>",
          "public_key": "<hex>",
          "address_version": "<e.g. network byte / version string>"
        }
      }
    }
  ],
  "outputs": [
    {
      "value": { "Token": 1000 },
      "locktime": 0,
      "script_public_key": "<recipient locking script / key hash encoding>"
    }
  ],
  "version": 1,
  "druid_info": {
    "druid": "<coordination id for 2-of-n or DEX-style flows, or empty string>",
    "participants": 2,
    "expectations": {
      "from": "<address>",
      "to": "<address>",
      "asset": {}
    }
  }
}

Typical example (omit druid_info)

Many single-party sends omit druid_info. Your deployment may accept a body like:

{
  "inputs": [
    {
      "previous_out": { "t_hash": "<utxo-tx-hex>", "n": 0 },
      "script_signature": {
        "Pay2PkH": {
          "signable_data": "<hex>",
          "signature": "<hex>",
          "public_key": "<hex>",
          "address_version": "<string>"
        }
      }
    }
  ],
  "outputs": [
    {
      "value": { "Token": 1000 },
      "locktime": 0,
      "script_public_key": "<script>"
    }
  ],
  "version": 1
}

Example

curl -sS -X POST "https://mempool.lineage.to/create_transactions" \
  -H "Content-Type: application/json" \
  -H "x-cache-id: 0123456789abcdef0123456789abcdef" \
  -d @transaction.json

Responses

200 and 400 for success and client errors, using the same envelope as other routes.

Envelope fields (typical)

• id — idempotency id (matches x-cache-id).
• status — one of Success, Error, or Pending.
• reason — human-readable detail; especially useful for errors.
• route — logical route name for the call.
• content — payload; shape depends on the operation.

Example success payload

{
  "id": "a1d46199e5c89b00509e118f5af83172",
  "status": "Success",
  "reason": "Transaction/s successfully created",
  "route": "create_transactions",
  "content": {
    "transaction": {
      "tx_hash": "<32-byte-hex of accepted tx>",
      "hex": "<optional raw tx hex if your build returns it>"
    }
  }
}

Example error envelope (typical 400)

{
  "id": null,
  "status": "Error",
  "reason": "Bad Request",
  "route": null,
  "content": null
}