Splunk® SOAR (Cloud)

REST API Reference for Splunk SOAR (Cloud)

The classic playbook editor will be deprecated in early 2025. Convert your classic playbooks to modern mode.
After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:

REST Audit

You can access audit information for individual Users, Roles, Playbooks, and Containers. Or you can access all available audit information at once, with or without additional filtering.

/rest/audit

List all audit events.

Syntax 

https://<username>:<password>@<host>/rest/audit

Usage details
By default, with no additional variables provided, this rest endpoint will list all audit events for the last 30 days. Like the rest endpoints for individual objects, you can specify "format", "sort", "start" and "end", which will still give you all categories of audit events. Changing the start or end times will change the default start of 30 days ago, or the default end time of now.

Because the rest endpoints for other individual objects inherently specified the object in question, there is no need to specify the set of objects you want audit events for. For the "all" endpoint, the default set is all objects. But you may wish to specify a subset to get just the events you want. As long as you do not specify any object set, you will get all. But as soon as you specify any object, you limit the results to just that object or set of objects.

GET

Request all audit information.

Request string
An argument string must include the following fields: id, where id is the number of the container. See Optional parameters for more information.

Example request
For objects specifying a single user, role, playbook, or container, these would be the equivalent of using the individual rest endpoints for the same id. All of theses pairs of URLs would produce the same results: 

curl -k -u username:password https://localhost/rest/audit?user=1 -G -X GET
curl -k -u username:password https://localhost/rest/user/1/audit -G -X GET

curl -k -u username:password https://localhost/rest/audit?role=6 -G -X GET
curl -k -u username:password https://localhost/rest/role/6/audit -G -X GET

curl -k -u username:password https://localhost/rest/audit?playbook=1 -G -X GET
curl -k -u username:password https://localhost/rest/playbook/1/audit -G -X GET

curl -k -u username:password https://localhost/rest/audit?container=1 -G -X GET
curl -k -u username:password https://localhost/rest/container/1/audit -G -X GET

The difference is that with /rest/audit you can specify a wildcard (*) to get all objects of that type, or you can specify more than one type at a time, or you can specify a list of objects.


Example request
Specify that you want all playbook audit events at once by specifying playbook=* with this URL: 

curl -k -u username:password https://localhost/rest/audit?playbook=* -G -X GET

Example request
For "authentication" and "administration" events, you can only specify * since there are no individual objects to refer to, just those categories. These are effectively the "on" for including these events types. You can ask for multiple objects types at once by specifying multiple types in the URL: 

curl -k -u soar_local_admin:changeme https://localhost/rest/audit?authentication=*&administration=* -G -X GET

Example request
And finally, you can specify multiple individual IDs for the same object type by separating them with %1E, for example, to retrieve audit events for user IDs 1 and 2: 

curl -k -u username:password https://localhost/rest/audit?user=1%1E2 -G -X GET

/rest/audit optional filter

An additional, optional filter is provided to filter based on tenant mapping. If tenant is supplied, the results of all other requested audits will be filtered based on the provided tenant. Using this filter will still include records where no specific mapping exists, implying all tenants, so asset or administration changes that affect all tenants will be included, depending on the type of audit requested. Since this is a filter, * is not supported, as that would be the same as not including it. The filter takes either tenant id or tenant name, and supports multiple arguments using the %1E field separator. If the filter is not included, all records will be included, no matter which tenant they affect.

tenant: (tenant_id or tenant_name)

Example request
You can specify multiple individual IDs for the same object type by separating them with %1E, for example, to retrieve audit events for user IDs 1 and 2: 

curl -k -u username:password https://localhost/rest/audit?container&admnistration&tenant=4%1E2 -G -X GET

The example is retrieving all container and administration operations filtering for those which affect tenant 4 or tenant 2, which will include records affecting all tenants (since this would implicitly include tenant 2 or tenant 4).


/rest/ph_user/<id>/audit

Audit of /rest/ph_user/<userid>.

Syntax 

https://<username>:<password>@<host>/rest/ph_user/<id>/audit

GET

Request the audit information related to a single user.

