General standards and guidelines

This section provides standards and guidelines for working with the REST API specification in ValueEdge.


The principles guiding the specification follow the basic REST guidelines were introduced by Roy Fielding. For details, see Representational State Transfer (REST)

These are the guidelines that are required for implementing REST over HTTP. These guidelines are adapted to ValueEdge. Note, however, that the guidelines follow the standard.

Back to top


Platforms and languages Applications can be written in any language and on any platform that support REST. For details about REST, see Representational state transfer.
Data formats

The API supports only application/json representation both on request and response.

Data is submitted and returned in the JSON format, unless otherwise specified in the reference for a resource. This API uses the ECMA 404 Specification.

Communication and security
  • The API communicates via HTTPS.
  • The REST API cannot run in a configuration where a proxy server requires Basic Authentication before allowing access to the REST resources.
  • The only value supported for the Accept-Encoding header is gzip. If any other value is specified, the response is not encoded.
  • To comply with security guidelines, the REST API enforces a policy that defines the maximum input allowed for POST and PUT requests. The global default value for the maximum input size is 100MB. Site admins can modify this value by setting the MAX_REQUEST_LENGTH parameter. Some resources let you set a custom limit which overrides the global value. This allows you to make subtle adjustments per functionality, such as logs, coverage, vulnerabilities, import shared-space, and attachments.

URL encoding

Request URIs sent by an application must be URL-encoded. For details about URL encoding, see IETF: Uniform Resource Identifier (URI): Generic Syntax.

For details, see URIs.


When sending data, always send a Content-Type header to specify the type of data being sent from the client to the server.

The Content-Type header should be application/json, including when authenticating.

Do not send a Content-Type header, unless content is sent.

Always send an Accept header to specify the format of the data to receive from the server.

For details, see Performing requests.

Resend cookies

In any request you send to the server, return all cookies sent by the server in the preceding response using the "Set-Cookie" header. See Failing to resend cookies can result in authentication expiration while the user is interacting with the REST API service.

For details, see Session management and expiration.

Time data

Time data is saved in the database in UTC format. The REST API is unable to convert the UTC time to the local time. Therefore, the UI client converts the UTC format to the global user's local time.

REST API consumers should do the same with the time data.

Back to top

Next steps: