> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/getting-started/tutorial/deploying-verifier.md).

# Deploying the Verifier

**What We Are Doing:**

* Using your [One-Click deployment](https://oneclick.empe.io/) — which hosts both the Issuer and Verifier APIs — and registering a verifier identity in the operator console.
* The Verifier will be able to request credential presentations and check that they are valid once we create a verifier identity for it.

**Why:** The Verifier ensures that presented credentials are valid, come from a trusted Issuer, and meet the required criteria. It automates the cryptographic checks and exposes a simple HTTP API so your backend only has to create an authorization request and watch for the result.

**Steps:**

1. Log into the One-Click Deployment platform.
2. Register a verifier identity. The Verifier runs inside your One-Click deployment — a single deployment hosts both the Issuer and Verifier APIs. Register it *either* in the operator console (see [Create Verifier](/develop/intro/create_verifier.md)) *or* via the API calls under *Create a verifier identity* below — do one, not both.
3. Note the deployment's base URL — the Verifier API is served here. We keep it in its own variable because a Verifier can run under its own host in other setups, even though it currently shares the deployment with the Issuer:
   * `VERIFIER_BASE_URL` (e.g., `https://your-deployment.evdi.app`) — the base URL where the Verifier API is served.
4. **Save an admin access token** for the Verifier. Its API is protected by an admin **Bearer (JWT)** token that you send in the `Authorization` header to create authorization requests and verify presentations. Obtain it from the deployment's Keycloak using the credentials shown after creation — see [Authenticating to Your Deployment](/develop/intro/authenticating-to-your-deployment.md). Treat it like a password and keep it out of source control.

   > **Local development:** with `AUTH_DISABLED=true` you can omit the `Authorization` header — see [Authenticating to the API](/getting-started/tutorial/authentication.md).
5. Store these values in your `.env` file so your application can access them securely:

   ```
   VERIFIER_BASE_URL=https://your-deployment.evdi.app
   VERIFIER_ACCESS_TOKEN=your-oidc-access-token
   ```

   After storing these details in `.env`, they are easily accessible in your code using `process.env.VERIFIER_BASE_URL` and `process.env.VERIFIER_ACCESS_TOKEN`, and you can use them in your terminal to interact with the Verifier service (to load them you must run `source .env` first).

**Create a verifier identity:**

Before the service can issue authorization requests, it needs a **verifier** record. Creating one is a one-time setup step — if you already registered a Verifier on this deployment — in the operator console (Step 2) or in [Creating DIDs and Registering Issuer & Verifier](/getting-started/tutorial/creating-dids-and-issuer.md) — reuse that identifier as your `VERIFIER_ID` below and skip the two API calls. You can create a verifier without a DID and choose the signing DID later (per authorization request), but the simplest setup is to pass a decentralized identifier (DID) as the `verifierId` — the service then uses that DID by default to sign the authorization requests it sends to wallets.

First, create a DID for the verifier. The service can create a `did:key` (a self-contained key-based identifier) or a `did:web` (an identifier whose DID document the service hosts over HTTPS):

**`POST /agent/did/key`**

This request needs no body and returns the new DID:

```bash
curl -X POST "$VERIFIER_BASE_URL/agent/did/key" \
  -H "Authorization: Bearer $VERIFIER_ACCESS_TOKEN"
```

**Response Body**

```json
{
  "did": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "verificationMethodIds": ["did:key:z6Mk...#z6Mk..."]
}
```

Then register a verifier, passing that DID as the `verifierId`:

**`POST /agent/verifier`**

**Request Body**

```json
{
  "verifierId": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
}
```

* **verifierId** *(optional)* — an identifier for the verifier, which may be a DID. If you omit it, the service generates one for you. Pass the DID you just created so the service uses it by default to sign authorization requests (you can still override the signing DID per request).

```bash
curl -X POST "$VERIFIER_BASE_URL/agent/verifier" \
  -H "Authorization: Bearer $VERIFIER_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"verifierId":"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"}'
```

Keep the resulting verifier id — it is the `:verifierId` path segment you'll use when creating authorization requests in the next steps. Store it in your `.env` alongside the values from above:

```
VERIFIER_ID=did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
```

It is then available in your code as `process.env.VERIFIER_ID`.

Next, we'll configure a verification flow in our backend that uses this verifier to request and check credential presentations.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.empe.io/getting-started/tutorial/deploying-verifier.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.