1. Overview

Spotfire Server REST API to generate and obtain a deployment report.

1.1. Version information

Version : 1

1.2. Tags

  • deployment-report : Spotfire deployment report API

2. Authentication and authorization

The API uses the OAuth 2.0 protocol for authentication and authorization, with the Spotfire Server itself as Authorization Server. Authentication and authorization can also be delegated to an external Authorization Server through the use of Token Exchange.

Note: The API does not use HTTP sessions so there is no need to maintain session cookies.

Note: All communication should always be done over HTTPS when using OAuth 2.0.

2.1. Basic steps

  1. Register an API client using the register-api-client command to obtain client credentials.

    When registering the client you specify what type of client it is, what grants and scopes the client should be able to use etc.

  2. Obtain an access token using one of the following alternatives

    • To use the Authorization Code grant follow the instructions in section 4.1 of RFC 6749.

    • To use the Client Credentials grant follow the instructions in section 4.4 of RFC 6749.

    • To use a Refresh Token follow the instructions in section 6 of RFC 6749.

    • To use the Token Exchange grant follow the instructions in section 2 of RFC 8693.

      Additional information on how to get the access token

    • The OAuth 2.0 Authorization Server Metadata (RFC 8414) can be retrieved from: http[s]://<host>[:<port>]/spotfire/.well-known/oauth-authorization-server

    • The Authorization Endpoint can be accessed at: http[s]://<host>[:<port>]/spotfire/oauth2/auth

    • The Token Endpoint can be accessed at: http[s]://<host>[:<port>]/spotfire/oauth2/token

    • When calling the Token Endpoint the client must authenticate using either the client_secret_post or the client_secret_basic scheme (determined when registering the client) as described in section 2.3.1 of RFC 6749, using the credentials obtained when registering the client (unless the client is a public client to which no credentials have been issued). Public clients _must include the client_id parameter.

    • The initial request (to the Authorization Endpoint in the case of the Authorization Code grant, or to the Token Endpoint in the case of the Client Credentials or the Token Exchange grant) must include any and all scopes required to access the services that the client intend to access (see the documentation of each service for details).

  3. Include the access token in all requests to the API, in an Authorization header as described in section 2.1 of RFC 6750.

    • The access token has a limited lifetime, after which a new token must be obtained by repeating step 2.

    • An access token is only valid for the services and operations described in the scope parameter provided when obtaining the access token. The available scopes are described in the documentation for each service.

2.2. Additional information

  • Four client profiles are supported: other, web, native and user_agent. The profile other should be used by a typically headless application performing requests on its own behalf. The profile web should be used by a server-side web application performing requests on behalf of an end-user. The profile native should be used by a native client, such as an iOS or Android app, performing requests on behalf of an end-user. The profile user_agent should be used by a client-side (JavaScript) web application, performing requests on behalf of an end-user.

  • The Authorization Code, Client Credentials, Refresh Token and Token Exchange grants are supported.

  • Clients with profile web, native or user_agent can only use the Authorization Code, Refresh Token and Token Exchange grants. Clients with profile other can only use the Client Credentials and Token Exchange grants.

  • Refresh tokens MAY be issued to allow access also when no end-user is present (useful when for example performing periodic uploads or similar). To request a refresh token to be issued the scope offline should be included in the request. For more information see section 1.5 of RFC 6749.

    • Refresh tokens that are no longer needed SHOULD be revoked, as described in RFC 7009.

  • Public clients (clients without client credentials) MUST use PKCE (RFC 7636). Confidential clients SHOULD use _PKCE.

  • Native clients can use any of the three ways of receiving the response listed in section 7 of RFC 8252.

    • To use Private-Use URI Scheme Redirection a custom URI scheme must be registered when registering the client.

    • To use Claimed "https" Scheme URI Redirection an authorized redirect URI must be registered when registering the client.

    • Loopback Interface Redirection is supported for all native clients. The scheme must be http. The host must be either 127.0.0.1 (IPv4) or [::1] (IPv6). The path can be either / or /auth. The port is variable.

  • Native clients SHOULD adhere to the guidelines outlined in OAuth 2.0 for Native Apps (RFC 8252).

  • All clients SHOULD implement support for OAuth 2.0 Authorization Server Issuer Identification (RFC 9207).

