More complete output for api-list_accessible_cmds API command?


I took the output from the api-list_accessible_cmds API meta-command (with a key that could access everything) and used it to scaffold a basic Node.js API client.

Having the api-list_accessible_cmds command available was very handy and really made this a much more feasible project! However, it could be even better - a good chunk of the API commands get “see_docs” for all of the details:

      "cmd": "dns-list_records",
      "order": "see_docs",
      "args": "see_docs",
      "optargs": "see_docs"

Rather than the expected info, for example:

      "cmd": "jabber-deactivate_user",
      "order": [
      "args": [
      "optargs": []

Is there any chance that this will be more fleshed out in the near future? Ideally, I’d like to see it have descriptions of the args and response data, and/or a link to the relevant docs. But just filling in the “see_docs” parts would be a nice improvement that could immediately be turned into an improved JS client.

Also, I designed the library to work in browsers also, and then realized you guys don’t put CORS headers on the responses. I know you wouldn’t want a key that can access everything getting exposed publicly, but I can think of a few use-cases where client-side usage with a more limited key would make sense. Is there any chance you’ll add the CORS headers?

Hello there, I noticed your npm submissions and had a note to reach out to you :slight_smile: I asked around the company to understand more about the API’s roadmap but I don’t have a precise answer for your questions, yet. We don’t get much feedback from customers about the APIs. Could you share more details on your use cases? (feel free to email me directly if you prefer.)

So, my two current use cases are that npm module itself, and then this dns update script that basically treats you guys as dynamic dns (although with a bit higher TTL on the records than what I would have chosen - maybe you can expose that setting next.)

One other request I’ll put in while I’m thinking about it is proper boolean fields in json output. Right now the dns-list_records command puts a string “1” or “0” for the “editable” field - that works in php, but they’re both truthy in JavaScript :confused: I could fix that in the client, but it’d probably be better all around if it were fixed server-side. domain-registration_available returning [{“available”: “yes” / “no”}] is another example where a boolean might make more sense.

Looking at the npm stats, there seems to be a bit of demand for a node.js client - I wouldn’t have expected that much traffic for something I just published a day or two ago and literally haven’t told anyone about aside from this forum thread!