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

# API Overview

> Fortro Engine REST API overview

# API Overview

Fortro Engine is the Rust/Axum backend used by Sphyre ALV, Sphyre Issuers, and Sphyre Verifier. All application routes are mounted under `/api`.

```text theme={null}
Production: https://api.sphyre.tech
Local:      http://localhost:8080
```

## Authentication

Most application calls use a JWT issued by the DID challenge flow:

```http theme={null}
Authorization: Bearer <jwt>
X-User-DID: did:alyra:...
```

Issuer and verifier dashboards also pass their active DID in the path, for example `POST /api/issuer/:did/schemas` or `GET /api/verifier/:did/presentations`.

## Route Groups

| Group             | Mounted path             | Purpose                                                                                    |
| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------ |
| Auth              | `/api/auth`              | Register users, login, DID challenge verification, profile, wallet auth                    |
| Wallet            | `/api/wallet`            | Holder credentials, consents, wallet activity, credential requests, presentation approvals |
| Issuer            | `/api/issuer`            | Issuer profiles, schemas, templates, credential issuance, offers, request approval         |
| Verifier          | `/api/verifier`          | Verifier profiles, presentation requests, presentations, presets, consent checks           |
| Domain            | `/api/domain`            | Issuer/verifier domain challenge and verification status                                   |
| DID               | `/api/did/:did`          | Resolve DID documents                                                                      |
| QR                | `/api/qr`                | Short URL resolution and QR payload creation                                               |
| Blockchain        | `/api/blockchain`        | Current smart-contract helpers for credentials, schemas, and consents                      |
| Blockchain legacy | `/api/blockchain-legacy` | Legacy blockchain endpoints retained for compatibility                                     |
| Admin             | `/api/admin`             | Administrative DID and key migration helpers                                               |
| Health            | `/api/health`            | Service health check                                                                       |

## Main Endpoints

```text theme={null}
POST /api/auth/register
POST /api/auth/login
POST /api/auth/challenge
POST /api/auth/verify-challenge
POST /api/auth/generate-did
GET  /api/auth/me
GET  /api/auth/profile
PUT  /api/auth/profile
POST /api/auth/wallet/encrypted-seed
POST /api/auth/wallet/encrypted-seed/get

GET  /api/wallet/:did/credentials
POST /api/wallet/:did/credentials/import
POST /api/wallet/:did/credentials/share
GET  /api/wallet/:did/consents
POST /api/wallet/:did/consents
POST /api/wallet/:did/consents/:consent_id/revoke
POST /api/wallet/credential-request
GET  /api/wallet/:did/credential-requests
POST /api/wallet/presentation-requests
POST /api/wallet/presentation-requests/:request_id/approve
POST /api/wallet/presentation-requests/:request_id/reject

POST /api/issuer
GET  /api/issuer/:did
POST /api/issuer/:did/schemas
GET  /api/issuer/:did/schemas
POST /api/issuer/:did/templates
GET  /api/issuer/:did/templates
POST /api/issuer/:did/issue
GET  /api/issuer/:did/credentials
POST /api/issuer/:did/credentials/:credential_id/revoke
POST /api/issuer/:did/offers
GET  /api/issuer/:did/statistics

POST /api/verifier
POST /api/verifier/requests
GET  /api/verifier/requests/:id
POST /api/verifier/presentations
GET  /api/verifier/:did/presentations
GET  /api/verifier/presentations/:id
POST /api/verifier/presentations/:id/verify
POST /api/verifier/presentations/:id/resend
GET  /api/verifier/verify/ipfs/:ipfs_hash
GET  /api/verifier/:did/presets
POST /api/verifier/:did/presets

GET  /api/qr/resolve/:short_id
POST /api/qr/credential-offer
POST /api/qr/presentation-request

POST /api/blockchain/credential/register
POST /api/blockchain/credential/revoke
GET  /api/blockchain/credential/check/:did/:credential_hash
POST /api/blockchain/schema/register
POST /api/blockchain/consent/grant
POST /api/blockchain/consent/revoke
GET  /api/blockchain/consent/check/:user_did/:verifier_did/:purpose
GET  /api/blockchain/status
```

## Response Shape

Successful handlers commonly return:

```json theme={null}
{
  "success": true,
  "message": "Operation completed",
  "data": {}
}
```

Errors are produced by the shared `AppError` type and returned with the appropriate HTTP status code. Treat `message` as the stable user-facing field and avoid depending on exact internal text.