Hi All,
Simply is it possible to update from one Mikrotik scripting via REST API and fetch to update other Mikrotik settings.
Spent 3 days and countless ways seems it was not built to work with fetch and mikrotik. By logs api user logs in ok
For example below code returns error 400
/tool/fetch http-method=post http-header-field=“Content-Type: application/json” http-data=“payload={"name":"MK_TEST"}” url=“http://1.2.3.4:80/rest/system/identity” user=user password=pass
Have you tried to take it from a another angle, use another app like curl and get it working first.
And then use Mikrotik tool fetch command to do the same.
So you slice the/your problem into two steps.
With curl it works fine with no issues.
for example below work as expected
curl -k -u user:password -X POST http://1.2.2.3:80/rest/system/identity/set --data “{"name":"MikrotikTEST"}” -H “content-type: application/json”
This curl string not even converts with tool mentioned above
EDIT: conversion went thru if removed user creds
Thanks something worked, at least how small step forward
I think in V7, using output=none is generally preferable. Although imagine in that case there same. But output= allows you just control whether is a variable, file, or none in a one-stop operation.
One other tip is all the PUT/PATCH operations can generally be reflected in a POST request, in which case you typically put the id as { “numbers”: “*0”, … } - but it’s a lot closer to the CLI than other methods so sometimes POST is easier if you already know the RouterOS CLI command - essentially the the CLI command attributes go into JSON body, with the command is URL including the set/get/print/etc.
Finally to check the *0 is valid, use something like “/ip/address print show-ids” - with “show-ids” being the important part – which can confirm you’re using the right *XX in your REST API curl/fetch.
Interesting find. I wrote the tool, so it uses this library internally: https://github.com/postmanlabs/curl-to-postman
Which allows only a subset of curl commands, and --user is NOT one of them:
Unsupported flag are normally skipped, but I guess the --user takes a 2nd option user:password so that’s trickier…
Also since someone could cut-and-paste some creds, it probably for the best. FWIW, while I put a webpage around the code, the project is actually for use inside Postman app to get the /tool/fetch from a Postman App project which does support user= and password=. It the curl to postman part that’s lossy however, which the website curl2rsc uses.