Aho API

Version v1

Verifiable Credentials API for issuance, verification, and management.

Documentation

New to verifiable credentials? These resources will help:

Glossary — Key terms: DID, VC, VP, holder, issuer, verifier, and more
Credential Formats — Comparison of JWT-VC, SD-JWT-VC, and mdoc formats
Developer Guides — Step-by-step integration tutorials
Verifiable Credentials API Guide — Issue and verify credentials
Revocation API Guide — Revoke and suspend credentials

Base URL

All API requests are made to the api subdomain:

https://api.aho.com

For example, /v1/issuer/credentials becomes https://api.aho.com/v1/issuer/credentials.

Authentication

Different API paths require different authentication methods:

Path Prefix	Authentication	Description
`/v1/issuer/*`	Issuer API Key (`X-API-Key` header)	Credential issuance, schemas, data sources, automations
`/v1/verifier/*`	Verifier API Key (`X-API-Key` header)	Presentation requests, verification
`/v1/account/*`	Account API Key (`X-API-Key` header)	Domains, signing keys, webhooks, API key management
`/v1/holder/*`	Bearer Token (`Authorization` header)	Holder wallet operations
`/v1/hooks/*`	Token in URL path	External webhook triggers (no API key needed)
`/v1/health`	None (public)	Health check endpoint
`/v1/schemas`	None (public)	Public schema registry

API Keys: Obtain from your dashboard under Settings > API Key. Include as X-API-Key header.

Webhook Tokens: Generated per-automation via POST /v1/issuer/automations/{id}/webhook.
The token is embedded in the trigger URL for simple external system integration.

Rate Limits

All API endpoints are rate limited to prevent abuse. Limits are applied per API key.

Category	Limit	Applies To
General	60 requests/minute	All API endpoints
Batch Operations	30 requests/minute	Bulk credential issuance, batch revocation
Sensitive Operations	5 requests/minute	Domain creation, signing key creation, API key operations
Automation Triggers	10 requests/minute	Automation trigger endpoints
Data Source Tests	5 requests/minute	Data source connection tests

When rate limited, the API returns HTTP 429 with a Retry-After header indicating seconds to wait.

API Base URL

All API requests are made to the https://api.aho.com subdomain.

For example, /v1/issuer/credentials becomes https://api.aho.com/v1/issuer/credentials

Quick Start

Authentication

Most API endpoints require an API key passed in the X-API-Key header.

curl -X GET 'https://api.aho.com/v1/account/api_keys' \
  -H 'X-API-Key: your_api_key_here'

API Sections

Credential Schemas

**Credential Schemas** define the structure and validation rules for your verifiable credentials. A schema specifies: - The credential type (e.g., "EmployeeBadgeCredential") - The claims/fields the credential contains (name, title, department, etc.) - Validation rules for each field (required, format, allowed values) - Supported credential formats (JWT-VC, SD-JWT-VC, mdoc) **Workflow:** Create a schema first, then use it when issuing credentials or setting up automations. New schemas start in "draft" status and must be activated before use.

7 endpoints

Data Sources

**Data Sources** connect to external systems that contain subject data for automated credential issuance. Supported source types: - **PostgreSQL**: Connect to a database to query employee/student/member records - **CSV**: Upload files for batch processing Data sources store encrypted connection credentials and can be tested before activation. Use data sources with Data Source Mappings and Automations to issue credentials automatically.

6 endpoints

Data Source Mappings

**Data Source Mappings** define how data from a source translates into credential claims. A mapping connects: - A **Data Source** (where to get the data) - A **Credential Schema** (what credential to issue) - **Field Mappings** (which source columns map to which credential claims) - **Query Configuration** (how to extract records from the source) Example: Map the "full_name" database column to the "name" credential claim.

5 endpoints

Automations

**Automations** run credential issuance workflows automatically based on triggers. Trigger modes: - **Manual**: Triggered via API call or dashboard button - **Scheduled**: Runs on a cron schedule (e.g., daily at midnight) - **Webhook**: Triggered by external systems via webhook URL Each automation uses a Data Source Mapping to know what data to fetch and what credentials to issue. Automations can be paused, resumed, and monitored for run history.

11 endpoints

Credential Issuances

**Credentials** are the verifiable credentials you issue to holders. Operations: - Issue new credentials (directly or via credential offers) - List and search issued credentials - Revoke or suspend credentials - Check credential status Credentials are cryptographically signed using your signing keys and can be verified by anyone.

11 endpoints

Credential Offers

**Credential Offers** let holders claim credentials through a wallet app using OpenID4VCI protocol. Flow: 1. Create an offer with the credential data 2. Share the offer URL or QR code with the holder 3. Holder scans/clicks and their wallet fetches the credential Offers can be one-time use or reusable, with optional PIN protection.

4 endpoints

Credential Verification

**Verification** validates credentials and checks their authenticity. Verification checks: - Cryptographic signature validity - Expiration status - Revocation/suspension status - Issuer trust signals (domain verification, organization info) Use this to verify credentials presented to you before trusting their claims.

2 endpoints

Presentation Requests

**Presentation Requests** ask holders to present specific credentials using OpenID4VP protocol. Define what credentials you need: - Required credential types - Required claims within those credentials - Optional constraints (issuer, expiration, etc.) Requests generate a URL/QR code that holders scan to share matching credentials from their wallet.

8 endpoints

Presentation Responses

**Presentation Responses** contain the credentials holders submit in response to your requests. After a holder responds to a presentation request, retrieve and verify the submitted credentials here. Responses include the raw credential data and verification status.

2 endpoints

DC API Sessions

**DC API Sessions** enable server-to-server verification using the Digital Credentials API. The thin client architecture keeps credential handling server-side: 1. Create a session to get encryption keys and request configs 2. Your frontend uses the Digital Credentials API to request credentials 3. POST the encrypted response back to verify and extract claims Benefits: - No credential data exposed to frontend JavaScript - Cryptographic binding via session transcript - Works with Chrome/Android (OpenID4VP) and Safari/iOS (mdoc) Sessions expire after 5 minutes and are single-use.

4 endpoints

Credentials

**Holder Credentials** are credentials owned by an end user (holder). Operations: - List credentials in the holder's wallet - View credential details and claims - Delete credentials from the wallet Holders receive credentials through credential offers or direct issuance.

2 endpoints

Presentations

**Presentations** are packaged credentials that holders share with verifiers. Create verifiable presentations to respond to verification requests, proving you hold certain credentials without revealing unnecessary information.

5 endpoints

Domains

**Custom Domains** establish your organization's identity for credential issuance. Your domain becomes part of your DID (Decentralized Identifier): `did:web:yourdomain.com` Domain verification: 1. Add your domain 2. Create the required DNS TXT record 3. Verify ownership A verified domain increases trust in your issued credentials.

5 endpoints

Signing Keys

**Signing Keys** are the cryptographic keys used to sign your verifiable credentials. Key features: - Keys are generated and stored securely (never exposed) - Support for key rotation with overlap periods - Multiple algorithms supported (ES256, EdDSA) Each credential is signed with your active key, allowing verifiers to confirm authenticity.

6 endpoints

API Keys

**API Keys** authenticate your API requests. Each account has two types of keys: - **Secret Key**: For server-to-server API calls. Never expose in client-side code. - **Publishable Key**: For browser-based requests. Restricted by origin allowlist. Keys auto-create on first access and can be regenerated if compromised (old value stops working immediately).

4 endpoints

Webhooks

**Webhooks** notify your systems when events occur in your account. Supported events: - Credential issued, revoked, suspended - Presentation request completed - Domain verification status changes Configure a webhook URL to receive real-time event notifications with cryptographic signatures for verification.

6 endpoints

Hooks

**Webhook Triggers** allow external systems to trigger actions without API key authentication. Currently supports: - **Automation triggers**: External systems POST to trigger credential automation runs Each trigger uses a unique token URL. Tokens can be regenerated if compromised.

0 endpoints