# Common errors and issues

This page explains common errors and issues that you may encounter. If you are having trouble debugging an error, get in touch with us to add it to this list.

# General errors

# Incorrect endpoint

If you call an incorrect endpoint you will be given a list of availale endpoints. For example curl https://api.bitpost.co/ returns:

{
  "data": {
    "endpoint": "Endpoint not found. See available endpoints under the key 'available'.",
    "available": [
      "POST /request",
      "DELETE /request",
      "PUT /request",
      "GET /request",
      "GET /requests",
      "POST /wallettokens",
      "GET /utxos"
    ]
  },
  "status": "fail"
}

# Missing parameters

You get can easily get all mandatory parameters of an endpoint from its error message. For example, curl -X POST https://api.bitpost.co/request returns:

{
  "data": {
    "body": "Invalid HTTP request body.",
    "target": "Invalid target."
  },
  "status": "fail"
}

# POST /request

# Double spend against to-be-broadcasted transactions

No relayed pre-signed transactions (PSTs) can double-spend another PST in another request. If instead, you want to cancel the existing request and make a new one, you can call the DELETE /request endpoint (keep in mind that old broadcasts can still be mined); or if you want to add new PSTs to an existing request, call PUT /request. Finally, if you tried to double-spend by mistake, you can call /utxos endpoint to obtain all used UTXOs and lock them before performing coin selection.

# The relayed transactions are not mutually exclusive

The set of PSTs that you sent to Bitpost have to be mutually exclusive; this is, it should be impossible to mine two of the relayed transactions. If you get this error, you are probably doing a new coin selection for every transaction you sign, which leads to non-overlapping inputs in the relayed PSTs.

# Inconsistent use of a pending transaction

Some PSTs that you relayed to us are childs of a pending transaction or transactions of a pending request while others aren't. This choice of inputs greatly complicates the fee adjustment process without any benefit. Think of whether you want to include this pending transaction or pending request, and then use it all or none of the PSTs that you will send to us.

# POST /wallettokens

# Invalid signature(s)

If you are having trouble getting your signatures validated, remember that the message to be signed is "bitpost" appended with the current second epoch divided by 1000 (e.g. "bitpost1594735") and the sighash should be created from the message as in bitcoin core. You can find more information about it here.

{
  "data": { "signature": "Invalid signature for message and public key." },
  "status": "fail"
}

← Child requests →