Share:API

From Adobe Labs

Table of contents

3.1.1 Request methods
3.1.2 Request path basics
3.1.3 Request authorization

3.1.3.1 Using an HTTP request header
3.1.3.2 Table: Authorization header parameters
3.1.3.3 Using authorization parameters in an HTTP request

3.1.4 Requests with XML payloads

3.2 Handling HTTP responses

3.2.1 XML elements common to file and folder nodes
3.2.2 XML elements specific to file nodes
3.2.3 Error Messages for responses

4 Authentication and sessions

4.1 Requesting an authorization token

4.1.1 Authorization response
4.1.2 Error messages for authization

4.2 Starting a new session

4.2.1 Authorization response
4.2.2 Authorization error messages

4.3 Ending a session

4.3.1 Error messages for ending a session

5 Managing files and folders

Overview

Note: This document is also available as a PDF from HERE.

The Share APIs provide developers with a platform for leveraging Share in their own applications. Share enables any number of users with the requisite privileges to manipulate files and folders located on https://share.acrobat.com. Share uses a relatively simple REST-based interface, so using it requires that developers know a few details about the following:

HTTP requests and responses
Authentication and sessions
Managing files and folders

Accessing the Share API

Developers typically start with an application or create one (such as an AIR application). The application provides the user interface end users interact with to access the Share service. It's the developer's job to connect the application to a networking layer that can create the HTTP headers and XML requests that the Share service can parse. You can write your own code or leverage an existing library for this purpose. Some existing libraries include the following:

Actionscript 3: AirShare demo source code for AIR M6
Actionscript 3: Working (compiled) demo for AIR M6
Java library See also the Javadoc
Ruby (Developed by Hideyuki KATO)
Python (Developed by Vivek Kapoor ]
Cold Fusion (Developed by Ray Camden)

HTTP requests and responses

To write applications that leverage or to interact with the Share service, developers should understand the basics of constructing HTTP requests and parsing the HTTP responses. For an overview of Share-specific details, see the following:

Making HTTP Requests
Handling HTTP responses

Making HTTP Requests

Share API requests may consist of the following components:

Request methods: Supported methods include GET, POST, PUT, DELETE, and MOVE. For certain requests, alternate syntax is supported as described below.
Request path basics: The root request URL to which parameters may be appended.
Request authorization: Authorization parameters including a required signature.
Requests with XML payloads: A request body in XML format that may be required depending on the nature of the request.

Request methods

Each request begins with an HTTP method. Because some clients do not support every HTTP method, alternate syntax is supported. For example, where DELETE is not supported by the client, you can use POST and set a query parameter method to the needed method. For example, the two DELETE requests below are equivalent.

  DELETE https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]
  POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]?method=DELETE

Request path basics

The base (root) path for all requests is always in the format of <https://><base URL><trailing slash>. The base path is then appended with three possible paths plus request-specific node or path information. The possible paths include the following:

auth: Gets an authorization token for use with subsequent requests.
sessions: Starts and ends sessions.
dc: Identifies files and folders.

  https://api.share.acrobat.com/webservices/api/v1/

For example, a dc/share request with a node ID of xyzDoc would be: POST https://api.share.acrobat.com/webservices/api/v1/dc/xyzDoc/share/. All requests must include the trailing slash.

Request authorization

Using an HTTP request header

Most HTTP requests will include an authorization header which have the following requirements:

New sessions require four parameters: Authorization, apikey, data, and sig. An authorization header for getting the list of nodes in the root folder for a new session could look like:

  Authorization: AdobeAuth
  apikey="1dbcbb7111618358a3a6c7f62b152381",
  data="POST https://api.share.acrobat.com/webservices/api/v1/auth/ 1196363602050",
  sig="1bda167c5c4a96483b50788430351b43"

Existing sessions require five parameters: Authorization, apikey, data, sig, and sessionid. An authorization header for getting the list of nodes in the root folder while in an existing session could look like:

  Authorization: AdobeAuth
  sessionid="3bafbc700acd2ca0d38433230a408c2a",
  apikey="6b8b71755fe80445276d0f7d1d5c3d65",
  data="GET https://api.share.acrobat.com/webservices/api/v1/dc/ 1188518642796",
  sig="308421b3840c7bad180e7ea13b32ffde"

