This is a technical guide for the Digital-Clay REST API. For an overview of other options for integrating applications, custom interfaces and systems with Digital-Clay, see Integration.

Note that Data Injection is a non-standard but faster alternative for adding and updating data into Digital-Clay, as well as a method for updating data from external systems and web sites that do not have direct network access to the Clay server. As compared to Injection however, the REST API provides a standard protocol and framework for programming solutions, it provides responses or errors for each API call, and a variety of functions that also allow an application to retrieve data from Clay without accessing the Clay database directly.

The REST API is accessible only via Web Clay. This article assumes you have already installed Web Clay.

A REST API call uses the exact same URL as Web ClayStation, except it contains a path after the URL. For example, if the Web Claystation URL is: http://myserver.com/clay.dcw a sample REST API URL would be: http://myserver.com/clay.dcw/data/150/ .

Every API call must be accompanied by one of three standard authentication methods:

• A user/password login sent with each and every API call using HTTP Basic authentication. This method is more convenient when no session can be stored between API calls. But it is less secure since each call must include the username and password. This uses the 'Basic' type in the Authentication header.

• A 'login' API call, and then a session ID sent as a standard HTTP Bearer authentication header with each subsequent API call. This method is more secure since the username/password is only retrieved and sent once. This uses the 'Bearer' type in the Authentication header.

• A Clay-session authentication using an existing Clay client session ID. Note that this is not the same session ID as in the previous example, and it relies on an existing login made using a regular Clay client. This uses the non-standard 'Session' type in the Authentication header.

All login methods are practically equal in terms of performance. They only differ in convenience and security. Details and examples follow below.

Note that for security purposes, when the API is called from external applications or networks and eavesdropping is a concern, it is recommended to install a Web Server with an SSL certificate and to call the REST API using the HTTPS protocol.

Important note about Web Server configuration: The standard “Authentication” HTTP header must be passed by the web server to the Clay FastCGI module in order for authentication (and therefore for all of the API) to work. The default Clay Apache installation contains the appropriate configuration in Apache's conf file. But if you are using a different web server or configuring the web server manually, you must ensure that the web server passes this header to its modules. For example, in Apache, this is done using the following line:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
(or can also use "CGIPassAuth on" on newer Apache versions)

Request:

GET /clay.dcw/data/1/
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

This method is attached to any API call listed below. In the above example it is attached to a GET “data” API call. I.e. every API call must contain an HTTP header named “Authorization” with the value “Basic”, and then a base64 encoded string containing the “username:password”.

If the client has already logged in using this user/pass from the same IP, the previous connection will be re-used for performance. Connections will only disconnect after a period of inactivity, just like with other Clay connections.

First, a login API call must be made as follows:

Request:

POST /clay.dcw/login/

{"user": "john", "pass": "123"}

Details:

Path: login/
Verb: POST
Content-Type: application/json

Response:

{"SessionID": "FBA16C8E241B70851D31"}

The returned SessionID must be then used in all subsequent API calls as follows:

Request:

GET /clay.dcw/data/1/
Authorization: Bearer FBA16C8E241B70851D31

Request:

GET /clay.dcw/data/1/
Authorization: Session eW91Z290bWUhbm9wYXNzd29yZGhlcmU=

