@wayne-workman
Thx. I figured out where was the issue. Maybe this info will help somebody.
I use curl under Windows, but command line doesn’t support single quotes '.
I used " and had to escape inner ones
–data “{\“hostID\”:13}”

What did your Powershell command look like? I would like to see that example. I am most familiar with it and the one main thing I need to work on is a for each from a csv file with all of our old junked computers and laptops returned from lease. We no longer need them in fog.

This is just a quick means to represent how you could filter the tasks if you needed to as well.

Our “List all tasks” works without a body sent, but CAN be filtered to get specific information for active tasks. The example just shows how you might want to get active tasks for host ids of 5 and 6. I’m not trying to show actual payload right now. Just trying to show example use cases.

So let’s do this command line style:
Let’s just say your api token is abcde
Let’s just say your user token is fghij
List all current/active tasks is a GET request.
URL for now is just fogserver

This will list all current/active tasks to a file in the current working directory named listalltasks.json

For creating a snapin task, this depends how you plan to do it. To be honest, while the option is available, it’s not something I’ve worked overly hard to get working “natively”. It was originally only designed to allow host and group, though I saw the appeal and added capabilities.

Hi Tom
Thanks you for the detailed response much appreciated, i feel rather stupid asking but i don’t suppose you have a couple of examples to follow do you ?
Say for instance if i wanted to list all active tasks or even add a snapin task.

Right now there isn’t much in terms of documentation. We are working toward getting there.

Understand the API system is very new, but as much as I could “simply” implemented.

What I mean with this:

Data body or return is done with JSON.

All objects in the core have some ability to managed with the API system with the only exception, so far, being Users.

There are a few important bits in regards to interacting and using the API System.

API Can be globally enabled/disabled.

API Can be user enabled/disabled. – (You can define which users you want to have access to the api system.)

Tokens:

API Global token is a header required with the name fog-api-token

API User token is a header that can be used (Highly recommended) being passed as a header in the form fog-user-token

You can not manually create the tokens via the presented text fields. This is what the purpose of the “Reset Token” Buttons are. There’s a Reset Token for the global API as well as one for each user.

Tokens are cryptographically generated so no two tokens will be known regardless of how many FOG Server’s you decide to install. There is no “default” token essentially. This holds true for both User and Main API Tokens.

Authentication:
You can use HTTP Basic Authorization (with curl -u <user>:<password> or header with name Authorization: Basic <base64encoded username:password>
Although I have allowed the ability for this type of authentication, and it will work, I would still recommend using user token system as it cannot be received and decoded to a valid username/password pair to manage your fog server.

HEAD

I realize this is not a full on “here’s everything” but it’s something that should be able to help get you along the path.

Core <object>

clientupdater

dircleaner

greenfog

group

groupassociation

history

hookevent

host

hostautologout

hostscreensetting

image

imageassociation

imagepartitiontype

imagetype

imaginglog

inventory

ipxe

keysequence

macaddressassociation

module

moduleassociation

multicastsession

multicastsessionsassociation

nodefailure

notifyevent

os

oui

plugin

powermanagement

printer

printerassociation

pxemenuoptions

scheduledtask

service

snapins

snapinassociation

snapingroupassociation

snapinjob

snapintask

storagegroup

storagenode

task

tasklog

taskstate

tasktype

usercleanup

usertracking

virus

Core <objecttasktype>

group

host

multicastsession

snapinjob

snapintask

task

Core <objectactivetasktype>

multicastsession

scheduledtask

snapinjob

snapintask

task

Routes that allow filtering with JSON body passed

GET

/fog/<object>

/fog/<objectactivetasktype>/active

/fog/<objectactivetasktype>/current

DELETE

/fog/<objectactivetasktype>/cancel

Plugin’s Compatibility.

I have worked relatively hard to implement capability for plugins to also tie in with this. This means hooks can be used to implement API level functionality with plugins or custom elements you’d like to use.

Hook Event Names what core element it ties in with:

API_VALID_CLASSES, variable to adjust is labeled ‘validClasses’. Ties in with <object> items.

API_TASKING_CLASSES, variable to adjust is labeled ‘validTaskingClasses’. Ties in with <objecttasktype> items.

API_ACTIVE_TASK_CLASSES, variable to adjust is labeled ‘validActiveTasks’. Ties in with <objectactivetasktype> items.

API_MASSDATA_MAPPING, variables to adjust are labeled ‘data’, ‘classname’, and ‘classman’. Operates on the “list” and “search” type routes.

API_INDIVDATA_MAPPING, variables to adjust are labeled ‘data’, ‘classname’, and ‘class’. Operates on individual objects such as /fog/<object>/<IDOFOBJECT>

API_GETTER, variables to adjust are labeled ‘data’, ‘classname’, and ‘class’. Operations for all items and is used to present the return of data in a common way regardless of what object is being called.

In regards to #6 of the Hook Event elements, think of it as this:
If I request information about a task, one of the elements of a task is the “host” object. The data presented in the “Task” return for a specific host will look the same in the task return as it would if you looked the host up individually. For example, if the task is using a hostID of 7, the ‘host’ item in this element would look identical to the return data if you were go to route /fog/host/7