---
title: "Check whether the human has entered the secret"
method: GET
path: "/api/v1/credentials/requests/{credential_request}"
tags: ["Credentials"]
---

# Check whether the human has entered the secret

`GET /api/v1/credentials/requests/{credential_request}`

## Request

- Base URL: `https://wardenpoint.com` (the document declares no server; this is the origin it was published from)
- URL: `https://wardenpoint.com/api/v1/credentials/requests/{credential_request}`
- Auth: API key in header `X-API-Key`

Poll after showing the link. Returns pending, verified or failed and nothing about the secret — not its value, not its length, not a mask.

Stop polling on verified, and on failed with reason `expired`. Keep polling on failed with reason `verification_failed`: the provider rejected one attempt, the link is still alive, and the person can paste again — the status will flip to verified if they get it right.

Reading the status changes nothing, including when the link has already expired.

## Path parameters

- `credential_request` string, uuid, required

## Response `200`

Current state of the request.

- object
  - `data` CredentialRequest: One request for a human to type a provider secret. Never carries the secret itself, in any direction.
    - `uuid` string, uuid: Stable identifier of the request.
    - `provider` string: The provider this request is bound to. A request is good for one provider only.
    - `status` 'pending' | 'verified' | 'failed': pending — nobody has typed anything yet. verified — the secret was accepted by the provider and stored; the link is spent. failed — see failure_reason.
    - `failure_reason` 'verification_failed' | 'expired' | 'superseded', nullable: Only set when status is failed. `verification_failed` — the provider rejected what was typed; this is NOT terminal, the same link keeps working until expires_at and the status can still become verified. `expired` — terminal, ask for a new link. `superseded` — terminal and NOT an error: the secret for this provider was already entered through another link of the same company (asking for a link twice, which a retry does, produces exactly this), so the one you are polling was closed and the credential you wanted is in place. Check the other request, or the channel itself, before asking for a new link.
    - `verification` 'provider_check' | 'stored_only': What `verified` means for this provider. `provider_check` — the value was accepted by the provider itself, so the channel works. `stored_only` — the values were stored but nothing proved them here, because this provider cannot be checked by typing alone; today that is only `telegram`, where the proof is the QR sign-in (POST /api/v1/credentials/telegram/qr). Do not report an account as configured on a `stored_only` verified.
    - `url` string, uri: The page to show the human. Opening it requires being signed in to this account, so a leaked link is useless on its own.
    - `status_url` string, uri: Poll this for the status. Polling has no side effects and never returns the secret.
    - `expires_at` string, date-time: After this moment the link stops working and the status reads failed/expired.
    - `created_at` string, date-time
    - `completed_at` string, date-time, nullable: When the secret was accepted. Null until then.

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks the config.write ability.
- `404`: No request with this UUID, it belongs to another company, or secret-entry links are switched off for this installation.

---

[API](https://skmtc.dev/wardenpoint/apis/wardenpoint-api.md) · [All operations](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/llms.txt) · [OpenAPI document](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/revisions/259ee445728e?raw)