> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/integrations-and-api/manage-app-and-custom-credentials.md).

# Manage app and custom credentials

Create and maintain the credentials used by app actions. Use an app credential for a connector's authentication flow and a custom credential for named values consumed by a supported action.

### Before you start

* Use an account permitted to create or manage the required credential.
* Know the target application, URL, and authentication method.
* Obtain the required provider permissions.
* Identify flows that depend on a credential before changing or removing it.

Open the app/credential management area. Depending on the product version, this area is shown as **Apps** or **Vault**.

### Create an app credential

Current form example: open Manage → Application Credentials, select New App Credential and choose WhatsApp. With Authentication Type set to User Access Token, the form shows Connector Name, User Access Token and Phone Number ID. Set as default credential, Test Connect and Connect & Create are separate controls. Use the selected application guide for the actual provider values; this field inspection did not enter a token, test a connection or create a credential.

<figure><img src="https://3857940684-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJcSHU5jP5GABQrGmWvW2%2Fuploads%2F9en5K4pCNGqKg8shn25K%2Fvault-app-credential.jpg?alt=media" alt="The WhatsApp app-credential form in Vault. Authentication fields are blank and Set as default credential is unchecked."><figcaption><p>The WhatsApp app-credential form in Vault. Authentication fields are blank and Set as default credential is unchecked.</p></figcaption></figure>

1. Select **New App Credential** and choose the application.
2. Give the connection a meaningful name that identifies its purpose and environment.
3. Select an authentication method supported by that application.
4. Complete the fields displayed for that method, including the URL where required.
5. Complete the provider authorization flow if OAuth is used.
6. Save the connection.
7. Select it in a controlled action and verify the returned result.

For OAuth, use the scopes and refresh behavior specified by the provider. A missing refresh token is not the universal explanation for every OAuth error.

### Maintain a connection

1. Expand the application's credential list and select the intended connection.
2. Use **Edit** to update the fields exposed by the form.
3. Review dependent actions and test the new connection with a limited operation.
4. If you set a default credential, check which actions use that default before saving.
5. Reopen a dependent action and confirm its selected credential.

Use **Disconnect** when you intend to remove the active connection. Use **Delete** only after checking its consumers; deleting a credential is not the same as rotating it.

### Create a custom credential

1. Open **Custom Credentials** and select **Add New Credential**.
2. Enter the credential name and description.
3. Add the variable name, description, and value.
4. Enable **Is Masked?** for confidential values.
5. Use **+** to add additional variables where required.
6. Save and select the credential through the consuming action's credential control.

<figure><img src="https://3857940684-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJcSHU5jP5GABQrGmWvW2%2Fuploads%2FOSn1dsDAqsFC6vai1AEi%2Fvault-custom-credential.jpg?alt=media" alt="Custom Credentials separates the credential name from its variable definitions. Use Is Masked? for confidential values; this inspection left the form unsaved."><figcaption><p>Custom Credentials separates the credential name from its variable definitions. Use Is Masked? for confidential values; this inspection left the form unsaved.</p></figcaption></figure>

Check the available access/request controls with the intended user. Do not assume that a credential is shared merely because another person can open the same Hyperflow.

### Expected result

The intended action can use the saved credential to perform its permitted operation. Other actions and users retain the access intended for them.

### Troubleshoot

* Credential absent: check the application, current user, and access/request status.
* Provider authorization fails: inspect the returned error, registered callback, tenant/account, and requested permissions.
* Connection stops working: check token expiry or revocation and repeat the provider's authorization flow where appropriate.
* Wrong account used: inspect the action's explicit credential selection and any default.
* Secret shown in a log: stop sharing that output and follow your credential-rotation procedure.

Masking a field in the editor does not by itself define every downstream action's logging behavior.

### Related reference

* [Apps, connections, and authentication](/userguide/integrations-and-api/apps-connections-and-authentication.md)

### Worked example: verify a Xurrent read connection

Use a test Xurrent account and a record you are authorized to inspect. The goal is to prove that the selected connection reaches the intended account and retrieves the intended record, without changing it.

1\. In App Credentials, choose the installed Xurrent application. Name the connection Xurrent — test — request lookup and complete the fields for the authentication method your account supports. Store the actual authentication values only in the credential form.

2\. In a test Hyperflow, add the installed Xurrent Get Any Object with ID action. Read its current input contract. The documented action requires object and object\_id; select the request object offered by the action and enter your known test record’s actual ID.

3\. Select the new credential explicitly. Assign the action response to a result variable, then run the read once.

4\. Compare the returned record ID and an identifying field with the record in Xurrent. Also confirm the target account or environment. A successful connection to the wrong account is not a passed test.

5\. Repeat with a known nonexistent ID. Record the actual empty-result or error shape so the flow can distinguish no match from an authentication failure.

6\. If another permitted operator will use the flow, verify the intended access path using that account. Do not assume that visibility of the flow grants access to every credential.

Keep the credential label, target environment, action version, test record ID and observed result in the setup record. Do not include tokens, client secrets or secret-bearing URLs. If an existing production credential is used elsewhere, create an isolated test credential rather than changing its default or disconnecting it for this exercise.