A correctly computed request signature.

Table: Authorization header parameters

Parameter	Description
AdobeAuth	A literal string indicating that this is an authorization header.
apikey	The API key registered to this application.
data	A concatenation of three values separated by spaces: the HTTP method, the URL of the request, and the timestamp of the request in milliseconds.
sig	The MD5 digest of the string formed by concatenating data with the shared secret returned by an authorization token request.
sessionid	The session ID returned from a new session request. Not used for the initial authorization token and new session requests.

Using authorization parameters in an HTTP request

For clients that do not have access to HTTP headers, the authorization parameters can be passed to Share via an HTTP request method. The parameters apikey, calltime, and sig are required. sessionid is only required for existing sessions.

data is not required. The data string to sign consists of the following:

The HTTP method (use the intended method if routing through POST)
Space
the URL of the request excluding the query parameters and host
Space
The query parameter name/value pairs in alphabetical order and separated by spaces (ignore the method parameter if used): apikey, calltime, and sig

For example, the data string for the URL https://api.share.acrobat.com/webservices/api/v1/dc/ could look like:

  GET /webservices/api/v1/dc/
  apikey=6b8b71755fe80445276d0f7d1d5c3d65
  calltime=1188518642796
  sessionid=3bafbc700acd2ca0d38433230a408c2a

As with the HTTP authorization header, the signature is formed by taking the MD5 digest of the concatenated data string and the shared secret. After the signature is calculated, the final URL with all the query parameters could appear as below:

  https://api.share.acrobat.com/webservices/api/v1/dc/
  ?apikey=6b8b71755fe80445276d0f7d1d5c3d65
  &calltime=1188518642796
  &sessionid=3bafbc700acd2ca0d38433230a408c2a
  &sig=308421b3840c7bad180e7ea13b32ffde

Requests with XML payloads

As you will learn from the subsequent sections that describe in detail how to communicate with the Share API, not all requests include an XML body. However, when they do, the request XML body element is request. Additional elements containing parameters may reside within the request element. While GET requests will not have elements, PUT and POST usually do. As you refer to the following sections, if a feature is associated with a parameter table, then an XML body must be used. If the parameter is not explicitly listed as optional in the tables below, it is required.

  <request>
  <some element/>
  <anotherelement>Some parameter value</anotherelement>
  </request>

Handling HTTP responses

HTTP responses should be parsed and handled according to the requirements of your application. In general:

Successful responses will return two items: an HTTP status code of 200 and an optional XML payload in the response body.
Unsuccessful responses will return with an error code in the 400 or 500 range and will include the error message in the response body.

XML elements common to file and folder nodes

HTTP responses may or may not be returned with an XML payload depending on the nature of the response. Responses that return information about a file or folder node will generally have the elements shown below.

Table: HTTP response attributes: for files and folders

Element	Description
createddate	The node creation date.
description	The node description.
directory	True if the node is a folder or a directory.
hascontent	True if the node is a file.
link	True if someone else has shared this file with you.
modifieddate	The nodes last modified date.
name	The node name.
nodeid	The string that uniquely identifies the node.
owner	The Adobe ID of a given nodes owner.
ownername	The full owner name of a given node.

XML elements specific to file nodes

HTTP responses may or may not be returned with an XML payload depending on the nature of the response. Responses that return information about a file nodes will generally have the elements shown below.

Table: HTTP response attributes: for files only

