> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure AppViewX to authenticate to CryptoHub

> Store the CryptoHub credentials in the AppViewX vault and authenticate against the CryptoHub REST API to obtain a session token.

AppViewX authenticates to the CryptoHub REST API with the endpoint credentials from the deployed AppViewX service, and carries the returned token on every subsequent call.

## Store the CryptoHub credentials

Store the endpoint username and password in the AppViewX vault so the workflow reads them at run time rather than carrying them inline.

The CryptoHub login endpoint expects the password **Base64 encoded**. Store the encoded value.

```shell expandable lines wrap title="Shell" theme={null}
printf '%s' '<password>' | base64
```

<Warning>
  Base64 is an encoding, not encryption. The encoded password is as sensitive as the original. Keep it in the AppViewX vault and out of workflow definitions, exported configuration, and logs.
</Warning>

## Configure the authentication call

AppViewX authenticates against `/home/v1/login` with `authType` set to `userpass`.

```json expandable lines wrap title="Request" theme={null}
{
  "authCredentials": {
    "username": "<identity username>",
    "password": "<Base64-encoded password>"
  },
  "authType": "userpass"
}
```

The response carries the session token in `token` and its expiry in `tokenExpiration`.

<Check>
  The response is similar to the following:

  ```json expandable lines wrap title="Response" theme={null}
  {
    "token": "<JWT>",
    "tokenExpiration": "2026-07-29 12:34:56",
    "fullyLoggedIn": true
  }
  ```
</Check>

For the full request and response contract, including the other response fields, see [Login](/REST_API/Docs/Identity_and_access/Login).

<Note>
  If the identity belongs to a role that requires multiple identities, the session reports `fullyLoggedIn: false` until enough identities have authenticated. The endpoint identity used for unattended automation should be scoped so that a single login fully authenticates the session.
</Note>

## Carry the token on subsequent calls

Send the token in the `Authorization` header on each following request:

```shell expandable lines wrap title="Shell" theme={null}
Authorization: Bearer <JWT>
```

Configure AppViewX to read `tokenExpiration` and re-authenticate when the token expires, rather than assuming a fixed lifetime. For the token handling patterns CryptoHub supports, including the stateless and session-based flows, see [Using bearer tokens](/REST_API/Docs/Bearer_token_authentication/Using_bearer_tokens).

<Note>
  The token lifetime is set by CryptoHub, not by the client, and is deployment dependent. In testing against CryptoHub 7.0.3.x the token remained valid for roughly 24 hours, well beyond the fixed 10-minute interval some workflow templates assume. Always honor the `tokenExpiration` timestamp returned at login rather than a hardcoded lifetime.
</Note>

## Handle authentication failure

If authentication fails, the workflow must stop rather than continue to the key generation step. A failed login leaves no CryptoHub objects behind, so no cleanup is required.

Verify the following when a login fails:

* The password is Base64 encoded.
* The username matches the endpoint identity, not an administrator identity.
* The endpoint's partition is enabled.
* The CryptoHub address resolves and is reachable over HTTPS from the AppViewX host.

## Next steps

Generate the key pair and certificate signing request. See [Generate a key pair and CSR in CryptoHub](/Integrations/CryptoHub/Certificate_management/AppViewX/Integration_steps/Generate_a_key_pair_and_CSR_in_CryptoHub).