Request string
An argument string must include the following fields: id, where id is the number of the user. See Optional parameters for more information.

Example request
Request the audit information related to a single user, where 1 is the ID number of the user. For example, the "soar_local_admin" user is usually ID 1. To see everything the soar_local_admin user has done while auditing was enabled, do the following: 

curl -k -u soar_local_admin:changeme https://localhost/rest/ph_user/1/audit -G -X GET

Example response
A successful GET will return the audit of everything the soar_local_admin user has done. 

[
  {
    "AUDIT ID": 37,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": null,
    "NOTE": "GET:/rest/ph_user/1/audit",
    "OBJECT ID": 1,
    "OBJECT TYPE": "ph_user",
    "OLD VALUE": null,
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T00:47:20.692539Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 4,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "disabled",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "true",
    "NOTE": "local/list vms:Previous Record ID:56",
    "OBJECT ID": 57,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "false",
    "RELATED OBJECT ID": 56,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-05T21:47:42.257788Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 3,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "comment",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "3",
    "NOTE": "local/list vms:Previous Record ID:56",
    "OBJECT ID": 57,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "2",
    "RELATED OBJECT ID": 56,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-05T21:47:42.257748Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 2,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "change",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "fa3d71372ac87c1291208e25804af5f7749e79e4",
    "NOTE": "local/list vms:Previous Record ID:56",
    "OBJECT ID": 57,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "88d24966b067f7c7e02de1c208090f736b85dbdd",
    "RELATED OBJECT ID": 56,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-05T21:47:42.257660Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 2,
    "AUDIT SOURCE": "Action Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "",
    "NEW VALUE": "",
    "NOTE": "local/list vms:whois_ip_1",
    "OBJECT ID": "",
    "OBJECT TYPE": "action",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-05T21:45:47.568000Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 1,
    "AUDIT SOURCE": "Action Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "",
    "NEW VALUE": "",
    "NOTE": "local/list vms:list_vms_1",
    "OBJECT ID": "",
    "OBJECT TYPE": "action",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-05T21:45:37.077000Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 1,
    "AUDIT SOURCE": "Playbook Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "",
    "NEW VALUE": "",
    "NOTE": "local/list vms:run",
    "OBJECT ID": 56,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-05T21:45:36.925000Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  }
]

A large number of auditing events have been snipped from this example for the sake of brevity. With all auditing enabled, the audit records can be extensive. It should be noted that accessing audit logs is itself an auditable action. So if you use a user like soar_local_admin to access the soar_local_admin audit record, then you have just added another audit item to the log. Therefore, each subsequent call will return a slightly larger set of records than the one before.

Also note that the AUDIT ID numbers (alone) are not necessarily unique. This is because the audit record comes from more than one database table, each of which has their own set of row numbers. It's the combination of AUDIT SOURCE and AUDIT ID together that make up the unique identifier. The example contains both "Playbook Run":"1" and "Action Run":"1", which are two different item's event though they both have an AUDIT ID of 1, because they have different AUDIT SOURCE values. You will not have two "Playbook Run":"1" audit events, or any audit entries with both the same ID and SOURCE.

/rest/role/<id>/audit

Audit of /rest/role/<role_id>.

Syntax 

https://<username>:<password>@<host>/rest/role/<id>/audit

Usage

Requesting role audit events returns two types of events. First are changes to the role itself, such as creating the role, or changes to permissions in it. Second are events for users currently in the role at the time of the API call. If a user had that role yesterday, but has since been removed, when you request audit events for that role the removed user's events will not appear. For user events, the role here is acting like a group of users. If the role has no users assigned, you will only get the modifications to the role itself.

GET

Request the audit information related to a role.

Request string
An argument string must include the following fields: id, where id is the number of the role. See Optional parameters for more information.

Example request
Request the audit information related to a single user, where 7 is the ID number of the user. To request the format in "csv" instead of the default "json", do the following: 

curl -k -u soar_local_admin:changeme https://localhost/rest/role/7/audit?format=csv -G -X GET

Example response
A successful GET will return a user named "herman" who is the only user in role number 7. Also included is the herman login, and then log authorization errors because that user does not have the necessary privileges to access the objects in question. The example log has been truncated. 