Element	Description
adobedoc	True if the file is a special file from Adobe.
author	The author of a document, if the author's name was able to be extracted from file metadata.
filesize	The file size in bytes.
flashpreviewembed	The HTML object code that can be used to embed a flash preview in a web page.
flashpreviewpagecount	The number of document pages if a flash preview was successfully generated.
flashpreviewstate	The preview state: 1: The flash preview is ready. 0: The flash preview is still being generated. -1: Flash preview generation failed.
mimetype	The file type, such as PDF, doc, and so on.
pdfstate	-1: Failed. 0: Unknown. 1: Not available for download. 2: Available for download. 3: Converting.
recipients (child element's "recipient")	The Adobe IDs of each person with which the document has been shared. Each Adobe ID will be a child recipient element.
recipienturl	The URL a recipient uses to view a document (such as a link in an email).
sharelevel	The share level: 0: The file is unshared. 1: The file is only accessible to those with whom the file has been shared. 2: The file is publicly accessible.
thumbnailstate	The thumbnail state: 1: The thumbnail is ready 0: the thumbnail is still being generated. -1: Thumbnail generation failed.

Error Messages for responses

The error messages shown below pertain to all calls and may be returned by any request. Additional errors may be returned for any request-specific errors.

Table: HTTP response: error messages

Status	Reason
BadApikey	The given API key is invalid.
BadAuthHeader	The authorization header has the wrong format or syntax.
BadAuthQuery	The query does not contain the required parameters. This error is only returned when the authorization parameters are passed in an HTTP request rather than in an HTTP header as described in Using authorization parameters in an HTTP request.
BadCalltime	The given calltime has problems: Either it does not come after the calltime of the most recent successful request, or The request was issued too soon after the prior request. The suggested time between requests per session is half a second.
BadFormat	The request body is malformed.
BadSessionid	The given sessionid does not exist or is expired.
BadSig	The authorization signature is incorrect.
Error	An unknown error has occurred.
LimitReached	The number of allowable requests was exceeded in the last hour.
MissingElements	The request body is missing required elements.
Unauthorized	The user does not have authorization to perform the requested action.

Authentication and sessions

Before an application can leverage the Share API, the application must initiate an API session on behalf of the user. Doing so requires two steps:

Requesting an authorization token
Starting a new session

Requesting an authorization token

Authenticating a request requires that it includes a user's Adobe ID credentials. When the Share service receives the user's username and password, it returns an authorization token.

auth/ gets an authorization token for use with subsequent requests. It is only used for initial authentication. Before starting a session, you must post a user's credentials to receive an authorization token for use with subsequent requests.

Example: auth token request path

  POST https://api.share.acrobat.com/webservices/api/v1/auth/

Table: Auth request XML parameters

Parameter	Description
username	The user's Adobe ID username.
password	The user's Adobe ID password.

Example: auth request

  <request>
  <username>user@domain.com</username>
  <password>qwerty123</password>
  </request>

Authorization response

Table: Response: auth XML parameters

Parameter	Description
authtoken	A token that can be used to request a new session. Each token is valid only for one session start request.

Example: auth response

 <response status="ok">
 <authtoken>22e7909e7453cf0b62f656ecae66efdf</authtoken>
 </response>

Error messages for authization

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: auth api request

Error	Description
BadLogin	Invalid username or password.
LockedOut	Too many failed login attempts; try again later.

Starting a new session

After an authentication token has been returned from the previous request, that token can be used once to start a new session.

sessions/ starts and ends Share sessions. After getting an authorization token, use sessions to obtain a Share session ID for use with all subsequent requests. An authorization token can be used only once to request a session. If this session request fails, a new authorization token is required (see Requesting an authorization token).

Example: session token request path

  POST https://api.share.acrobat.com/webservices/api/v1/sessions/

Table: Auth request XML parameters

Parameter	Description
authtoken	Single-use authorization token returned from auth/.

Example: session request

  <request>
  <authtoken>22e7909e7453cf0b62f656ecae66efdf</authtoken>
  </request>

Authorization response

Table: Session response XML parameters

Parameter	Description
sessionid	The new session ID which to use in the Authorization header of all subsequent requests.
secret	The new, shared secret to use in the Authorization header of all subsequent requests.
level	User's subscription level: 0: Trial. >0: Subscribed. -1: Special account.

Example: Response: session XML parameters

  <response status="ok">
  <sessionid>1ab1a6190dc1f1f849ca7649190cca83</sessionid>
  <secret>3965c47eb9c937f78d49f3f33e19ca45</secret>
  <level>1</level>
  </response>

Authorization error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: session api request

Error	Description
BadAuthtoken	Invalid authorization token.

Ending a session

delete immediately ends a session. As shown below, there are alternate methods for ending a session. The session will automatically be deleted after 1 hour of inactivity.

Example: HTTP request: for ending a session (method 1)

  DELETE https://api.share.acrobat.com/webservices/api/v1/sessions/[sessionid/]

Example: HTTP request for ending a session (method 2)

  POST https://api.share.acrobat.com/webservices/api/v1/sessions/[sessionid/]?method=DELETE

Error messages for ending a session

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: End session request

Error	Description
BadSessionid	The session ID is invalid.

Managing files and folders

Once the use is authenticated and a session ID obtained through the use of auth and sessions, you application can manipulate files and folders as well as access to them.

dc/ provides requests to work with files and folders. Requests using dc/ may or may not require an XML request payload. In general, GET requests do no require XML while most PUT and POST requests provide XML containing information about files or folders or instructions for the Share API.

For example, using a GET method with dc and a node ID does not require XML. Share simply returns all the child nodes for that node ID. Each child node is returned with the information shown in XML elements common to file and folder nodes as well as XML elements specific to file nodes if it is a file.

Many PUT and POST requests require an XML payload in the request as described below. The XML elements and their parameters listed in the tables below are required.

Listing file and folder information

A dc request with a node ID retrieves information about a given node. The following rules apply:

If the node ID is omitted, the root folder is used.
If a folder's node ID is provided, its files and folders are returned in the children element.

Example: dc request: GET for listing node details

  GET https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]