2.3. Using an external Authorization Server

The Token Exchange grant can be used to authorize use of the Spotfire Server API using an external Authorization Server. The API client will first obtain a subject token from the external Authorization Server and then, through Token Exchange towards the Authorization Server of the Spotfire Server, exchange that token for an access token that can be used with the Spotfire Server API. The subject token issued by the external Authorization Server MUST follow the format of RFC 9068 (JWT Profile for OAuth 2.0 Access Tokens) and the requirements described further down.

2.3.1. Requirements

The Token Exchange grant must be explicitly enabled by configuring the Spotfire Server to trust tokens issued by the external Authorization Server. Configuration is done using the config-rfc-9068-token-exchange-authenticator command. The most basic configuration only requires setting the URI to the OAuth 2.0 Authorization Server Metadata document of the external Authorization Server. The metadata document MUST contain an issuer and a jwks_uri (with the keys needed to verify subject token signatures).

Requirements on the Token Exchange request

  • The value of the resource parameter MUST be the public address of the Spotfire Server.

  • The audience parameter MUST NOT be included.

  • The scope parameter MUST be included.

  • The value of the requested_token_type parameter MUST be urn:ietf:params:oauth:token-type:access_token.

  • The value of the subject_token parameter must adhere to the requirements described below.

  • The value of the subject_token_type parameter MUST be urn:ietf:params:oauth:token-type:jwt.

  • The actor_token and actor_token_type parameters MUST NOT be included.

  • If the client is a public client then the client_id parameter MUST be included. Otherwise the client MUST authenticate.

Requirements on the subject token

  • Must adhere to the requirements of RFC 9068 (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens).

  • The aud claim MUST include the Spotfire Server Token Endpoint URI.

  • The token SHOULD contain a may_act claim.

  • If the token contains a may_act claim then the value of the client_id sub-claim MUST be client ID of the client using the token.

  • The token SHOULD contain a scope claim.

  • If the token contains a scope claim then all scopes requested (through the scope parameter) MUST also be present in the scope claim.

3. API Endpoint URLs

All API services can be accessed at the following location, where ServicePath is one of the entries in the Resources listing below:

http[s]://<host>[:<port>]/spotfire/api/rest/deploymentreport/v1/<ServicePath>

Example:

https://example.com:8443/spotfire/api/rest/deploymentreport/v1/report/status/<reportId>

You can download the Open API Specification (OAS) for this REST API as a JSON file from the Spotfire Server at http[s]://<host>[:<port>]/spotfire/api/v2/api-docs?group=deployment-report. This OAS file can be accessed at this location by all authenticated users (unless disabled through configuration). The OAS file can be used to generate client stubs, which will contain all types and methods that can be used with the API.

You can also browse the OAS for this REST API using the Swagger UI, available at http[s]://<host>[:<port>]/spotfire/api/swagger-ui.html?urls.primaryName=deployment-report

4. Usage

This API is used to generate and download a deployment report. All calls assume that a successful authentication has been made, see above.

Note
 Clients should be as resilient as possible, e.g. they should be able to handle any 4XX or 5XX http status codes and not just the ones documented here.
Note
 In later versions of this API, additional JSON properties might be added. Make the JSON response parsing done by the API client forgiving, so it can accept unexpected properties and different ordering.

5. Resources

5.1. Deployment-report-controller

5.1.1. Obtain a deployment report

GET /report/obtain/{reportId}
Description

Download the complete report as a zip file.

Parameters
Type Name Description Schema Example

Path

reportId
required

The report ID

string

"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Responses
HTTP Code Description Schema

200

The complete deployment report.

204

The deployment report is not yet done for downloading.

404

Deployment report not found.

ErrorResponse
Produces

  • application/octet-stream

Security
Type Name Scope

oauth2

spotfire-api-oauth2

api.deployment-report.generate

5.1.2. Generate and download a deployment report

GET /report
Description

Assembles a deployment report and returns it as a zip file. Generates and downloads a report in one call.

Responses
HTTP Code Description Schema

200

Report successfully generated.

500

Report could not be generated.
Produces

  • application/octet-stream

Security
Type Name Scope

oauth2

spotfire-api-oauth2

api.deployment-report.generate

5.1.3. Check status of a deployment report job

GET /report/status/{reportId}
Description
Can be used to see if the process succeeded or not and to check whether the report is ready to download.
Parameters
Type Name Description Schema Example

Path

reportId
required

The report ID

string

"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Responses
HTTP Code Description Schema

200

Information about the deployment report that is being generated.

DeploymentReportInfo

404

Deployment report not found.

ErrorResponse
Produces

  • application/json

Security
Type Name Scope

oauth2

spotfire-api-oauth2

api.deployment-report.generate

5.1.4. Start generating a deployment report

GET /report/generate
Description

Starts the process of generating a deployment report.

Responses
HTTP Code Description Schema

200

Information about the deployment report to be generated. Contains the report ID used to check status of the process and to obtain the completed report.

DeploymentReportInfo
Produces

  • application/json

Security
Type Name Scope

oauth2

spotfire-api-oauth2

api.deployment-report.generate

6. Definitions

6.1. Status

Enum value Schema

IN_PROGRESS

string

COMPLETED

string

FAILED

string

CANCELLED

string

6.2. DeploymentReportInfo

Information about a deployment report job.

Name Description Schema

reportId
optional

The attachment ID for the report file.
Example : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

string

status
optional

The status of the deployment report.
Example : "IN_PROGRESS"

Status

attachmentId
optional

The attachment ID for the report file.
Example : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

string

creationTime
optional

The time when the deployment report job was started.

string

warnings
optional

Deployment report generation warnings.

<string> array

complete
optional

True if the deployment report is complete and ready for download, false otherwise.
Example : "false"

boolean

7. Security

7.1. spotfire-api-oauth2

Type : oauth2
Flow : application
Token URL : /spotfire/oauth2/token

Name Description

api.deployment-report.generate

Generate and download a deployment report

8. Common Responses

HTTP Code Description Reason

401

Not Authenticated

The client has not been authenticated

403

Not Authorized

The client is not authorized to access the requested resource

500

Internal Server Error

Something went wrong when the processing the request

9. Error Codes

A request to the API that results in an ErrorResponse will have a response body with the following format:

{
  "error": {
    "code": "server_busy",
    "description": "The server is currently too busy to handle the request"
  }
}

where description is a description of the error, and code can be one of the following predefined API error codes:

Error Code HTTP Status Description

invalid_request

400

The request was invalid or incomplete

precondition_failed

400

A precondition for the request was not met

bad_digest

400

The supplied digest is not valid or does not match the digest of the request body

not_authenticated

401

The API client is not authenticated

not_authorized

403

The API client is not authorized to access the requested resource

not_found

404

The requested resource cannot be found

job_unknown

404

The referenced job does not exist, or the client does not have access to it

method_not_allowed

405

The HTTP method is not allowed

already_exists

409

The resource already exists

limit_exceeded

413

A resource limit has been reached

unsupported_mediatype

415

The media type of the request payload is unsupported

rate_limit_exceeded

429

A resource limit has been reached

internal_error

500

The server encountered an error when processing the request

server_busy

503

The server is currently too busy to handle the request

10. Configuration

The API is enabled by default. To disable it or to make other configuration changes, use the config-web-service-api command. For more information see the section Configuration using the command line of the Spotfire© Server and Environment Installation and Administration manual.

11. Additional resources

For more information please refer to these resources: