API Reference Archives - SearchStax Docs

Managed Search APIs Overview

Tom Humbarger — Wed, 10 May 2023 17:50:08 +0000

Managed Search APIs Overview

Overview

The SearchStax Managed Search service provides various APIs for supporting the creation, deletion, and management of Solr deployments.

Learn more about SearchStax Managed Search Solr APIs:

SearchStax Managed Search deployments also support custom JAR files to add custom analyzers, tokenizers, query parsers and other plugins for Solr deployments. Learn more about custom JAR files for SearchStax Managed Search .

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Managed Search APIs Overview appeared first on SearchStax Docs.

Provisioning API – Authentication

admin — Thu, 04 Mar 2021 10:27:07 +0000

Provisioning API – Authentication

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion, and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

The Provisioning API uses two methods of authentication appropriate to two levels of security:

Token Authentication: Use the username and password of an authorized user to obtain an authentication token. The token authorizes API calls within the normal scope of the user’s permissions. A token expires after 24 hours of inactivity.
API Key Authentication: The API Key authenticates a narrow set of API functions for managing Solr Basic Auth users and Zookeeper configurations in a deployment. The API Key does not expire, but it can be revoked.

The API can be accessed through any tool that assembles HTTP requests and dispatch them to a server. Among these would be the Python coreapi package, the Postman tool, and cURL. For Windows, use PowerShell 7+.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Token Authentication
- obtain-auth-token > create
- verify-auth-token
API Key Authentication

Token Authentication

The first step in using the SearchStax API is to obtain an authentication token by logging in to the SearchStax server. The token authorizes subsequent API requests.

obtain-auth-token > create

Generates an authentication token for the user of a tenant account. This token expires after 24 hours of inactivity

POST https://app.searchstax.com/api/rest/v2/obtain-auth-token/

The request body should be an “application/x-www-form-urlencoded” object to accommodate the non-alphanumeric characters that sometimes appear in usernames and passwords.

"username=&password="

Parameter	Description	Example
username required string	This is the email address used when you log into the SearchStax server.	“user@company.com”
password required string	This is the password associated with that username.	“4r36%74m”
tfa_token optional string	This is a six-digit code supplied by the Google Authenticator to enable two-factor authentication. Each code is good for one minute, so move fast. The eight-character backup codes work with no time limit, but only once each. If TFA is not enabled for this user account, this token is ignored.	“123456” or “noho2x5n”

When invoked from Linux (Bash script):

TOKEN=$(curl -s -H "Content-Type: application/json" -X POST \
       -d "{\"username\":\"$USER\",\"password\":\"$PASSWORD\",\"tfa_token\":\"$TWOFACTOR\"}" \
       https://app.searchstax.com/api/rest/v2/obtain-auth-token/)

If SearchStax will not accept your credentials from Bash, check your password for a $ or # character. Bash will try to interpret these characters, changing the text of the password.

When invoked from Windows (PowerShell script):

$USER = "username"
$PASSWORD = "password"
$TFA = "123456"

$body = @{
    username=$USER
    password=$PASSWORD
    tfa_token=$TFA
}

$body = $body | ConvertTo-Json

$TOKEN = Invoke-RestMethod -Method Post -Body $body -ContentType 'application/json' `
        -uri "https://app.searchstax.com/api/rest/v2/obtain-auth-token/" 
$TOKEN = $TOKEN.token

The response is a JSON document containing an authorization token.

{
  "token": "aa70cb0a180a0532ae8855f7a1712eeceb81e080"
}

Using the token in Bash

In the Bash scripts, the authorization token is incorporated directly in the header of the cURL call:

    curl -s -H "Authorization: Token $TOKEN" etc.

Using the token in PowerShell

In the PowerShell scripts, we use the token by assembling a header for the Invoke-RestMethod call. Note that $TOKEN.token extracts the actual token number from the Json response.


$TOKEN = $TOKEN.token

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Authorization", "Token $TOKEN")

$RESULTS = Invoke-RestMethod -Headers $headers etc.

verify-auth-token

Verifies if the auth token is valid, or needs to be re-generated

GET https://app.searchstax.com/api/rest/v2/verify-auth-token/

The Authorization header should be passed with the token to verify

Authorization "Token "

Parameter	Description	Example
token required string	The token to verify	“XyZ190189898njjhjhjhjhjhj”

When invoked from Linux (Bash script):

TOKEN=$(curl -s -H "Content-Type: application/json" -X GET  \
   -H 'authorization: Token YXBwNDAtYXBpOmdUSG8xNyNrdXU4' \
 https://app.searchstax.com/api/rest/v2/verify-auth-token/)

The response is a JSON with the expiry information of the token

{
    "token": {
        "key": "YXBwNDAtYXBpOmdUSG8xNyNrdXU4",
        "created": "2024-03-31T23:46:28Z",
        "expires": "2024-04-01T23:46:28Z"
    }
}

API Key Authentication

An API Key is a non-expiring authorization allowing certain non-SearchStax users to perform a specific set of API operations on specific deployments of a specific account. If you step outside of that scope, you will see an Out of Scope error.

In a little more detail:

You must be the Owner or an Admin of a Platinum or Platinum Plus account to generate an API Key.
You will need Token Authentication to create the API Key.
The API Key by itself is not good for anything. The account Owner or an Admin must associate the API Key with a specific deployment before the key becomes active.
At this point, anyone who possesses the API Key (anyone at all) can use SearchStax Provisioning API methods to:
- Manage Solr Basic Auth users on that specific deployment.
- Manage Solr configurations on Zookeeper in that specific deployment.

Note that the API Key is good for absolutely nothing else.

Procedure for creating an APIkey:

Obtain an authentication Token.
Generate an APIkey.
Associate the APIkey with a specific deployment.

Once the APIkey has been associated with a deployment, you can view the APIkey under the Security menu for that deployment in the Managed Search dashboard.

account > apikey > create

This method creates an API Key based on a valid authentication token.

POST https://app.searchstax.com/api/rest/v2/account//apikey/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "scope":["deployment.dedicateddeployment"]
}

Parameter	Description
scope required list of strings	The scope in which this API key will be effective. Default value is deployment.dedicateddeployment.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{
    \"scope\":[\"deployment.dedicateddeployment\"]
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$body = @{
    scope=@('deployment.dedicateddeployment')   # Force single-value to be a list
}
$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document:

{ "apikey": "eyJhbGciOiJIUzVCJ9.eyJpYXQiOjE1NDMyNDc0ODMsImp0aSI6IjhmYTlkZThjNTIyNjRjZTc2Njg0NTkyMWQ4MTQ0MDY5ZThkMjc5NmMiLCJzY29wZSI6WyJkZXBsb3ltZW50LmRlZGljYXRlZGRlcGxveW1lbnQiXSwiQ1MrdThSZmlNTzMwNnZJM082QSJ9.r6X7bJi_ZWGR99XC0Ac" }

Using the API key in Bash

In the Bash scripts, we use the API key directly in the header of the cURL call:

 curl -s -H "Authorization: APIkey $APIKEY" etc.

Using the API key in PowerShell

In the PowerShell scripts, we use the API key by assembling a header and using it in the Invoke-RestMethod call:

 $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Authorization", "APIkey $APIKEY")

$RESULTS = Invoke-RestMethod -Headers $headers etc.

account > apikey > associate_apikey_to_deployment

This method associates an API key to a specific deployment. Note that an API key can be associated with multiple deployments, but each deployment can be associated with only one API key at a time.

POST https://app.searchstax.com/api/rest/v2/account//apikey/associate/

where is the name of the tenant account.

This method requires Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "apikey": "eyJhbGciOiJI6IkpXVCJ9...",
    "deployment": "ss123456"
}

Parameter	Description	Example
apikey required string	This is the API key that needs to be associated with the deployment.	“eyJhbGciOiJI6IkpXVCJ9…”
deployment required string	This is the UID of the deployment.	“ss123456”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/associate/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{
    \"apikey\": \"eyJhbGciOiJI6IkpXVCJ9...\",
    \"deployment\": \"ss123456\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    apikey=$APIKEY
    deployment=$uid
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod  -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/associate/"

$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing a list of deployments associated with this key.

{
  "deployments": [ "ssXXXXX1", "ssXXXXX2"]
}

account > apikey > apikey_deployments

This method lists the deployments associated with the given API key.

POST https://app.searchstax.com/api/rest/v2/account//apikey/deployments/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "apikey" : "eyJhbGciOiJI6IkpXVCJ9..."
}

Parameter	Description	Example
apikey required string	This is the API key that is associated with the deployments.	“eyJhbGciOiJI6IkpXVCJ9…”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/deployments/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{ \"apikey\" : \"eyJhbGciOiJI6IkpXVCJ9...\" }"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$APIKEY = "eyJhbGciOiJI6IkpXVCJ9..."

$body = @{
    apikey=$APIKEY
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/deployments/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing a list of deployment UIDs.

{
  "deployments": [ "ss123456" ]
}

account > apikey > disassociate_apikey_from_deployment

This method disassociates an API key from a deployment.

POST https://app.searchstax.com/api/rest/v2/account//apikey/disassociate/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "apikey" : "eyJhbGciOiJI6IkpXVCJ9...",
    "deployment": "ss123456"
}

Parameter	Description	Example
apikey required string	This is the API key that needs to be disassociated from the deployment.	“eyJhbGciOiJI6IkpXVCJ9…”
deployment required string	This is the UID of the deployment.	“ss123456”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/disassociate/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{
    \"apikey\" : \"eyJhbGciOiJI6IkpXVCJ9...\",
    \"deployment\": \"ss123456\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$APIKEY = "eyJhbGciOiJI6IkpXVCJ9..."

$body = @{
    apikey=$APIKEY
    deployment=$uid
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/disassociate/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing a list of deployments with which the API key is still associated.

{
  "deployments": [
    "ssXXXXX1",
    "ssXXXXX2",
    "ssXXXXX3"
  ]
}

account > apikey > deployment_apikeys

This method lists the API key that is associated with a deployment. Each deployment may be associated with only one API key at a time.

POST https://app.searchstax.com/api/rest/v2/account//apikey/list/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "deployment" : "ss123456"
}

Parameter	Description	Example
deployment required string	This is the UID of the deployment.	“ss123456”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/list/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{ \"deployment\" : \"ss123456\" }"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    deployment=$uid
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/list/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing the API key associated with the deployment.

{
  "apikey": [ "eyJhbGciOiJI6IkpXVCJ9..." ]
}

account > apikey > revoke

This method revokes an API key.

POST https://app.searchstax.com/api/rest/v2/account//apikey/revoke/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "apikey" : "eyJhbGciOiJI6IkpXVCJ9..."
}

Parameter	Description	Example
apikey required string	This is the API key to revoke.	“eyJhbGciOiJI6IkpXVCJ9…”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//apikey/revoke/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{
    \"apikey\" : \"eyJhbGciOiJI6IkpXVCJ9...\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$APIKEY = "eyJhbGciOiJI6IkpXVCJ9..."

$body = @{
    apikey=$APIKEY
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/apikey/revoke/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing a success/failure message.

{
  "success": "API Key revoked successfully."
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Provisioning API – Authentication appeared first on SearchStax Docs.

SearchStax Users API

admin — Thu, 04 Mar 2021 10:23:05 +0000

Provisioning API – Users

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of SearchStax Managed Search service deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to manage the users of a SearchStax account through the API.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Users

Users

The SearchStax Provisioning API provides methods for managing the users of a SearchStax Account from a remote application.

users > list

This method lists the SearchStax users for an account.

GET https://app.searchstax.com/api/rest/users/?account=<account_name>

where ?account= is the name of the tenant account.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET https://app.searchstax.com/api/rest/users/?account=$ACCOUNT 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/users/?account=$ACCOUNT" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing the SearchStax users of the account and their details:

{
  "success": true,
  "users": [
    {
      "firstname": "FirstName",
      "lastname": "LastName",
      "email": "user@company.com",
      "role": "Team Member",
      "phone": "123-456-7890",
      "company": "Company",
      "id": 3201,
      "last_login": null,
      "created": "2021-01-06T19:51:28Z",
      "invitation_status": "Completed"
    }
  ]
}

users > add-user > create

This method invites a new user to join an existing tenant account.

POST https://app.searchstax.com/api/rest/users/add-user?account=<account_name>

where ?account= is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "email": "user@company.com",
    "role": "Admin",
    "first_name": "First",
    "last_name": "Last",    
    "phone_number": "8005551212"
}

Parameter	Description
email required string	The user’s email.
role required string	One of ‘Admin’, ‘Technical Contact’, ‘Billing Member’, ‘Team Member’.
first_name required string	User’s first name.
last_name required string	User’s last name.
phone_number optional string	User’s phone number.

When invoked from Linux (Bash script):

curl -s -H "Authorization: Token $TOKEN" -H "Content-Type: application/json" -d "${BODY}" 
-X POST https://app.searchstax.com/api/rest/users/add-user?account=$ACCOUNT

When invoked from Windows (PowerShell script):

$body = @{
    email='clayton@sti.net'
    role='Admin'
    first_name='Bruce'
    last_name='Clayton'    
    phone_number='8005551212'
}

$body = $body | ConvertTo-Json

$RESULTS = Invoke-RestMethod -Method Post -Body $body -ContentType 'application/json' -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/users/add-user?account=$ACCOUNT" 
$RESULTS = $RESULTS | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "success": true,
  "message": "User 'user@company.com' invited successfully."
}

users > change-password > create

This method allows an authenticated user to change his own password. It is not possible to change someone else’s password.

POST https://app.searchstax.com/api/rest/users/change-password?account=<account_name>&id=<id>

where ?account= is the name of the tenant account, and id= is the user identification number obtained from users > list.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following item:

{
    "password": "new-password"
}

Parameter	Description
password required string	The desired new password.

When invoked from Linux (Bash script):

curl -s -H "Authorization: Token $TOKEN" -H "Content-Type: application/json" -d "${BODY}" 
-X POST "https://app.searchstax.com/api/rest/users/change-password?account=$ACCOUNT&$ID"

When invoked from Windows (PowerShell script):

$body = @{
    password='password'
}

$body = $body | ConvertTo-Json

$RESULTS = Invoke-RestMethod -Method Post -Body $body -ContentType 'application/json' -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/users/change-password?account=$ACCOUNT&id=$ID" 
 
$RESULTS = $RESULTS | ConvertTo-Json

This method returns a JSON document containing a success message.

{
    "success":  true,
    "message":  "Password changed successfully."
}

If you received an error saying, “You can not change password for another user,” check to be sure the URL is within double-quotes. If not, everything to the right of the ampersand (&) will be truncated, usually resulting in the loss of the user ID.

users > set-role > create

Managed Search User Roles

For background on user roles in Managed Search, see Role-based User Roles for Your SearchStax Team and User Management.

This method allows an Author or Admin to change the role of one or more account users.

POST https://app.searchstax.com/api/rest/users/set-role/?account=<account_name>

where ?account= is the name of the tenant account..

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following item:

{
    "id": "2178,2067,3385",
    "role": "Team Member"
}

Parameter	Description
id required string	A comma-separated list of user ID numbers obtained from users > list.
role required string	One of Admin, Technical Contact, Billing Member, Team Member, Marketer. All users in the id list will be assigned to this role.

When invoked from Linux (Bash script):

curl -s -H "Authorization: Token $TOKEN" -H "Content-Type: application/json" -d "${BODY}" 
-X POST "https://app.searchstax.com/api/rest/users/set-role?account=$ACCOUNT"

When invoked from Windows (PowerShell script):

$body = @{
    id='2178,2067,3385'
    role='Team Member'
}

$body = $body | ConvertTo-Json

$RESULTS = Invoke-RestMethod -Method Post -Body $body -ContentType 'application/json' -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/users/set-role?account=$ACCOUNT" 
 
$RESULTS = $RESULTS | ConvertTo-Json

This method returns a JSON document containing a success/failure message for each user.

[
  {
    "id": 2178,
    "success": true,
    "message": "Role updated successfully."
  },
  {
    "id": 2067,
    "success": false,
    "message": "User id 2067 does not exist."
  },
  {
    "id": 3385,
    "success": true,
    "message": "Role updated successfully."
  }
]

users > delete

This method deletes a SearchStax user from an Account.

DELETE https://app.searchstax.com/api/rest/users/?account=<account_name>&id=<user_id>

where ?account= is the name of the tenant account, and &id= is the ID of the user.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl -H "Content-Type: application/json" -H "Authorization: Token $TOKEN" 
     -X DELETE "https://app.searchstax.com/api/rest/users/?account=$ACCOUNT&id=$DELUSER"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$DELUSER = "1234"

$RESULT = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/users/?account=$ACCOUNT&id=$DELUSER" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
   "id":3204,
   "success":true,
   "message":"User deleted successfully."
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post SearchStax Users API appeared first on SearchStax Docs.

Solr Basic Auth API

admin — Thu, 04 Mar 2021 10:10:05 +0000

Provisioning API – Basic Auth

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to manage Solr Basic Auth features through the API.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Solr Basic Auth

Solr Basic Auth

The SearchStax Provisioning API provides a selection of methods for managing Solr basic authentication from a remote application.

account > deployment > solr > auth > enable_basic_auth

This method enables basic auth for a Solr deployment.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/enable/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/enable/" \
  --header "Authorization: APIkey "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/enable/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "Basic authentication successfully Enabled for Solr",
  "success": "true"
}

account > deployment > solr > auth > disable_basic_auth

This method disables basic auth for a Solr deployment.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/disable/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/disable/" \
  --header "Authorization: APIkey " \

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/disable/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "Basic authentication successfully Disabled for Solr",
  "success": "true"
}

account > deployment > solr > auth > add_solr_user

This method adds a Solr user to the deployment. Basic auth must be enabled.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/add-user/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "username" : "demoSolrUser",
    "password" : "test123",
    "role" : "Admin"
}

Parameter	Description	Example
username required string	This is the Solr user name.	“demoSolrUser”
password required string	This is the Solr user’s password.	“test123”
role required string	This is the Solr role: Admin, Read, Write, or ReadWrite.	“Admin”

See Solr Basic Authentication for an explanation of the Solr roles.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/add-user/" \
  --header "Authorization: Token " \
  --header "Content-Type: application/json" \
  --data "{
    \"username\" : \"demoSolrUser\",
    \"password\" : \"test123\",
    \"role\" : \"Admin\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    username='demoSolrUser'
    password='test123'
    role='Admin'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/add-user/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "User successfully added",
  "success": "true"
}

account > deployment > solr > auth > delete_solr_user

This method deletes a Solr user from a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/delete-user/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "username" : "demoSolrUser"
}

Parameter	Description	Example
username required string	This is the Solr user name.	“demoSolrUser”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/delete-user/" \
  --header "Authorization: APIkey " \
  --header "Content-Type: application/json" \
  --data "{
    \"username\" : \"demoSolrUser\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    username='demoSolrUser'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/delete-user/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "User successfully deleted!",
  "success": "true"
}

account > deployment > solr > auth > get_solr_users

This method gets the Solr users for a deployment.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/get-users/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/get-users/" \
  --header "Authorization: APIkey "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/get-users/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing the Solr users and the roles associated with them.

{
  "success": "true",
  "users": {
    "demoSolrUser": {
      "roles": [ "Read", "Write", "Admin" ]
    }
  }
}

account > deployment > solr > auth > set_solr_user_password

This method sets a password for a Solr user.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/set-password/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "username" : "demoSolrUser",
    "password": "test456"
}

Parameter	Description	Example
username required string	This is the Solr user name.	“demoSolrUser”
password required string	This is the Solr user’s password.	“test456”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/set-password/" \
  --header "Authorization: APIkey " \
  --header "Content-Type: application/json" \
  --data "{
    \"username\" : \"demoSolrUser\",
    \"password\": \"test456\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    username='demoSolrUser'
    password='test456'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/set-password/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "Password successfully updated!",
  "success": "true"
}

account > deployment > solr > auth > set_solr_user_role

This method sets the Solr user’s role. Available roles are Admin, Read, Write, and ReadWrite.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/auth/set-role/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "username" : "demoSolrUser",
    "role" : "Read"
}

Parameter	Description	Example
username required string	This is the Solr user name.	“demoSolrUser”
role required string	This is the Solr role: Admin, Read, Write, or ReadWrite.	“Read”

See Solr Basic Authentication for an explanation of the Solr roles.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//solr/auth/set-role/" \
  --header "Authorization: APIkey " \
  --header "Content-Type: application/json" \
  --data "{
    \"username\" : \"demoSolrUser\",
    \"role\" : \"Read\"
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    username='demoSolrUser'
    role='Read'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/auth/set-role/" 
$RESULT = $RESULT | ConvertTo-Json

This method returns a JSON document containing a success message.

{
  "message": "Successfully updated user role!",
  "success": "true"
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr Basic Auth API appeared first on SearchStax Docs.

Solr IP Filtering API

admin — Thu, 04 Mar 2021 09:57:52 +0000

Provisioning API – IP Filtering

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to set up IP Filtering using the API methods.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

IP Filtering

IP Filtering

The SearchStax Provisioning API includes methods for applying IP Filters to deployments.

account > deployment > ip-filter > list

This method returns a list of IP Filters from a deployment.

GET /api/rest/v2/account/<account_name>/deployment/<uid>/ip-filter/?page=<n>

where is the name of the tenant account, and is the ID of the deployment. The query parameter page is a number, , that defaults to 1.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//ip-filter/?page=" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULTS = Invoke-RestMethod -Method Get -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/ip-filter/?page=1" 
$RESULTS = $RESULTS | ConvertTo-Json

The response is a JSON document containing a list of IP Filters.

[
  {
    "services": [
      "solr"
    ],
    "cidr_ip": "0.0.0.0/0",
    "description": ""
  }
]

account > deployment > ip-filter > add-cidr-ip

Setting IP Filters on Azure Deployments

When using add-cidr-ip in an Azure environment, IP filters for Zookeeper and Solr must both be explicitly set.

SearchStax requires Zookeeper to be locked down by IP filters. To then leave Solr open to any connection (a common request), set the Solr IP filter to ‘0.0.0.0/0’.

This method adds a new IP Filter to a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/ip-filter/add-cidr-ip/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    services=@('solr','zk')
    cidr_ip='100.100.100.100'
    description='Added by API'
}

Parameter	Description	Example
services required list of strings	Which services to apply the filter to. Allowed values are ‘solr’ and ‘zk’.	(‘solr’,’zk’)
cidr_ip required string	The IP address.	“100.100.100.100”
description optional string	A very brief label.	“Added by API”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//ip-filter/add-cidr-ip/" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data '{"services":["solr","zk"],"cidr_ip":"100.100.100.100","description":"Added by API"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    services=@('solr','zk')
    cidr_ip='100.100.100.100'
    description='Added by PowerShell'
}
$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/ip-filter/add-cidr-ip/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming success.

{
  "detail": null,
  "success": true
}

account > deployment > ip-filter > delete-cidr-ip

This method deletes an IP Filter from a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/ip-filter/delete-cidr-ip/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    cidr_ip='100.100.100.100'
}

Parameter	Description	Example
cidr_ip required string	The IP address of the filter to delete.	“100.100.100.100”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//ip-filter/delete-cidr-ip/" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data '{"cidr_ip":"100.100.100.100"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    cidr_ip='100.100.100.100'
}
$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/ip-filter/delete-cidr-ip/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming success.

{
  "detail": null,
  "success": true
}

account > deployment > ip-filter > update-cidr-ip

This method updates an IP Filter in a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/ip-filter/update-cidr-ip/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    services=@('solr','zk')
    cidr_ip='100.100.100.100'
    description='Updated by API'
}

Parameter	Description	Example
services required list of strings	Which services to apply the filter to. Allowed values are ‘solr’ and ‘zk’.	(‘solr’,’zk’)
cidr_ip required string	The IP address.	“100.100.100.100”
description optional string	A very brief label.	“Added by API”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//ip-filter/add-cidr-ip/" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data '{"services":["solr","zk"],"cidr_ip":"100.100.100.100","description":"Updated by API"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    services=@('solr','zk')
    cidr_ip='100.100.100.100'
    description='Updated by PowerShell'
}
$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/ip-filter/update-cidr-ip/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming success.

{
  "detail": null,
  "success": true
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr IP Filtering API appeared first on SearchStax Docs.

Solr Deployment API

admin — Thu, 04 Mar 2021 09:15:08 +0000

Provisioning API – Deployments

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to create and manage deployments using API methods.

The API can be accessed through any tool that assembles HTTP requests and dispatches them to a server. Among these would be the Python coreapi package, the Postman tool, and cURL. For Windows, use PowerShell 7+.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Deployment

account > deployment > create

This method lets you create a new deployment. Note that a successful response indicates only that deployment creation was authorized and has begun. It can take up to an hour to bring a new deployment on line depending on the cloud provider.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "name": "SolrFromAPI",
    "application": "Solr",
    "application_version": "7.3.1",
    "termination_lock": false,
    "plan_type": "DedicatedDeployment",
    "plan": "NDN1-AWS-S",
    "region_id": "ap-northeast-1",
    "cloud_provider_id": "aws",
    "num_additional_app_nodes": 0
    "private_vpc": 2
}

Parameter	Description	Example
name required string	The name of the new deployment	“SolrFromAPI”
application required string	The application for which this deployment is being created.	“Solr”
application_version required string	The version of application being deployed. Detailed information regarding application versions is available from the List Plans method.	“7.3.1”
termination_lock required boolean	Whether or not the deployment should be shielded from API deletion.	false
plan_type required string	Available plan type could be SharedDeployment or DedicatedDeployment. Currently SearchStax only supports DedicatedDeployment (the default).	“DedicatedDeployment”
plan required string	The plan of the selected plan type. Detailed information regarding plans available can be fetched using List Plans method.	“NDN1-AWS-S”
region_id required string	The region ID of the region where deployment has to be created. Detailed information regarding regions available can be fetched using List Plans method.	“ap-northeast-1”
cloud_provider_id required string	The cloud provider to be used to create this deployment. Detailed information regarding cloud providers available can be fetched using List Plans method.	“aws” “azure” “gcp”
num_additional_app_nodes optional number	The number of additional nodes to be added to the deployment beyond the default number of nodes. If the deployment will grow to a large number of nodes, create it with 10 “additional” nodes. This allocates a large IP subnet that can scale up gracefully. You may then use the SearchStax Dashboard to manage the actual number of nodes up or down as needed.	“10”
private_vpc optional number	The ID of the Private VPC where the new deployment will appear. Private VPC IDs are available from the account > privatevpc > list method.	“2”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment/" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data "{
    \"name\": \"SolrFromAPI\",
    \"application\": \"Solr\",
    \"application_version\": \"7.3.1\",
    \"termination_lock\": false,
    \"plan_type\": \"DedicatedDeployment\",
    \"plan\": \"NDN1-AWS-S\",
    \"region_id\": \"ap-northeast-1\",
    \"cloud_provider_id\": \"aws\",
    \"num_additional_app_nodes\": \"0\"
    \"private_vpc\": \"2\"
    }"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$body = @{
    name='SolrFromAPI'
    application='Solr'
    application_version='7.5.0'
    termination_lock='false'
    plan_type='DedicatedDeployment'
    plan='NDN1-AWS-S'
    region_id='us-west-1'
    cloud_provider_id='aws'
    num_additional_app_nodes='0'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -Body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing …

{
  "name": "SolrFromAPI",
  "uid": "ss123456",
  "application": "Solr",
  "application_version": "7.5.0",
  "tier": "Silver",
  "http_endpoint": null,
  "status": "Pending",
  "provision_state": "Pending",
  "termination_lock": false,
  "plan_type": "DedicatedDeployment",
  "plan": "NDN1-AWS-S",
  "is_master_slave": false,
  "vpc_type": "Public",
  "vpc_name": "",
  "region_id": "us-west-1",
  "cloud_provider": "Amazon Web Services"
  "cloud_provider_id": "aws",
  "num_additional_app_nodes": 0,
  "deployment_type": "Dedicated Node",
  "num_nodes_default": 1,
  "num_zookeeper_nodes_default": 0,
  "num_additional_zookeeper_nodes": 0,
  "servers": [],
  "zookeeper_ensemble": null,
  "tag": [],
  "specifications": {
    "jvm_heap_memory": "536870912",
    "disk_space": "8589934592",
    "physical_memory": "1073741824"
  },
  "backups_enabled": false,
  "dr_enabled": false,
  "sla_active": false,
  "state_changed": null,
  "term_end": null,
  "date_created": "2023-01-25",
  "application_nodes_count": 1,
  "selected_node_count": 0,
  "savings": {
    "one_year_saving_perc": "52.38",
    "three_year_saving_perc": "59.52"
  },
  "dr_plan_type": null,
  "subscription": "monthly",
  "security_pack": false,
  "desired_tier": "silver",
  "backup": null,
  "onboarding": false,
  "selected_plan_memory": 0.0,
  "selected_plan_storage": 0.0,
  "dr": null,
  "payment_method": null,
  "purchase_order": null
}

Note that the servers and the zookeeper_ensemble values are not initially available because those entities take time to create. Wait until the deployment is up and running, and then use the account > deployment > list method (below).

account > deployment > delete

This method deletes a deployment from the tenant account. Note that a successful response means only that the deletion process was authorized and has begun. It can take up to an hour to delete a deployment depending on the cloud provider.

DELETE https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request DELETE "https://app.searchstax.com/api/rest/v2/account//deployment//" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$RESULT = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/" 
$RESULT = $RESULT | ConvertTo-Json

A success response will identify the deleted deployment.

{
  "success": "true",
  "message": "Successfully deleted ss123456"
}

Invalid UID will throw a Not Found error.

{
  "detail": "Not found."
}

Subject to Termination Lock

The Termination Lock button on the Deployment Details page in the SearchStax Dashboard protects the deployment from API deletion until the lock is released.

If the Termination Lock is set, you’ll see a message like this one:

{
   "detail":"This deployment has Termination Lock enabled. Please first remove the termination lock, and then retry deleting the deployment."
}

account > deployment > list

This method lists the deployments of an account along with their deployment details.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/?page=<n>&page_size=<m>

where is the name of the tenant account; page (optional) is the page number of a multi-page list; and page_size (optional) is the number of deployments to include on a page.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$DEPLOYMENTS = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/" 
$DEPLOYMENTS = $DEPLOYMENTS | ConvertTo-Json

A successful response contains a JSON object containing a list of deployment descriptions. Note that next and previous are literal URLs that fetch the next and previous pages of a multi-page list of deployments.

{
  "count": 3,
  "next": null,
  "previous": null,
  "results": [
    {
      "name": "ListByAPI",
      "uid": "ss123456",
      "application": "Solr",
      "application_version": "8.11.2",
      "tier": "Silver",
      "http_endpoint": "https://ss123456-7hp6b4y0-us-west-1-aws.searchstax.com/solr/",
      "status": "Configuring Deployment",
      "provision_state": "Pending",
      "termination_lock": false,
      "plan_type": "DedicatedDeployment",
      "plan": "NDC128-AWS-G",
      "is_master_slave": false,
      "vpc_type": "Public",
      "vpc_name": "",
      "region_id": "us-west-1",
      "cloud_provider": "Amazon Web Services",
      "cloud_provider_id": "aws",
      "num_additional_app_nodes": 0,
      "deployment_type": "Dedicated Cluster",
      "num_nodes_default": 2,
      "num_zookeeper_nodes_default": 3,
      "num_additional_zookeeper_nodes": 0,
      "servers": "ss123456-5 ss123456-4 ss123456-3 ss123456-2 ss123456-1",
      "zookeeper_ensemble": "ss123456-7hp6b4y0-1-us-west-1-aws.searchstax.com:2181,ss123456-7hp6b4y0-2-us-west-1-aws.
rchstax.com:2181,ss123456-7hp6b4y0-3-us-west-1-aws.searchstax.com:2181",
      "tag": "",
      "specifications": "@{disk_space=; physical_memory=; jvm_heap_memory=}",
      "backups_enabled": false,
      "dr_enabled": false,
      "sla_active": false,
      "state_changed": null,
      "term_end": null,
      "date_created": "2023-01-25",
      "application_nodes_count": 2,
      "selected_node_count": 0,
      "savings": "@{one_year_saving_perc=0.00; three_year_saving_perc=15.00}",
      "dr_plan_type": null,
      "subscription": "yearly",
      "security_pack": false,
      "desired_tier": "silver",
      "backup": null,
      "onboarding": false,
      "selected_plan_memory": 0.0,
      "selected_plan_storage": 0.0,
      "dr": null,
      "payment_method": null,
      "purchase_order": null
    },

account > deployment > read

This method lists the properties of a specific deployment.

GET /api/rest/v2/account/<account_name>/deployment/<uid>/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$DETAILS = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/" 
$DETAILS1 = $DETAILS | ConvertTo-Json

The response is a JSON document containing the detailed properties of a deployment:

{
  "name": "ReadByAPI",
  "uid": "ss123456",
  "application": "Solr",
  "application_version": "7.7.2",
  "tier": "Silver",
  "http_endpoint": "https://ss123456-hjmll0ug-us-west-1-aws.searchstax.com/solr/",
  "status": "Running",
  "provision_state": "Done",
  "termination_lock": true,
  "plan_type": "DedicatedDeployment",
  "plan": "NDN1",
  "is_master_slave": false,
  "vpc_type": "Public",
  "vpc_name": "",
  "region_id": "us-west-1",
  "cloud_provider": "Amazon Web Services",
  "cloud_provider_id": "aws",
  "num_additional_app_nodes": 0,
  "deployment_type": "Dedicated Node",
  "num_nodes_default": 1,
  "num_zookeeper_nodes_default": 0,
  "num_additional_zookeeper_nodes": 0,
  "servers": [
    "ss123456-1"
  ],
  "zookeeper_ensemble": "ss123456-hjmll0ug-1-us-west-1-aws.searchstax.com:2181",
  "tag": [
    "DoNotDelete"
  ],
  "specifications": {
    "jvm_heap_memory": "536870912",
    "disk_space": "8589934592",
    "physical_memory": "1073741824"
  },
  "backups_enabled": false,
  "dr_enabled": false,
  "sla_active": false,
  "state_changed": "1571931445",
  "term_end": null,
  "date_created": "2019-10-24",
  "application_nodes_count": 1,
  "selected_node_count": 0,
  "savings": {
    "one_year_saving_perc": "52.50",
    "three_year_saving_perc": "64.38"
  },
  "dr_plan_type": null,
  "subscription": "monthly",
  "security_pack": false,
  "desired_tier": null,
  "backup": null,
  "onboarding": false,
  "selected_plan_memory": 0.0,
  "selected_plan_storage": 0.0,
  "dr": null,
  "payment_method": null,
  "purchase_order": null
}

Converting specifications to GB

In a PowerShell script, we can convert the reported specification values to GB using the following lines. Do not convert the output to JSON before making these calculations:


$GB = [math]::pow( 1024, 3 )  # To convert raw memory to rounded GB like the UI uses.

$DISK = $DETAILS.specifications.disk_space / $GB
$JVM = $DETAILS.specifications.jvm_heap_memory / $GB
$MEMORY = $DETAILS.specifications.physical_memory / $GB


Write-Host "Disk space is $DISK GB"
Write-Host "JVM heap memory is $JVM GB"
Write-Host "Physical memory is $MEMORY GB"

account > deployment > get_deployment_health

This method gets the deployment’s health using its UID.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/deployment-health/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//deployment-health/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/deployment-health/" 
$RESULT = $RESULT | ConvertTo-Json

Responses are JSON documents like those shown below. These examples are from a three-node cluster:

All nodes are running.

{ "status": "OK", "level": "success" }

One or two of the three servers is down.

{ "status": "Warn", "level": "warning" }

All three servers are down.

{ "status": "Error", "level": "danger" }

Invalid UID throws a Not Found error.

{ "detail": "Not found." }

account > deployment > collections_health

This method gets the health of a deployment’s collections.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/collection-health/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//collections-health/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/collections-health/" 
$RESULT = $RESULT | ConvertTo-Json

Responses are JSON documents like those shown below.

All collections are running.

{ "success": true, "healthy": true}

One or more collections are degraded.

{ "success": true, "healthy": false }

API endpoint failure.

{ "success": false, "error": "some message" }

account > deployment > rolling_restart

This method lets you restart the Solr or Zookeeper nodes of a cluster in a rolling manner.

PUT https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/rolling-restart/

where is the name of the tenant account and is the ID number of the deployment.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "solr": true,
    "zookeeper": false
}

Parameter	Description	Example
solr required boolean	If true, will restart the Solr nodes. Default is true.	true
zookeeper required boolean	If true, will restart the Zookeeper nodes. Default is false.	false

When invoked from Linux (Bash script):

curl --request PUT "https://app.searchstax.com/api/rest/v2/account//deployment//rolling-restart/" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data "{
    \"solr\": true,
    \"zookeeper\": false
    }"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    solr='true'
    zookeeper='false'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Put -Body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/rolling-restart/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing …

{
  "detail": "Rolling restart initiated"
}

If the message says, “The specified deployment is not ready for a rolling restart,” it means that a rolling restart is already underway, or that one of the nodes is down.

account > deployment > server > start_solr

This method starts an individual Solr node using its UID.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/server/<node>/start-solr/

where is the name of the tenant account, is the ID of the deployment, and is the ID of the specific node.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//server//start-solr/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$NODE = "ss123456-4"

$RESULT = Invoke-RestMethod -Method Post -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/server/$NODE/start-solr/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document similar to this:

{
  "success": true
}

account > deployment > server > stop_solr

This method stops an individual Solr node using its UID.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/server/<node>/stop-solr/

where is the name of the tenant account, is the ID of the deployment, and is the ID of the specific node.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//server//stop-solr/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$NODE = "ss123456-4"

$RESULT = Invoke-RestMethod -Method Post -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/server/$NODE/stop-solr/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document similar to this:

{
  "success": true
}

account > deployment > server > host_status

This method returns the status of an individual Solr node using its UID.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/server/<node>/host-status/

where is the name of the tenant account, is the ID of the deployment, and is the number of the specific node.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//server//host-status/" \
  --header "Authorization: Token

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$NODE = "4"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/server/$NODE/host-status/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document similar to this:

{
  "level": "success",
  "status": "OK"
}

account > deployment > server > list

This method returns a list of nodes making up a Solr deployment.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/server/

where is the name of the tenant account, and is the ID of the deployment.

This method uses either Token authentication or API Key authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//server/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/server/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document similar to this:

[
  {
    "sn": 1,
    "node": "ss123456-1",
    "private_address": "10.0.1.78",
    "dns_address": "ss123456-jkzg2pr0-1-ca-central-1-aws.searchstax.com",
    "status": "Running",
    "solr": false,
    "zookeeper": true,
    "silk": false
  },
  {
    "sn": 2,
    "node": "ss123456-2",
    "private_address": "10.0.1.74",
    "dns_address": "ss123456-jkzg2pr0-2-ca-central-1-aws.searchstax.com",
    "status": "Running",
    "solr": false,
    "zookeeper": true,
    "silk": false
  },
]

account > plan > list

This method lists the available deployment plans and the regions where those plans are available.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/plan/?page=1&application=Solr&plan_type=DedicatedPlan

where is the name of the tenant account. There are three query parameters: page is the page number within the paginated result set; application requests plans for either “Solr” or “elasticsearch”; and plan_type is “DedicatedPlan”. (The API currently supports only one plan type.)

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//plan/?page=1&application=Solr&plan_type=DedicatedPlan" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/plan/?page=1&application=Solr&plan_type=DedicatedPlan" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document with the following values –

Parameter	Description	Example
name string	The name of the plan	“NDN4-AWS-S”
description string	The description of the plan.	“Dedicated Node – 4GB/32GB”
application object	JSON object with details of application selected	{ “name”: “Solr”, “description”: “Apache Solr”, “tag”: “solr” }
application_versions list of strings	List of available application versions	[ “8.11.2”, “8.11.1”, “8.8.2”, “8.8.1”, “8.6.3”, and many more… ]
plan_type string	The plan type selected	“DedicatedPlan”
plan_regions list of objects	List of JSON objects containing information associated with each region.	{ “price”: 160, “additional_application_node_price”: 0, “additional_zookeeper_node_price”: 0, “region_id”: “ap-northeast-1”, “cloud_provider”: “Amazon Web Services”, “cloud_provider_id”: “aws” }
trial_available boolean	Whether the plan is available in trial account	false

account > usage > list

This method produces a list of the billable usage events of dedicated deployments in an account during a specific year and month.

GET /api/rest/v2/account/<account_name>/usage/<year>/<month>/

where is the name of the tenant account, is an integer (2023), and is an integer (1-12).

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//usage/// \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$YEAR = "2023"
$MONTH = "3"

$RESULTS = Invoke-RestMethod -Method Get -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/usage/$YEAR/$MONTH/" 
$RESULTS = $RESULTS | ConvertTo-Json

The response is a JSON document containing a list of usage events like this one:

  {
    "startDate": "2022-04-01",
    "endDate": "2022-04-30",
    "objectID": "ss123456",
    "SKU": "NDN4-AWS-S",
    "currency": "USD",
    "amount": "192.00",
    "usage": 30,
    "tagCollection": []
  },

Usage is the number of billable days between startDate and endDate, inclusively. In the case of backup storage, it is the number of bytes stored.

account > usage-extended > list

This method produces a list of billable usage events for serverless indexes of an account during a specific year and month.

GET /api/rest/v2/account/<account_name>/usage-extended/<year>/<month>/

where is the name of the tenant account, is an integer (2023), and is an integer (1-12).

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//usage-extended/// \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$YEAR = "2023"
$MONTH = "3"

$RESULTS = Invoke-RestMethod -Method Get -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/usage-extended/$YEAR/$MONTH/" 
$RESULTS = $RESULTS | ConvertTo-Json

The response is a JSON document containing a list of usage events like this one:

  {
    "startDate": "2023-12-01",
    "endDate": "2023-12-31",
    "objectID": "4008_QuickStart",
    "SKU": "SH-STARTER",
    "usage": 31,
    "tagCollection": [
      "Serverless_Index",
      "type:index"
    ],
    "currency": "USD",
    "amount": 9.15,
    "extendedAttributes": [
      "createdDate:2023-10-06",
      "totalRequests:0",
      "indexID:4008",
      "name:QuickStart",
      "region:us-west-2",
      "indexSize:0.002734375",
      "indexSizeWUnit:2.8 KB",
      "status:active",
      "orderStatus:completed",
      "subscription:yearly"
    ]
  }

Usage is the number of billable days between startDate and endDate, inclusively. In the case of backup storage, it is the number of bytes stored. The list of extendedAttributes describes a single serverless index (collection).

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr Deployment API appeared first on SearchStax Docs.

Private VPC API

Bruce — Fri, 24 Jun 2022 01:18:46 +0000

Private VPC API

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to obtain the ID number of a Virtual Private Cloud (VPC) using the API. This ID is essential to creating a new deployment inside the VPC using the account > deployment > create method.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Private VPC API
- account > privatevpc > list

Private VPC API

SearchStax provides the ability to create new Solr deployments within your VPC using the account > deployment > create method. That method, in turn, requires the ID number of the VPC in your account. The following method lets you obtain this ID number.

account > privatevpc > list

This method lists VPCs associated with an account.

GET /api/rest/v2/account/<account_name>/privatevpc/?page=1

where is the name of the tenant account, and is an optional page number within the paginated result set.

This method uses Token authentication.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//privatevpc" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$RESULT = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/privatevpc/"
$RESULT = $RESULT | ConvertTo-Json

A successful response is a JSON object describing the VPCs of the account:

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 2,
      "account": "test",
      "region": "us-east1",
      "status": "Active",
      "address_space": "10.63.0.0/16",
      "name": "test-vpc"
    }
  ]
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Private VPC API appeared first on SearchStax Docs.

Solr DNS Alias API

admin — Thu, 04 Mar 2021 08:55:55 +0000

Provisioning API – DNS Alias

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to redirect a DNS alias from one deployment to another using the API.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

DNS Alias

DNS Alias

SearchStax provides the ability to set up a DNS CNAME alias for your deployment. This means that your search application can query a domain address of the form myalias.searchstax.com in place of a literal Solr HTTP Endpoint like ss123456-hemxx0ug-us-west-1-aws.searchstax.com/solr/.

We also provide API methods that let you redirect this alias to a different deployment in the same account. This lets you switch search traffic from one deployment to another in an emergency. Note that multiple CNAME records can point to the same deployment.

Searchstax controls the master list of CNAME records to prevent name collisions. If your system would benefit from a CNAME alias, please contact sales@demo.searchstax.com.

account > dns-record > list

This method lists the existing CNAME aliases of an account.

GET /api/rest/v2/account/<account_name>/dns-record/

where is the name of the tenant account.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//dns-record/" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$ALIASES = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/dns-record/"
$ALIASES = $ALIASES | ConvertTo-Json

A successful response is a JSON object containing a list of CNAME records for this account:

{
  "count": 3,
  "next": null,
  "previous": null,
  "results": [
    {
      "associated": true,
      "name": "alias1",
      "value": "ss123456-dbw2acz6-us-west-1-aws.searchstax.com",
      "deployment": "ss123456",
      "ttl": 300
    },
    {
      "associated": true,
      "name": "alias2",
      "value": "ss123456-jdwz6lb2-us-west-1-aws.searchstax.com",
      "deployment": "ss123456",
      "ttl": 300
    },
    {
      "associated": true,
      "name": "alias3",
      "value": "ss123456-jdwz6lb2-us-west-1-aws.searchstax.com",
      "deployment": "ss123456",
      "ttl": 300
    }
  ]
}

account > dns-record > read

This method reads a single CNAME record.

GET /api/rest/v2/account/<account_name>/dns-record/<name>/

where is the name of the tenant account, and is the name of the alias.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//dns-record//" \
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$NAME = "alias1"

$ALIASES = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/dns-record/$NAME/"
$ALIAS = $ALIAS | ConvertTo-Json

A successful response is a JSON object containing a single CNAME record from this account:

{
  "associated": true,
  "name": "alias3",
  "value": "ss123456-jdwz6lb2-us-west-1-aws.searchstax.com",
  "deployment": "ss123456",
  "ttl": 300
}

account > dns-record > associate

This method updates a DNS CNAME record, associating the alias with a deployment’s Solr HTTP Endpoint. It can also set the DNS TTL (time to live) value for the record.

PATCH https://app.searchstax.com/api/rest/v2/account/<account_name>/dns-record/<name>/

where is the name of the tenant account, and is the name of the alias.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    deployment='ss123456'
    ttl='300'
}

Parameter	Description	Example
deployment required string	The deployment ID number from the Solr HTTP Endpoint.	“ss123456”
ttl required string	The DNS time-to-live value (seconds), which must be one of 60, 300, 900, 1800, 3600, 21600, 43200, or 86400.	“300”

When invoked from Linux (Bash script):

curl --request PATCH "https://app.searchstax.com/api/rest/v2/account//dns-record//" \
  --header "Content-Type: application/json" \
  --header "Authorization: Token " \
  --data '{"deployment":"ss123456","ttl":"300"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$NAME = "alias1"

$body = @{
    deployment='ss123456'
    ttl='300'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Patch -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/dns-record/$NAME/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing the updated CNAME record.

{
  "associated": true,
  "name": "alias3",
  "value": "ss123456-jdwz6lb2-us-west-1-aws.searchstax.com",
  "deployment": "ss123456",
  "ttl": 300
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr DNS Alias API appeared first on SearchStax Docs.

Solr Backup/Restore API

admin — Thu, 04 Mar 2021 07:56:22 +0000

Provisioning API – Backup/Restore

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr Cloud deployments.

Platinum and Platinum Plus Clients Only!

The SearchStax API suite is available to our Platinum and Platinum Plus clients only, as noted on our Pricing page.

This page describes how to perform backup and restore operations through API methods.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

Account-Level Methods
Deployment-Level Methods

Account-Level Methods

Backup files do not disappear when you delete the associated deployment. However, the deployment’s ssID (ss123456) becomes invalid, making it impossible to use the deployment-level methods to restore or delete the orphaned backup files.

The following three methods let us list, restore, and delete orphaned backup files from the API.

account > backup > list

This method lists the existing backups of an account, including any orphaned backup files.

GET /api/rest/v2/account/<account_name>/backup/

where is the name of the tenant account.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//backup/" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$BACKUPS = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/backup/"
$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response contains a JSON object containing a list of backups:

[
    {
      "id": 57198,
      "backup_type": "One time",
      "created": "2020-06-19 04:49:42 PM (2020-06-19 16:49:42 UTC)",
      "status": "Done",
      "size": 223608,
      "region": "US West (N. California)",
      "collections": null,
      "deployment_uid": "ss305854",
      "deployment_name": "QuickStart",
      "version": "8.3.1",
      "cloud": "aws",
      "size_display": "223.61 KB",
      "replication_region": "-",
      "error_message": []
    }
]

account > backup > delete

This method deletes a backup from a deployment.

DELETE /api/rest/v2/account/<account_name>/backup/<buid>/

where is the name of the tenant account, and is the ID of the backup.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request DELETE "https://app.searchstax.com/api/rest/v2/account//backup//" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$BUID = "27004"

$BACKUPS = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/backup/$BUID/"
$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response returns a 204 code and an empty string.

account > restore > create

This method restores an orphan backup file to a deployment. See also account > deployment > restore > create for more versatile restore options.

Parallel Restoration

Note that restoring a backup takes all collections offline until the restore is complete.

The parallel_restore parameter reduces restore time by rebuilding each collection in a separate thread.

Downtime due to a restore is difficult to estimate, ranging from minutes to hours for very large backup files. Experience must be your guide.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/restore/

where is the name of the tenant account.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    id="27004"
    target_deployment_id="ss123456"
    parallel_restore="true"
}

Parameter	Description	Example
id required string	The backup id number, from the List Backups method.	“27004”
target_deployment_uid optional string	The target deployment ID number.	“ss123456”
parallel_restore optional string	Optional ability to restore collections in parallel (multiple threads). Default is “false.”	“true”

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//restore/" 
  --header "Content-Type: application/json" 
  --header "Authorization: Token " 
  --data '{"id":"27004","target_deployment_uid":"ss123456"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"

$body = @{
    id='27004'
    target_deployment_uid='ss123456'
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/restore/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming that the restore has been scheduled.

{
  "message": "restore begun"
}

Deployment-Level Methods

The SearchStax Provisioning API includes methods for performing backup and restore operations. If the backup file has been “orphaned” by deleting the source deployment, use the account-level methods instead.

account > deployment > backup > list

This method lists the existing backups of a deployment.

GET /api/rest/v2/account/<account_name>/deployment/<uid>/backup/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//backup/" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$BACKUPS = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/"
$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response contains a JSON object containing a list of backups:

[
   {
     "id": 26919,
     "backup_type": "onetime",
     "created": "2019-11-14T17:22:22Z",
     "status": "done",
     "size": 210553,
     "region": "Amazon Web Services - us-west-1"
   }
]

account > deployment > backup > create

This method makes a one-time backup of a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/backup/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    region: "us-west-1",
    collections: "[filmcollection]"
}

Parameter	Description	Example
region optional string	The region ID of the region where the backup should be created. Defaults to the deployment’s region. Region codes can be obtained using the List Plans method or from the deployment’s description in the SearchStax dashboard.	“us-west-2”
collections optional list	List of collections to back up – [] to back up all collections	Bash: [“collection1”, “collection2”] PowerShell: @(‘collection1’, ‘collection2’)

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//backup/" 
  --header "Content-Type: application/json" 
  --header "Authorization: Token " 
  --data '{"region":"us-west-1","collection":"[filmcollection]"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    region='us-west-1'
    collections=@('filmcollection')
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document containing the description of the new backup.

{
  "id": 123456,
  "created": "2019-11-14T19:20:45.903037Z",
  "status": "pending",
  "size": 0,
  "region": "Amazon Web Services - us-west-1"
  "collections": [
     "filmcollection"
     ]
}

account > deployment > backup > delete

This method deletes a backup from a deployment.

DELETE /api/rest/v2/account/<account_name>/deployment/<uid>/backup/<buid>/

where is the name of the tenant account, is the ID of the deployment, and is the ID of the backup.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request DELETE "https://app.searchstax.com/api/rest/v2/account//deployment//backup//" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$BUID = "27004"

$BACKUPS = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/$BUID/"
$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response is a JSON document containing a confirmation message:

{
  "message": "Successfully deleted backup 27004",
  "success": "true"
}

account > deployment > backup > schedule > list

This method lists the existing backup schedules of a deployment.

GET /api/rest/v2/account/<account_name>/deployment/<uid>/backup/schedule/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//backup/schedule/" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$BACKUPS = Invoke-RestMethod -Method Get -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/schedule/"

$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response contains a JSON object containing a list of backups:

[
  {
    "id": 1234,
    "days": [
      "mon",
      "tue",
      "wed",
      "thu",
      "fri",
      "sat",
      "sun"
    ],
    "time": "00:00:00",
    "retention": 1,
    "collections": []
  }
]

account > deployment > backup > schedule > create

This method creates a backup schedule for a deployment.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/backup/schedule/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    "retention":  7,
    "days":  [
                 "mon",
                 "wed",
                 "fri"
             ],
    "region_id":  "us-west-1",
    "frequency":  6,
    "collections":  [
                        "filmcollection"
                    ],
    "time":  "07:00"
}

Parameter	Description	Example
time optional string	Time (UTC) the backup should run. (Format: HH:MM) Either time or frequency must be provided.	“07:00”
days required list	List of days on which backup should run.	[“mon”, “tue”, “wed”, “thu”, “fri”, “sat”, “sun”] [“everyday”]
retention required number	Number of days to retain the backup.	7
frequency optional number	At what interval (hours) the backups should run in the day. Either time or frequency must be provided.	3
region_id required string	The region ID of the region where the backup should be created. Defaults to the deployment’s region. Region codes can be obtained using the List Plans method or from the deployment’s description in the SearchStax dashboard.	“us-west-1”
collections optional list	List of collections to back up. Defaults to [] to back up all collections	Bash: [“collection1”, “collection2”] PowerShell: @(‘collection1’, ‘collection2’)

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//backup/schedule/" 
  --header "Content-Type: application/json" 
  --header "Authorization: Token " 
  --data '{"time":"08:30","collections":["filmcollection"],"days":["everyday"],"retention":"7","region_id":"us-west-1"}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$body = @{
    days=@('mon', 'wed', 'fri')
    time='07:00'
    frequency=6
    retention=7
    region_id='us-west-1'
    collections=@('filmcollection')
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/schedule/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming success.

{
  "message": "Backup Scheduled Successfully"
}

account > deployment > backup > schedule > delete

This method deletes a backup schedule from a deployment.

DELETE /api/rest/v2/account/<account_name>/deployment/<uid>/backup/schedule/<buid>/

where is the name of the tenant account, is the ID of the deployment, and is the ID of the backup.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request DELETE "https://app.searchstax.com/api/rest/v2/account//deployment//backup/schedule//" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$BUID = "27004"

$BACKUPS = Invoke-RestMethod -Method Delete -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/backup/schedule/$BUID/"
$BACKUPS = $BACKUPS | ConvertTo-Json

A successful response is a JSON document containing a confirmation message:

{
  "success": "The backup schedule has been deleted!"
}

account > deployment > restore > create

This method restores a backup to a deployment. Optionally, it can restore one or more individual collections from a multi-collection backup.

Restoring Individual Collections

This method can be used to restore one or more individual collections from a multi-collection backup to a multi-collection deployment. Note that restoring individual collections takes all collections offline until the restore is complete.

The parallel_restore parameter reduces restore time by rebuilding each collection in a separate thread.

Downtime due to a restore is difficult to estimate, ranging from minutes to hours for very large backup files. Experience must be your guide.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/restore/

where is the name of the tenant account, and is the ID of the deployment.

This method uses Token authentication.

The request body should be a “application/json” encoded object, containing the following items:

{
    backup_id="27004"
    replication_factor="3"
    collection_name="quickstart"
    collections=["Col1", "Col2", "Col3"]
    parallel_restore="true"
}

Parameter	Description	Example
backup_id required string	The backup id number, from the List Backups method.	“27004”
replication_factor optional string	Defaults to the number of nodes in the target cluster. You may ask for fewer replicas, but not for more.	“2”
collection_name optional string	[Deprecated.] Optional name of a single collection to restore.	“quickstart”
collections optional list	[Preferred.] Optional list of collection names to restore.	[“Col1”, “Col2”, “Col3”]
parallel_restore optional string	Optional ability to restore collections in parallel (multiple threads). Default is “false.”	“true”

If collection_name and collections are both present, the method will restore all of the listed collections.

If collection_name and collections are both absent, the method will restore all the collections in the backup file, overwriting all previous data on the deployment.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//restore/" 
  --header "Content-Type: application/json" 
  --header "Authorization: Token " 
  --data '{"backup_id":"12345678","collections":["collection1","collection3"]}'

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$list = @("collection1","collection3")

$body = @{
    backup_id='12345678'
    collections=$list
}

$body = $body | ConvertTo-Json

$RESULT = Invoke-RestMethod -Method Post -body $body -ContentType 'application/json' -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/restore/" 
$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming that the restore has been scheduled.

{
  "message": "The restore request has been successfully placed in the Task queue and will be initiated soon. You can check the status with the restore-status API"
}

When performing a partial restore, SearchStax will overwrite the restored collections while preserving any others that are present.

account > deployment > restore > status

This method reports on the status of a restore.

POST /api/rest/v2/account/<account_name>/deployment/<uid>/restore/status/

where is the name of the tenant account, is the ID of the deployment.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request POST "https://app.searchstax.com/api/rest/v2/account//deployment//restore/status/" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"

$RESULTS = Invoke-RestMethod -Method Post -ContentType 'application/json' -Headers $headers `
              -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/restore/status/"
$RESULTS = $RESULTS | ConvertTo-Json

The response is a JSON object containing an appropriate message string:

{
  "message": "Backup Restore in Progress"
}

{
  "message": "No restore Running on this deployment"
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr Backup/Restore API appeared first on SearchStax Docs.

Solr Custom JARs API

Bruce — Wed, 06 Jul 2022 12:50:29 +0000

Provisioning API – Custom JARs

Overview

The SearchStax Managed Search service provides an API supporting the creation, deletion and management of Solr Cloud deployments.

Premium Clients Only!

The Custom JAR API suite is available to our premium clients only, as noted on our Pricing page.

This page describes how to add and manage custom JAR files using API methods.

JAR size limit!

The API can handle JAR files up to 75 MB. If this is a problem, submit a support ticket.

Restart Solr Nodes!

After uploading a custom Jar, you must perform a Rolling Restart of the deployment. The API does not automatically restart the Solr nodes.

Account Owner, Admin, or Technical Contact

To run the SearchStax Provisioning API, you must be the account Owner, an account Admin, or a Technical Contact. See SearchStax User Roles.

Symbols enclosed in carets (< and >) such as are metavariables. Substitute your local values when you encounter them in the examples.

Contents:

JARs

account > deployment > solr > custom-jars > list

This method lists the JAR files of a deployment or server.

GET https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/custom-jars/?server_sn=<server_number>&page=<page_number>

where is the name of the tenant account, and is the ID of the deployment.

is the optional number of the Solr server within the deployment (usually 4 or 5). If unstated, the method addresses all Solr servers.

is the optional page of the results list. Default is 1.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request GET "https://app.searchstax.com/api/rest/v2/account//deployment//solr/custom-jars/?server_sn=&page=" 
  --header "Authorization: Token "

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$SID = "4"
$PAGE = "1"

$RESULT = Invoke-RestMethod -Method Get -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/custom-jars/?server_sn=$SID&page=$PAGE" 

$RESULT = $RESULT | ConvertTo-Json

The response is a list of JSON documents identifying the deployment and its current set of JAR files:

[
  {
    "server_sn": 4,
    "jars": []
  },
  {
    "server_sn": 5,
    "jars": [
      "jarfile.jar"
    ]
  }
]

account > deployment > solr > custom-jars > create

This method uploads a custom JAR file to a deployment or a server. The JAR will be replaced if it already exists.

POST https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/custom-jars/?server_sn=<server_number>

where is the name of the tenant account, is the ID of the deployment, and is the optional number of the Solr server within the deployment (usually 4 or 5). If unspecified, the method will address all Solr servers.

This method uses Token authentication.

The request body should be a “multipart/form-data” encoded object, containing the following items:

Parameter	Description	Example
file required string	Path to load JAR file.	“file=@jarfile.jar”

When invoked from Linux (Bash script):

curl -i -X POST -H "Authorization: Token " -H "Content-Type: multipart/form-data" -F "file=@jarfile.jar" https://staging.searchstax.com/api/rest/v2/account/staging/deployment/ss123456/solr/custom-jars/

When invoked from Windows (PowerShell script), use a version of PowerShell that supports multipart-form data, such as Powershell 7.0+. To determine what version of PowerShell you are running, evaluate $PSVersionTable.PSVersion.

$ACCOUNT = "AccountName"
$uid = "ss123456"
$SID = "4"

$form = @{
    file = Get-Item -Path '$JARFILE'
}

# Assuming the JAR file is in the same directory as this script. 

$RESULTS = Invoke-RestMethod -Method Post -Form $form -Headers $headers `
          -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/custom-jars/" 
$RESULTS = $RESULTS | ConvertTo-Json

Write-Host $RESULTS

The response is a list of JSON documents identifying the deployment and its current set of JAR files:

[
  {
    "server_sn": 4,
    "jars": [
      "jarfile.jar"
    ]
  },
  {
    "server_sn": 5,
    "jars": [
      "jarfile.jar"
    ]
  }
]

account > deployment > solr > custom-jars > delete

This method deletes a JAR from a deployment or a server.

DELETE https://app.searchstax.com/api/rest/v2/account/<account_name>/deployment/<uid>/solr/custom-jars/<jar-name>/?server_sn=<server_number>

where is the name of the tenant account, is the ID of the deployment, is the name of the JAR file, and is the optional number of the Solr server within the deployment (usually 4 or 5). If not specified, the method addresses all Solr servers.

This method uses Token authentication.

There is no request body.

When invoked from Linux (Bash script):

curl --request DELETE "https://app.searchstax.com/api/rest/v2/account//deployment//solr/custom-jars//?server_sn=" 
  --header "Authorization: Token " 
}"

When invoked from Windows (PowerShell script):

$ACCOUNT = "AccountName"
$uid = "ss123456"
$sid = "4"

$RESULT = Invoke-RestMethod -Method DELETE `
         -Headers $headers `
         -uri "https://app.searchstax.com/api/rest/v2/account/$ACCOUNT/deployment/$uid/solr/custom-jars//?server_sn=$sid" 

$RESULT = $RESULT | ConvertTo-Json

The response is a JSON document confirming the deletion:

{
  "success": "true"
}

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Solr Custom JARs API appeared first on SearchStax Docs.