Example: dc request: XML payload for listing node details

 <response status="ok">
 <node />
 <children>
 <node>
    snip ----------- File and folder details -----------
 <node />
 <node>
    snip ----------- Another node.... until the nth node -----------
 <node /
 </children>
 </response>

Creating a PDF

See Uploading a file below.

Uploading a file

To upload a file, construct a POST request with a node ID and an XML payload describing the file. The file will be added to the folder with the given node ID. The following rules apply:

If a node ID is not specified, the file is uploaded to the root node.
If the given node ID corresponds to an already existing file, that file will be replaced with the uploaded file.

Example: dc request: POST for file upload

POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid]

Example: dc request: XML payload for file upload

 <request>
 <file>
 <name>myfile.pdf</name>
 <description>My File</description>
 <renditions>true</renditions>
 <createpdf>true</createpdf>
 </file>
 </request>

Table: dc request XML parameters: file upload

Parameter	Description
name	File name.
description	Optional.
renditions	If true, uploads the file, and then automatically creates thumbnail, preview, and PDF renditions after upload. If false, adds only the file.
createpdf	Optional. If true, uploads the file, and then automatically createsa PDF of the file. If false, adds only the file.

Multi-part POST requests

Files can be uploaded and added through the API using multi-part POST requests. The format for these requests adheres to the standard RFC1867. For details, see http://www.ietf.org/rfc/rfc1867.txt.

Example: dc request: Multi-part POST request

 POST /webservices/api/v1/dc/ HTTP/1.1
 Host: api.share.acrobat.com
 Content-type: multipart/form-data, boundary=314159265358979323846
 Content-Length: 12345
 Authorization: AdobeAuth................
 
 ------------------314159265358979323846
 
 content-disposition: form-data; name="request"
 <request>
 <file>
 <name>test.pdf</name>
 <description>My File</description>
 <renditions>true</renditions>
 </file>
 </request>
 
 ------------------314159265358979323846
 
 content-disposition: form-data; name="file"; filename="test.pdf"
 Content-Type: application/octet-stream
 Content-Transfer-Encoding: binary
 binary data here...
 
 ------------------314159265358979323846

Upload response

Share returns all the node elements shown in shown in XML elements common to file and folder nodes as well as XML elements specific to file nodes if it is a file.

Example: dc request: File upload response

 <response status="ok">
 <node>
 first node data
 </node>
 