OR, if you require a GET URL for images etc (don't forget to encodeURIComponent() the sessionID):

GET /clay.dcw/data/1/?session=eW91Z290bWUhbm9wYXNzd29yZGhlcmU%3D

Note that this method does not use the same session ID as in the Bearer method. The Bearer method creates a new login via a REST API login call, and uses the returned ID for subsequent REST API calls. This uses an existing session ID currently in use by Clay clients such as ClayStudio or Web ClayStation, and it performs the REST API call using this existing login without disconnecting that user. If the login does not currently exist, i.e. the client is no longer connected, this method will fail. If the client reconnects, a new session ID is needed.

This method is used for add-ons. For example, an add-on may present a custom interactive graphical interface to the user, and store updates to Clay, or retrieve new data from Clay, using REST API. All this is done while the user is connected using a regular Clay client, and has loaded the add-on interface. The interface can then communicate with Clay using REST API and use the existing client's login/connection for performing its actions.

The Clay session ID can be retrieved currently only using Document Templates. A system merge field called “Session ID” must be added to the document template, and then used in javascript for authentication with the web server when calling Clay REST API.

Web Browser Security Restrictions: Important note when using the REST API and the Clay session ID from withing an addon tab to communicate with WebClay: When using an addon from a desktop Clay client such as ClayStation, you must take into account web browser security restrictions related to the Same-Origin Policy (Cross-Origin Resource Sharing (CORS)). This is a restriction imposed by the web browser based on security standards, not by Clay. This becomes an issue because the desktop client by default loads the addon from a local folder on the hard disk and the REST API request is made to WebClay on a web server, which means it is on a different domain from the addon itself. This means you can make the request, but cannot read the response, even the status code of the response. Old versions of Clay until version 9 used an older browser which allowed this, but as of version 10+ of Clay, Clay uses a chromium-based browser which doesn't allow this. Solutions/workarounds:

• Load the addon from the same web server as WebClay, not a local file. In other words give Clay a URL for the addon that is in the same domain as WebClay. If the addon is a Clay Document Template however, WebClay will have to generate the document and this is a problem.
• Use the addon only in WebClay, not in desktop Clay clients. This means the addon will be loaded from the same domain as WebClay by default.
• Make your requests to the REST API as usual but ignore the response and assume it was successful. This is not ideal as it means there is no error handling.

Changing a password via API is used primarily when the username used in the API has a password that has expired. In this case, any API call with either of the login methods above will receive an error with the error code 990 and no further API call will be responded to until the password is changed. The password may be changed via any Clay client, or via API as below.

Note that this API call, as with all other calls, must be accompanied by authentication information. I.e. either the old user:pass using Basic authentication, or the SessionID received when the previous login failed with the 'password expired' error.

Request:

PATCH /clay.dcw/login/

{"oldpass": "123", "newpass": "124"}

Details:

Path: login/
Verb: PATCH
Content-Type: application/json

Response:

{"error": "", "errorCode": 0}

All API calls using either of the above authentication methods will leave connections open until a period of inactivity has passed, or until a logout call has been made. As with the Change Password call, authentication information must be included in this call as well.

Request:

DELETE /clay.dcw/login/

Details:

Path: login/
Verb: DELETE

Response:

{"error": "", "errorCode": 0}

Any API calls may result in a unexpected error either due to malformed requests from the client, or due to internal Clay errors. In these cases, the result will always be a json string in the following format:

{"error": "Error description", "errorCode": 997}

The description of the problem will be in the “error” variable accompanied with an errorCode. Note that the errorCodes are not unique and the calling client must log the error description in order to debug the issue. But some of the more common errors are covered with the following error codes:

• 997: No such custom object. This usually means that a custom table, link or field has been used in the request which no longer exists.
• 999: No permission. This is returned when the user used by the API call does not have permission to perform the action contained in the request.
• 990: Password expired. A change password request must be sent in order to proceed.
• 668: Item not found: A record with a specific ID was requested or updated but does not exist in the database.

This section describes the API calls for getting, adding, updating and deleting data from Clay. All of these actions have the following in common:

A record can be accessed either via its internal ID, or via a combination of unique fields. I.e. if the internal ID of the record is known, this is the simplest and fastest method for retrieving or updating a record. (Note that the ID can be retrieved using API as well.) If this is not possible, then the alternative method is to supply one or more values in fields that, combined, will refer to a unique record. For example, in the table of 'Orders', a specific Order can be accessed via its internal ID, or via a unique custom field called “Invoice ID”, or by a combination of “Order Date” and “Customer”. Examples will be provided below for both of these methods.

The API calls must minimally provide the table id, and either the record ID, an ID of 0 to denote a new record, or a list of fields and field values to find a record by its values. All table and field IDs can be viewed from within ClayStudio using the Custom Fields or Designer tools, as well as by using the Tables API below.

Example #1. Request (using ID):

GET /clay.dcw/data/156/12345/

Details:

Path: data/[tableid]/[recordid]/
Verb: GET (or SEARCH or PROPFIND)

Response:

{"f0":{"v":"12345"},"f1":{"v":"1"},"f2":{"v":"John"},"f151":{"id":76543,"v":"Type A"},"f152":{"v":"1460462647"},"f153":{"v":[{"id":45678,"v":"Team B"},{"id":45679,"v":"Team D"}]},"f154":{"v":""}}

The response is the full data object with a list of all its fields and values. Field names are denoted as “f[fieldid]”. A description of the various types of fields is as follows:

• The ID is always returned as the field with the name “f0”.
• Each field is a json sub-object containing one or more values.
• The “v” generally means the display value of the field (as opposed to the internal id value in case of linked fields).
• The “id” value (f151) is returned for a linked field containing the internal ID of the linked record and it is the important value when updating a record. The “v” in this case is the Name of the linked record for display purposes.
• Many-to-many fields (f153) are returned as an array of sub-objects, each with an “id” and a “v”.
• Date and date-time fields (f152) are returned as the number of seconds since 1-1-1970.

Fields of type Custom Function are by default returned with empty values, unless the API request includes an optional parameter “calcs”. For example:

GET /clay.dcw/data/156/12345/?calcs=154,157

This will fill the values for the function fields with ids 154 and 157.

Example #2. Request (using fields):

PROPFIND /clay.dcw/data/156/?unique=2,152

{"f2":{"v":"John"},"f152":{"v":"1460462647"}}

Details:

Path: data/[tableid]/
Verb: GET (or SEARCH or PROPFIND). Some REST clients refuse to send an HTTP body with the GET/SEARCH actions in which case you can use PROPFIND.
Content-Type: application/json

Response:

{"f0":{"v":"12345"},"f1":{"v":"1"},"f2":{"v":"John"},"f151":{"id":76543,"v":"Type A"},"f152":{"v":"1460462647"},"f153":{"v":[{"id":45678,"v":"Team B"},{"id":45679,"v":"Team D"}]},"f154":{"v":""}}

See previous example for a description of the fields.

The same record as in the previous example is returned, except this time instead of using an id (12345), the example searches for a record using the combination of values in the fields 2 and 152. Note that you need to add the parameter “unique” as well as the actual values in the BODY of the request.

Important: If more than one record is found using the provided fields/values, then only the first record found will be used. Which is why you need to ensure that the fields used are guaranteed to be unique.

Example #3. Request (getting a blank record):

GET /clay.dcw/data/156/

Details:

Path: data/[tableid]/[blank or 0/]
Verb: GET

Response:

{"f0":{"v":"0"},"f1":{"v":"1"},"f2":{"v":"default"},"f151":{"id":0,"v":""},"f152":{"v":""},"f153":{"v":[]},"f154":{"v":""}}

Use this method to get an 'empty record'. This can be useful as a json object to start with when adding a new record, and, more importantly, it provides the configured default values for the current user.

As with Data Injection, the methods for both adding and updating records have been combined for convenience, since often one wants to add a record OR update it if it doesn't exist, all with a single action.

An Update can use either an ID or a unique field list in order to find an existing record. See the previous section on the Get API call for more examples.

Request (using ID):

POST /clay.dcw/data/156/12345/?duplicate=1

{"f2":{"v":"John"},"f152":{"v":"1460462647"},"f153":{"v":[{"id":45678,"v":"Team B"}}

Details:

Path: data/[tableid]/[recordid or "?unique" or 0 or blank]/
Verb: POST (or PUT or PATCH)
Content-Type: application/json

Response:

{"f0":{"v":"12345"}}

Notes:

• The request must contain a json object in the BODY. See the Get API call for details on the format of this object.

• If the record ID and the “unique” parameters are both missing, it will perform an Add.

• The “duplicate” parameter defines what action to perform, not the REST verb. The options for this parameter are identical to the ones in Data Injection: 0=Add (always add and don't check for duplicates - the default if the duplicate parameter is not included), 1=Merge (add if it doesn't exist and merge if it does), 2=Merge Only (don't add new records, merge only with existing ones if they exist), 3=Skip (add new records only, skip if they exist).

• If it will perform an update, there is no need to fill all of the field values. Only the changed fields need to be included. The rest will be merged from the existing/old data.

• To set linked fields and single-select fields, the “id” value must be filled and “v” is optional. If you wish to link to an existing record and do not know its ID, then either use a Get or Add/Update call for that record first to get its ID.

• The response returns only the ID whether it is an Add or an Update.

• For conflict management, make sure you only send the updated/changed fields so that there should be no conflicts. However, if your code is performing an update based on previous values and you need to know if there is a conflict since the last Get, then the Modified field must also be filled with the last modified date value. If the Modified By is not the current user, and the Modified date is set and has changed, a validation/conflict error will be returned.

This call uses options identical to the Get verb.

Request (using ID):

DELETE /clay.dcw/data/156/12345/

Details:

Path: data/[tableid]/[recordid or ?unique=...]/
Verb: DELETE

Response:

"OK" or an error

This section describes the API calls for getting, querying, adding, updating and deleting documents from Clay.

As opposed to the Data API, Documents must be accessed using internal IDs (either the record ID to which the document is being attached, or the Folder ID where the document is being stored, as well as the Document ID itself). For folders, an API call is included for retrieving a list of folders. Record IDs may be retrieved using the Data or Query API, including the GET call that finds a record based on any combination of unique fields (see above).

In other words, it is typically necessary to make two API calls for Documents, one to find the record ID, and another to retrieve or add a document. When adding a new record along with an attachment, this is a natural two-step procedure: The Data Add API call will return an ID for the new record, which can then be used to add an attachment to that record.

This call retrieves a list of attachments currently attached to a specific record.

Request:

GET /clay.dcw/docs/156/12345/

Details:

Path: docs/[tableid]/[recordid]/
Verb: GET (or SEARCH)

Response:

{"rows":[{"id":12346,"data":["Doc1","TypeA","jpg","189732","1209920419","Administrator","1209920419","Administrator","23456","1103224364","12346","0","12345","156","||KeyA||KeyB||","a.jpg",""]},{"id":12347,"data":["Doc2","","zip","3458271","1209911347","Administrator","1209911347","Administrator","0","1103224364","12347","0","12345","156","","doc.zip",""]}]}

The response is a list (array) of documents each with a document ID, then an array of values (“data”) containing metadata for the document, in the following order: Document Display Name, Document Type (Clay's Document Types), File Extension, File Size (in bytes), Created Date (Unix time format), Creator Name, Modified Date, Modifier Name, Document Type ID, Creator ID, Document ID, Attachment Type (0=File, 1=URL, 2=E-Mail File, 3=Link to another Document), Record or Folder ID, Table ID, File Name or URL, Record Name.

This is used to get a list of documents currently stored in a Clay 'Document Repository' folder. This is identical to the previous API call in its format and response format.

Request:

GET /clay.dcw/docs/0/6789/

Details:

Path: docs/0/[folderid]/
Verb: GET (or SEARCH)

This retrieves the actual document itself. It uses the same request format when retrieving either a list of attachments or folder documents (see above), except with the specific document ID appended to the URL.

Request:

GET /clay.dcw/docs/156/12345/98765/

OR

GET /clay.dcw/docs/0/6789/98765/

Details:

Path: docs/[tableid or 0]/[recordid or folderid]/[documentid]/
Verb: GET (or SEARCH)
Content-Type: [Dependent on the file type]

This retrieves a list of folders currently contained in the Document Repository.

Request:

GET /clay.dcw/docs/0/

Details:

Path: docs/0/
Verb: GET (or SEARCH)
Content-Type: [Dependent on the file type]

Response:

{"id":"0","item":[{"id":"12345","text":"Folder1","item":[{"id":"12346","text":"SubFolder1","item":[{"id":"12347","text":"SubSubFolder1"},{"id":"12348","text":"SubSubFolder2"}]}]},{"id":"12349","text":"Folder2"}]}

The response is a hierarchical list of folders each with a folder ID and name (“text”) as well as any contained sub-folders (“item” - an array). The 'root' virtual folder is always a blank with an id of 0.

To add a new document either as an attachment to a record or to a folder, the URL used is identical to the Get List APIs above, except the body of the request must contain both document metadata as well as the file itself. If the URL contains a document ID, the existing document will be updated/overwritten.

Request:

POST /clay.dcw/docs/156/12345/98765/

(optional metadata in one part of the multipart form-data using POST data key/value pairs):
aname=Display Name
atype=1

(+ the file itself posted in another part of the 'multipart' body)

Details:

Path: docs/[tableid or 0]/[recordid or folderid]/[0 or documentid]/
Verb: POST (or PUT or PATCH)
Content-Type: multipart/form-data

Response (the new or updated Document ID):

12345

Request Metadata key-value pairs (all optional):

• “aname”: The display name of the document. If omitted it will use the filename or the URL.

• “atype”: 0 for file (default), 1 for URL

• “aurl”: The URL (if atype=1)

• “adate”: The Created Date. If omitted it will use the current date.

• “adoc”: The Document Type ID.

• “akeys”: A list of keywords to attach to the Document separated and delimited by two pipe characters (||). For example: ||KeyA||KeyB||

To point to an Attachment in a field of type Picture or Attachment, simply use the Data Update API described above to set the field value using the Document ID. For example, after adding a jpg attachment using the Docs Add API, it will respond with the new document ID (e.g. 2114537215). You may then call the Data Update API and set a picture field value (e.g. with field ID 154) to the Document ID (e.g. {“f154”:{“v”:“2114537215”}}

This call uses options identical to the Get verb.

Request (using ID):

DELETE /clay.dcw/docs/156/12345/98765/

OR

DELETE /clay.dcw/docs/0/6789/98765/

Details:

Path: docs/[tableid or 0]/[recordid or folderid]/[0 or documentid]/
Verb: DELETE

Response:

"OK" or an error

These are used to retrieve information about custom tables and fields.

Request:

GET /clay.dcw/tables/

Details:

Path: tables/
Verb: GET

Response:

{"tables":[{"id":1,"name":"Contact","nameplural":"Contacts"},{"id":2,"name":"Customer","nameplural":"Customers"},{"id":8,"name":"Lead","nameplural":"Leads"})

This returns a simple list of tables and their names.

Request:

GET /clay.dcw/tables/1/

Details:

Path: tables/[tableid]/
Verb: GET

Response:

{"id":1,"name":"Contact","nameplural":"Contacts","fields":[{"id":1,"name":"Status","type":11},{"id":2,"name":"Customer","type":0},{"id":171,"name":"function","type":14,"type2":1}":1}]}

The table name is returned, as well as a list of its fields. Possible field properties include:

• id: The field ID
• name: The field's display name for the current User's Role.
• desc: The short help text associated with this field for the current User's Role.
• readonly: 1 if the field cannot be changed by the current user.
• required: 1 if the field must be filled by the current user.
• type: 0=Linked, 1=Text, 2=Date, 3=Duration, 4=Datetime, 5=Numeric, 6=Currency, 7=Percentage, 9=Yes/No, 10=Notes, 11=Builtin Dropdown, 12=Single-Select, 13=Picture, 14=Function, 15=E-Mail, 16=Phone, 17=URL, 16=Work Duration, 19=Attachment, 20=Duration Seconds, 31=One-To-One Linked, 32=Many-To-Many Linked, 33=Many-To-Many Attachment, 34=Small Numeric
• type2: For fields of type custom function, this is the function's display data type.

For Single-Select fields, the drop-down values are also returned per field, in the following format (“ids” are the internal values used when setting or getting the field values, the “vals” are the display values meant for the user interface only):

"values": {"ids": ["","a","b","c"], "vals": ["[None]","aa","bb","cc"]}

This API is used to retrieve information in the form of a list of records (browser query), or a list of aggregated data (analysis query with a fixed base table and one or more indicators).

Request:

GET /clay.dcw/query/151/?columns=6,151,3:157&filters=8:12:1-555&sort=3&sortdesc=0

Details:

Path: query/[tableid]/
Verb: GET (or SEARCH or PROPFIND in case the data is too big for a GET and needs to be posted as the BODY)

Response:

{"rows":[{"id":12345,"data":["A","Active","1150329600"]},{"id":34567,"data":["B","Inactive",""]}]}

Notes:

• The tableid is mandatory and defines the base table for the query.
• If the parameters are too large to be sent using a GET, then they can be sent also in the BODY of the request (using PROPFIND if necessary). The BODY must be regular application/text format as if it were a POST, not in json format.
• The response contains a single array of rows, each with an “id” of the record in that row, and an array of values (“data”) for that row for the requested columns.
• Date values are returned as the number of seconds since 1-1-1970.

Tip: A query API call can be constructed manually using the instructions below. Or, there is a shortcut using any Clay desktop client: Build the query in the Clay Browser, then press Ctrl-Shift-R. The REST query string will be copied into the clipboard.

Parameters:

• columns (Optional): A comma-separated list of columns to return per row. Each column is either a simple fieldid that belongs to the table, or it can be a linked field in another table using the format [linkid]:[fieldid] (e.g. 3:157). The link must be linkable to the base table. If “columns” is not included, it will use the default columns for the current user currently defined for the base table.

• filters (Optional): See Dynamic Filters for details on the format of URL filters. The structure here is identical, except the REST filters may also include optional filter settings appended to the end of each filter, as follows: 1=OR (Group with other optional filters), 2=NOT (return results not matching this filter), 8=Include NULL values, 16=Filter on Join. The filter settings can be combined with a logical AND. Example (3=OR and NOT):

filters=8:12:1-555:3

• sort (Optional): A comma-separated list of which columns to sort by. The format is identical to the columns.

• sortdesc (Optional): A comma-separated list of which of the columns in the sort list should be in descending order. The size of this list must be identical to the size of the “sort” list and each value must be either 0 or 1.

• lt (Optional): A numeric value specifying the maximum amount of query results.

Request:

GET /clay.dcw/query/151/?indicators=5004:157,5005:15&agg=0,1&columns=3:157&filters=8:12:1-555&sort=5004:157&sortdesc=0

Details:

Path: query/[tableid]/
Verb: GET (or SEARCH or PROPFIND in case the data is too big for a GET and needs to be posted as the BODY)

Response:

{"rows":[{"data":["25","5125","Active"]},{"data":["5","27654","Inactive"]}]}

An Analysis query is identical to a List query, with the following differences:

• The “indicators” parameter is what defines the query as an aggregate query.
• The tableid is mandatory and defines the fixed base table for the query and all indicators and dimensions must be linkable to the base table.

Tip: As with the List query, there is a shortcut from the Clay Analysis tool by pressing Ctrl-Shift-R. But the query must have been built using a fixed base table and must contain at least one indicator.

Parameters:

• indicators (Mandatory): A comma-separated list of Indicators to aggregate in the format: [linkid]:[fieldid].

• agg (Optional): Which aggregation function to use on the indicators. The size of this list must equal the size of the indicators list. The default aggregation function is “Sum”. Other options: 0=Count, 1=Max, 2=Min, 3=Avg, 4=Sum, 5=Count Distinct, 6=Stddev, 7=Var.

• columns (Optional): This defines the Dimensions to add to the query and is identical to the parameter in the List query, except they all must in the format: [linkid]:[fieldid] and there are no default columns.

• filters (Optional): See List query.

• sort (Optional): See List query.

• sortdesc (Optional): See List query.

• lt (Optional): See List query.

A Document Repository Query is the equivalent of the 'Search' tab in the Document Repository tool in Clay. It may optionally include a List Query (“AKA Item Filter”) in order to filter the list of documents according to the records the documents are attached to.

The way this is done is using the same URL as a List Query (see above), with an additional parameter “docs=1” added to the parameters, and optional filters for the repository query. In other words, the Repository Query and the List Query may be combined into a single API call.

The response to this type of query is a list of document metadata similar to the response to a Get Attachment List.

Example #1. Request (without a List Query):

GET /clay.dcw/query/0/?docs=1&afilters=43::picture

Details:

Path: query/0/
Verb: GET (or SEARCH or PROPFIND)

Note the docs=1 in the parameters that defines this query as a Document Repository Query. This request searches for all documents with the word 'picture' in its name. Using 0 as the tableid ensures that no List Query/Item Filter will be attached.

The “afilters” parameter is optional and defines the filters for the Document Repository Query. The format for this parameter is identical in its structure to the “filters” parameter in a regular List Query above and is described under Dynamic Filters. A list of the special filters that may be used here is as follows:

• 43: Document Name
• 584: Keywords
• 527: Document Type (by ID)
• 535: Full text search in the document content
• 645: File extension
• 3: Creator (by ID)
• 6: Modifier (by ID)
• 581: Created Date
• 582: Modified Date
• 583: File Size (numeric)
• 518: Type (0=File, 1=URL, 2=E-Mail File, 3=Link to another Document)

Example #2. Request (with a List Query):

GET /clay.dcw/query/151/?docs=1&afilters=43::picture&filters=8:12:1-555

Details:

Path: query/[tableid]/
Verb: GET (or SEARCH or PROPFIND)

In this example, we combined the Document Repository Query from the previous example, with the List Query from the List example. In other words, the query is: Return a list of all documents with 'picture' in its name AND that are attached to records in table 151 with the filter 8:12:1-555.