Incorrect NodeId Size (32-byte vs 33-byte) in UpdateRelayFee API Documentation

[CaoKha]

Description

The Eclair API documentation for the updaterelayfee endpoint at https://acinq.github.io/eclair/#updaterelayfee contains an inconsistency in the parameter descriptions. The nodeId parameter is incorrectly described as a 32-byte hex string, while the nodeIds parameter (which accepts multiple node IDs) is correctly described as requiring 33-byte hex strings.

Details

When implementing a client for the Eclair API, I noticed this inconsistency. The actual implementation requires both nodeId and nodeIds to be 33-byte hex strings (66 characters), which matches the standard format for Lightning Network node identifiers.

The documentation currently states:

Parameter	Description	Optional	Type
nodeId	The nodeId of the peer you want to update	Yes (*)	32-bytes-HexString (String)
nodeIds	The nodeIds of the peers you want to update	Yes (*)	CSV or JSON list of 33-bytes-HexString (String)

which should be

Parameter	Description	Optional	Type
nodeId	The nodeId of the peer you want to update	Yes (*)	33-bytes-HexString (String)
nodeIds	The nodeIds of the peers you want to update	Yes (*)	CSV or JSON list of 33-bytes-HexString (String)

[CaoKha]

In https://acinq.github.io/eclair/#rbfopen, channelId parameter, which is currently of type 33-bytes-HexString (String), should be of type 32-bytes-HexString (String).

[t-bast]

Thanks, there are indeed probably a few occurrences of such errors! Please list everything you find in this issue, and once we've gathered them all, we'll update the API documentation.

[CaoKha]

I was testing with regtest and here are the other inconsistences I found in the docs CreateOffer returns an object instead of a string like shown in the docs

{
  "records": {
    "OfferChains": {
      "chains": [
        "06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f"
      ]
    },
    "OfferDescription": {
      "description": "test-offer"
    },
    "OfferNodeId": {
      "publicKey": "0390bfc705b197ecd54397eb42f28e731ef0aa6d118fc7387bcb41c31dbe6e6914"
    },
    "OfferAmount": {
      "amount": 1000000
    },
    "OfferIssuer": {
      "issuer": "kha"
    },
    "OfferAbsoluteExpiry": {
      "absoluteExpiry": {
        "iso": "2025-05-24T09:53:37Z",
        "unix": 1748080417
      }
    }
  }
}

ListOffers endpoint returns an array of object instead of an array of string like shown in the docs DisableOffer, PayOffer need offer encoded in BOLT12 format (which currently cant be received directly from ListOffers) GlobalBalance endpoints return onChain.unconfirmed, onChain.confirmed fields as object and not a number ChannelBalances, UsableBalances return

[
  {
    "remoteNodeId": "03240bcb4ff626836e9e3e8fd4bd0d8c6b7f20aed343cf0834c48ffc6eef53d8cc",
    "realScid": "318x1x1",
    "aliases": {
      "localAlias": "0x16939965d75002",
      "remoteAlias": "0xf424000000000001"
    },
    "canSend": 81100000,
    "canReceive": 8900000,
    "isPublic": true,
    "isEnabled": true
  }
]

while its docs said it returns:

[
  {
    "remoteNodeId": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",
    "shortIds": {
      "real": {
        "status": "final",
        "realScid": "562890x809x0"
      },
      "localAlias": "0x17537e03b55a01e",
      "remoteAlias": "0xcde44c7ebd1449"
    },
    "canSend": 131219000,
    "canReceive": 466000,
    "isPublic": true,
    "isEnabled": true
  },
  {
    "remoteNodeId": "02865c138ddfb0e1e8c62aa8cebbed383d5b343c2d40fa22c31773a6725854154f",
    "shortIds": {
      "real": {
        "status": "final",
        "realScid": "562890x809x1"
      },
      "localAlias": "0x8676ba94f75888",
      "remoteAlias": "0x317b1df704e350f"
    },
    "canSend": 0,
    "canReceive": 1250000,
    "isPublic": true,
    "isEnabled": false
  }
]

OnChainTransactions endpoint: count parameter is required and not optional as shown in the docs

[t-bast]

Fixed after the v0.13.0 release. Note that many of the changes you mention were because you didn't seem to be using eclair v0.12.0 but rather our master branch. The API documentation always matches the latest release, not the state of the master branch.

Thanks for reporting all of those!