.....
 
 <node>
 nth node data
 </node>
 </response>

Upload error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: File upload

Error	Description
QuotaReached	Adding the file would exceed the user's storage quota.

Adding a folder

To add a folder, construct a POST request with a node ID and an XML payload describing the folder. The folder will be added to the folder with the given node ID. The following rules apply:

If a node ID is not specified, the folder is uploaded to the root node.
If the given node ID corresponds to an already existing folder, that folder will be replaced with the uploaded file.

Example: dc request: POST for adding a folder

  POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid]

Example: dc request: XML payload for adding a folder

  <request>
  <folder>
  <name>New Folder</name>
  <description>This is a new folder</description>
  </folder>
  </request>

Table: dc request XML parameters: Adding a folder

Error	Description
name	The new folder's name.
description	Optional. A description of the new folder.

Adding a folder response

Share returns all the node elements shown in XML elements common to file and folder nodes as well as XML elements specific to file nodes if it is a file.

Example: Response: for adding a folder

 <response status="ok">
 <node>
 first node data
 </node> 
 
.....
 
 <node>
 nth node data
 </node>
 </response>

Adding a folder error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: Adding a folder

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the sent node ID doesn't exist.

This is a generic error. Error handling will be further refined in future releases.

Deleting a file or folder

To delete a file or folder, construct a request with a node ID as shown below. The node will be deleted to the folder with the given node ID. The following rules apply:

If a node ID is not specified, the folder is uploaded to the root node.
If the given node ID corresponds to an already existing folder, that folder will be replaced with the uploaded file.
The node ID is required because you cannot delete the root folder.

Example: DELETE method for deleting nodes

 DELETE https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]

Example: POST method for deleting nodes

 POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]?method=DELETE

Deleting a node response

No XML is returned if there are no errors The response header includes the HTTP status code of 200 indicating the request has succeeded.

Deleting a node error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: Deleting a node

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the sent node ID doesn't exist.

This is a generic error. Error handling will be further refined in future releases.

Moving or renaming a file or folder

To move or rename a node (a file or a folder), construct a request with a node ID as shown below. The node is moved or renamed as specified in the request. The following rules apply:

newname is only required for renaming files.
Moving and renaming can occur in one operation (request).
Folders are moved in the same way as files. If a folder moves, all of its files and subfolders move with it.

Example: MOVE for renaming nodes

 MOVE https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]?[destnodeid=newfolderid&]newname=newid

Example: POST for moving nodes

 POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]?method=MOVE

Table: dc request XML parameters: Moving or renaming file and folder

Parameter	Description
destnodeid	Optional and for moving only. The folders node id or else the root for the root folder.
newname	The new name for the file or folder. For moving a node, it can be the current name.

Moving or renaming node response

No XML is returned if there are no errors The response header includes the HTTP status code of 200 indicating the request has succeeded.

Moving or renaming node error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: moving or renaming a node

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the sent node ID doesn't exist.

This is a generic error. Error handling will be further refined in future releases.

Sharing a file

To share a file or a folder, construct a PUT request with a node ID and an XML payload describing the folder. You can specify an optional email message which is automatically sent to those you share the node's URL with. The following rules apply:

If the level parameter is 1, access is granted to only those users with an Adobe ID that matches one of the given email addresses.
If the level parameter is 2, anyone can access the file.
A message is optional.

Example: PUT for sharing files

 PUT https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]share/

Example: XML payload for sharing files

 <request>
 <share>
 <user>alice@example.com</user>
 <user>bob@example.com</user>
 </share>
 <message>hello world</message>
 <level>2</level>
 </request>

Table: dc request XML parameters: File sharing

Parameter	Description
level	There are two possible values: 1: Private share: Access is limited to the specified users. 2: Public share: Anyone can access the files.
message	Optional. A message to be included in the notification email.
user	The user's email address.

Parameter

Description

level

There are two possible values:

1: Private share: Access is limited to the specified users.

2: Public share: Anyone can access the files.

message

Optional. A message to be included in the notification email.