AUDIT SOURCE,AUDIT ID,TIME,USER ID,USER,IP ADDRESS,OBJECT ID,OBJECT TYPE,RELATED OBJECT TYPE,RELATED OBJECT ID,NOTE,CHANGED FIELD,OLD VALUE,NEW VALUE
Audit,62,2017-07-06 03:06:04.086355+00:00,3,herman,10.10.0.240,,authorization,,,users_roles:view:Failed,,,
Audit,61,2017-07-06 03:06:04.083012+00:00,3,herman,10.10.0.240,,authorization,,,containers:view:Failed,,,
Audit,60,2017-07-06 03:06:03.800788+00:00,3,herman,10.10.0.240,,authentication,,,login:Success,,,

/rest/playbook/<id>/audit

Audit of /rest/playbook/<id>.

Syntax 

https://<username>:<password>@<host>/rest/playbook/<id>/audit

GET

Request the audit information related to a playbook.

Request string
An argument string must include the following fields: id, where id is the number of the playbook. See Optional parameters for more information.

Example request
Request the audit information related to a playbook, where 59 is the ID number of the playbook. To request an ascending sort with oldest items first, do the following: 

curl -k -u soar_local_admin:changeme https://localhost/rest/playbook/59/audit?sort=asc -G -X GET

Example response
A successful GET will return back a user named "herman" who is the only user in role number 7. Also included is the user's login attempts, and then log authorization errors because that user does not have the needed privileges to access the objects in question. The example log has been truncated. 

[
  {
    "AUDIT ID": 149,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "change",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "24591582fdaa19b98d4d2681e5098ce712167cc4",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": null,
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:20:28.976883Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 150,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "disabled",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "false",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "true",
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:20:29.055953Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 151,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "passed_validation",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "true",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "false",
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:20:29.056054Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 2,
    "AUDIT SOURCE": "Playbook Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "",
    "NEW VALUE": "",
    "NOTE": "local/whois ip:run",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-06T03:20:38.452000Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 3,
    "AUDIT SOURCE": "Action Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "",
    "NEW VALUE": "",
    "NOTE": "local/whois ip:whois_ip_1",
    "OBJECT ID": "",
    "OBJECT TYPE": "action",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-06T03:20:38.466000Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 153,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "change",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "468ea286a5116c5f924401e802cf420df2f74c97",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "24591582fdaa19b98d4d2681e5098ce712167cc4",
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436100Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 154,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "comment",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "Changed IP",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "Initial version",
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436231Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 155,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "disabled",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "true",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "false",
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436273Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 156,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "old_name",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "whois ip",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": null,
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436310Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 157,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "passed_validation",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "false",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "true",
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436343Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 158,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "version",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "2",
    "NOTE": "local/whois ip:Previous Record ID:59",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "1",
    "RELATED OBJECT ID": 59,
    "RELATED OBJECT TYPE": "playbook",
    "TIME": "2017-07-06T03:22:23.436377Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 159,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "disabled",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "true",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "false",
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:22:23.508084Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 160,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "disabled",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "false",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "true",
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:22:23.513248Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 161,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "passed_validation",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "true",
    "NOTE": "local/whois ip:",
    "OBJECT ID": 60,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": "false",
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:22:23.513313Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 162,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": null,
    "NOTE": "GET:/rest/playbook/59/audit",
    "OBJECT ID": 59,
    "OBJECT TYPE": "playbook",
    "OLD VALUE": null,
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T03:22:32.051042Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  }
]

A small number of operations were performed on this playbook to illustrate what the API returns, but it generated a fair number of events. A playbook called "whois ip" was created and saved. That's audit IDs 149 through 151. Then it was run, which shows as playbook run 2 and action run 3. And then it was changed and saved again, which is shown in audit ID 153 and higher. The playbook started out as ID 59, which is what we requested in the API call. When it was changed and saved again, it became ID 60. Those changes are reflected in the audit events. If you ask for either playbook 59 or 60 from then on, you will get the audit information for all versions of that playbook. You do not have to track the changes and ask for subsequent versions, any version of it will work.

/rest/container/<id>/audit

Audit of /rest/container/<container_id>.

Syntax 

https://<username>:<password>@<host>/rest/container/<id>/audit

GET

Request the audit information related to a container.

Request string
An argument string must include the following fields: id, where id is the number of the container. See Optional parameters for more information.

Example request
Request the audit information related to a playbook, where 59 is the ID number of the playbook. To request events before a particular end date, and an ascending sort with oldest items first, do the following: 

curl -k -u soar_local_admin:changeme https://localhost/rest/container/1/audit?end=2017-07-07&sort=asc -G -X GET

Example response
A successful GET will return back the event dates of 2017-07-06 for the container. This is because the example request used only the date without specifying a time of day. Python substitutes a time of 00:00:00, or the very beginning of the day if you leave off the time. If the example was meant to specify the end of the day on 2017-07-06, it would have to specify 2017-07-06T23:59:59.999999Z, or just use 2017-07-07 as shown. 

[
  {
    "AUDIT ID": 365,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": null,
    "NOTE": "GET:/rest/container/1/comments?page=0&page_size=20&sort=time&order=desc&pretty=true",
    "OBJECT ID": 1,
    "OBJECT TYPE": "container",
    "OLD VALUE": null,
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T22:16:04.602689Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 1,
    "AUDIT SOURCE": "Action Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "",
    "NOTE": "user initiated list vms action",
    "OBJECT ID": "",
    "OBJECT TYPE": "action",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-06T22:17:34.392168Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 2,
    "AUDIT SOURCE": "Action Run",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": "",
    "NOTE": "user initiated whois ip action",
    "OBJECT ID": "",
    "OBJECT TYPE": "action",
    "OLD VALUE": "",
    "RELATED OBJECT ID": 1,
    "RELATED OBJECT TYPE": "container",
    "TIME": "2017-07-06T22:18:03.566282Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
  {
    "AUDIT ID": 368,
    "AUDIT SOURCE": "Audit",
    "CHANGED FIELD": "",
    "IP ADDRESS": "10.10.0.240",
    "NEW VALUE": null,
    "NOTE": "GET:/rest/container/1/artifacts?page=0&page_size=5&sort=id&order=desc&pretty=true",
    "OBJECT ID": 1,
    "OBJECT TYPE": "container",
    "OLD VALUE": null,
    "RELATED OBJECT ID": null,
    "RELATED OBJECT TYPE": null,
    "TIME": "2017-07-06T22:18:14.021982Z",
    "USER": "soar_local_admin",
    "USER ID": 1
  },
]

The results in the example response have been heavily truncated, because using the web UI to look at the container generates a lot of records like Audit 365 and Audit 368 as shown. You can also see two action runs. You can see that accessing the rest endpoint for a container is logged as an audit event if you have that auditing enabled. That will include the rest call you made to get these results. So every time you make this rest call, there will be at least one new event.

Optional parameters

The optional parameters for the audit REST API endpoints follow.

Audit Type Optional Parameters
ph_user, role, playbook, container
(/rest<type>/<id>/audit) 		format: (json by default or csv)

sort: (desc by default or asc)
start: [datetime] 30 days prior to the current time.
end: [datetime] Accepted date formats are ISO 8601 date or date and time.

ALL
(/rest/audit) 		format: (json or csv)

sort: (desc or asc)
start: [datetime] 30 days prior to the current time.
end: [datetime] Accepted date formats are ISO 8601 date or date and time.

user: (user_id or *)
role: (role_id or *)
authentication: [*]
administration: [*]
playbook: (playbook_id, repo/pb_name, or *)
container: (container_id, container_name, or *)

Additional Info:

  • For all types, multiple values may be selected by separating with %1E (ASCII field separator).
  • For playbook and container, a combination of name/id is possible, again using %1E as a separator.
Last modified on 06 November, 2024
REST Asset   REST Automation Broker

This documentation applies to the following versions of Splunk® SOAR (Cloud): current

Acrobat logo Download manual
Acrobat logo Download this page

Was this topic useful?







You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters