Understanding the AppViewX CERT+ API

The AppViewX CERT+ API provides a set of RESTful endpoints for managing certificates across your infrastructure. This section covers how to make requests, handle responses, and understand the structure of the API.

RESTful HTTPS Requests

The CERT+ API uses RESTful principles, leveraging standard HTTP methods to interact with resources. All requests must be made over HTTPS to ensure security.

Type Description
GET GET requests, retrieve resource representation/information only and not to modify it.
POST POST APIs create new subordinate resources. For example, a file is subordinate to a directory containing it or a row is subordinate to a database table. In terms of REST, POST methods are used to create a new resource into the collection of resources.
PUT PUT APIs are used to update existing resources (if a resource does not exist then API may decide whether to create a new resource or not).
DELETE DELETE APIs are used to delete resources (identified by the Request-URI).

Requests

All API endpoints are accessed via the following base URL. The base URL is built in the same way by the following structure:
http://<IP/HostName/TenantName>:<GWPORT>/avxapi/<Endpoint>?<gwsource>
Explanation
  • IP/HostName/TenantName: Replace with the actual IP address, hostname, or tenant name based on the specific configuration in AppViewX.
    • IP: A unique identifier assigned to each device connected to a computer network that uses the Internet Protocol for communication

      The IP address will be included in the endpoint URL for an on-prem deployment.

    • HostName: A human-readable label assigned to a device (host) on a network

      The hostname will be included in the endpoint URL for an on-prem deployment.

    • TenantName: An identifier label for a tenant given to indicate which tenant's data the API request will access/modify

      The tenant name will be included in the endpoint URL for a SaaS deployment.

  • GWPORT: AppViewX gateway port

    A gateway port refers to a network port through which data is sent and received to communicate with a gateway in an on-prem deployment.

    Example: 31443

  • avxapi: Path parameter value (static) that is part of the endpoint's URL
  • Endpoint: Endpoint of the API, for example: execute-hook
  • gwsource: Source or origin of a gateway, for example: external.

Request Structure

All endpoints accept a request structure that should consist of JSON formatted data. To ensure the request is accepted, set the header Content-Type: application/json.

The following example shows a request to add a resource:
 {
 "payload": {
 "name": "resource_1",
 "description": "This is a sample resource."
 }
 }

Response Structure

The Content-Type of the response is typically determined by the Content-Type header, and for most endpoints, it will be application/json. All requests that reach the server, regardless of the response code, will retrieve a response body. A successful request will contain a body with the requested information, for example:

https://appviewxapi.com/avxapi/resource?gwkey=f000ca01&gwsource=external
Returns the following JSON structure that a resource is added:
{
 "response": "Resource added successfully",
 "message": "Resource added successfully",
 "appStatusCode": null,
 "tags": null,
 "headers": null
 }

Description of Server Responses

HTTP Code Response Message
200 OK The request was successful (some API calls may return 201 or 202 instead).
400 Bad Request The request is not understood or required parameters are missing.
401 Unauthorized Authentication failed or the user doesn't have permissions for the requested operation.
409 Forbidden Access denied.
404 Not Found Resource not found.
429 Too many requests The number of requests to the service has crossed the threshold.
503 Service unavailable The client cannot communicate with the service.
504 Gateway timeout The given request has exceeded the expected time.

URI Scheme

  • Host : {url}
  • BasePath : /avxapi
  • Schemes : HTTPS
  • URL : https://{url}/avxapi

Types of Accounts in AppViewX

There are two types of accounts in AppViewX:
  • User Accounts: These are used by actual users.
  • Service Accounts: These are used by system services such as web servers, automation tools, and so on.
AppViewX recommends using a Service Account for accessing APIs from automation tools. Service Accounts are supported with oAuth standard for a more secure and standard way of accessing APIs.
Note: AppViewX supports both User Account and Service Account for accessing APIs.