I was going to point you towards my CoCoHue apps and drivers as an example of how to do HTTP GETs and PUTs with Groovy in Hubitat, but in most cases, particularly the PUTs, there are a couple pieces that get put together from the parent app and child devices, so it might not be an easy example to start out with.
So, instead I'll walk through a specific, highly commented and slightly modified near-example from the RGBW bulb driver:
// This really gets passed into the function this code lives in, but since it's not
// part of this example I'll just declare it here:
Map cmd = ["on": true]
// This is a method on the parent app that returns a Map that will look something
// like: [username: "abc123", fullHost: "http://1.2.3.4:80"]:
Map<String,String> data = parent.getBridgeData()
Map params = [
uri: data.fullHost,
path: "/api/${data.username}/lights/${getHueDeviceNumber()}/state",
contentType: "application/json",
body: cmd, // Groovy/Hubitat is nice and converts this to JSON for you
timeout: 15
]
asynchttpPut("parseSendCommandResponse", params, cmd)
If you care to parse the response or at least know when it happens, then you'll need a callback method, which is parseSendCommandResponse() per my call above:
void parseSendCommandResponse(resp, data) {
// Do things here, like check if `resp` indicates an error state or went OK;
// in my case, I generate events if the response from the Hue Bridge is HTTP 200 OK,
// and I do that based on the data Map that gets passed in as `cmd` from my asynchttpPut
// call (it's the command sent to the Bridge), but data is optional and will only be what you
// provide, if anything. Your system's API should tell you what to expect back.
}
The callback method is necessary here because I'm using an async call, which means it will not hold things up while it waits for a response. Instead, it will send the HTTP PUT, then the app or driver will go to sleep until it wakes up for the callback (ideally because it heard back from the device, but it could also be after the specified timeout). Synchronous calls are a bit easier to write for but less advised if you don't need them.
So while this was really written with the Hue API in mind (yours looks somewhat similar in that it's RESTful but has the JSON in the URL instead of the body; in that case, you may need to use Groovy's URL encoding methods--unless all the raw JSON doesn't make the URL invalid--and possibly stringify the Map into JSON yourself before that...I forget if that's one of the things that is automagically done for you or not) and a parent app that creates "child" devices, hopefully it still illustrates the point. But I don't know how helpful it will be. Hubitat's docs on the HTTP methods will probably be just as helpful. See this doc for those: Common Methods Object - Hubitat Documentation
There is also a community HTTP driver out there that creates a switch that, when turned on, can send these commands on its own with a bit of configuration on your part. It may be easier than writing everything on your own, but it may also be less desirable in that you'd have to specify your access token, IP, and whatnot in each driver (and do the same if either ever changes). You'll also have to think about your end goal; I know you said "app," but it's unlikely you'll want to have to go into a Hubitat app and press a button there each time to send a command to your devices. You'll probably want a Hubitat device (which may or may not be created/managed/communicated with via an app) so you can use the device in automations (apps, including rules/etc.) rather than needing to go into the admin UI to do anything with it. That could just be a terminology slip, but since they are also distinct concepts in the platform, I figured it was worth mentioning.
I should also mention that I know nothing about the other system you're using, but it sounds like others above do. So, I'm not saying any of what I said is (or isn't) a good idea as to how to integrate with that...just trying to directly answer the specific question about the part I do know. 