user

The user's email address.

Sharing a file response

No XML is returned if there are no errors The response header includes the HTTP status code of 200 indicating the request has succeeded.

Sharing a file error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: Sharing a file

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the sent node ID doesn't exist.

This is a generic error. Error handling will be further refined in future releases.

Adding or removing recipients

To add or remove user access to a file that has been shared, construct a POST request with a node ID and an XML payload describing the changes. You can specify an optional email message which is automatically sent to those whose privileges change. The following rules apply:

Users are specified by valid Adobe ID email addresses.
Grant access by listing user's email addresses under the parent share element.
Remove access by listing user's email addresses under the parent unshare element.
Messages are optional.
If you want to provide a different message for those with whom you unshare and share documents. In that case, share and unshare in separate requests.

Example: POST for adding or removing recipients

 POST https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]share/

Example: XML payload for adding or removing recipients

 <request>
 <share>
 <user>alice@example.com</user>
 <user>bob@example.com</user>
 </share>
 <unshare>
 <user>charles@example.com</user>
 </unshare>
 <message>You now have access to my documents (except for Charles).</message>
 </request>

Table: dc request XML parameters: Adding or removing recipients

Parameter	Description
share	The parent element for the list of users with which to share the file or folder.
unshare	The parent element for the list of users with which to unshare the file or folder.
user	The user(s) email address to add or remove.
message	Optional. The message to be included in an email to the user.

Adding recipient response

No XML is returned if there are no errors The response header includes the HTTP status code of 200 indicating the request has succeeded.

Adding recipient error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: Adding a recipient

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the user ID is malformed.

This is a generic error. Error handling will be further refined in future releases.

Accessing file renditions

A rendition is the representation of the file provided to the requester. A request can ask for either a thumbnail, the file source, or both. To request a file rendition, construct a request with a node ID. The following rules apply:

Folder nodes do not have thumbnails or a source.
thumbnail returns a thumbnail (if any) and src returns the file source.

Example: GET for a thumbnail

 GET https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]thumbnail/

Example: GET for the file source

 GET https://api.share.acrobat.com/webservices/api/v1/dc/[nodeid/]src/

Table: dc request XML parameters: Adding or removing recipients

Parameter	Description
thumbnail	The file's thumbnail, if any.
src	The actual node's source. For example, for a text file, it returns the text.

Assessing file rendition response

Depending on the nature of the request, Share can return the following:

The actual file thumbnail; and/or,
The actual file source.

Assessing file rendition error messages

If the request fails, error messages may be returned. See also the general errors described in Error Messages for responses.

Table: Error messages: deleting a node

Error	Description
Error	The error is returned when the Share API cannot understand the request; for example, when the node ID doesn't exist or it refers to a folder instead of a file.

This is a generic error. Error handling will be further refined in future releases.

Retrieved from "http://labs.adobe.com/wiki/index.php/Share:API"

Search

Personal tools

Views

Share:API

From Adobe Labs

Overview

Accessing the Share API

HTTP requests and responses

Making HTTP Requests

Request methods

Request path basics

Request authorization

Using an HTTP request header

Table: Authorization header parameters

Using authorization parameters in an HTTP request

Requests with XML payloads

Handling HTTP responses

XML elements common to file and folder nodes

XML elements specific to file nodes

Error Messages for responses

Authentication and sessions

Requesting an authorization token

Authorization response

Error messages for authization

Starting a new session

Authorization response

Authorization error messages

Ending a session

Error messages for ending a session

Managing files and folders

Listing file and folder information

Creating a PDF

Uploading a file

Multi-part POST requests

Upload response

Upload error messages

Adding a folder

Adding a folder response

Adding a folder error messages

Deleting a file or folder

Deleting a node response

Deleting a node error messages

Moving or renaming a file or folder

Moving or renaming node response

Moving or renaming node error messages

Sharing a file

Sharing a file response

Sharing a file error messages

Adding or removing recipients

Adding recipient response

Adding recipient error messages

Accessing file renditions

Assessing file rendition response

Assessing file rendition error messages