API Integration
API setup and making requests to the Andamio Gateway
API Reference: API Docs for endpoint schemas.
Authentication Headers
Most Andamio API requests require two authentication headers. Public endpoints (developer registration, billing plans, health checks) have reduced or no auth requirements.
| Header | Purpose | How to get |
|---|---|---|
X-API-Key | Application-level (your app) | Getting Started |
Authorization: Bearer <jwt> | User-level (wallet signature) | Authentication |
const headers = {
"Content-Type": "application/json",
"X-API-Key": APP_API_KEY,
"Authorization": `Bearer ${userJwt}`,
};Making Requests
Once authenticated, include both headers in all requests:
// Example: List user's courses
const res = await fetch(`${API}/course/owner/courses/list`, {
method: "GET",
headers,
});
const courses = await res.json();API Endpoints
The Andamio Gateway provides approximately 120 endpoints across these categories:
| Category | Base Path | Description | Guide |
|---|---|---|---|
| User Auth | /api/v2/auth/login/* | Wallet challenge/verify, User JWT | Authentication |
| Developer account and API keys | None: the developer portal | Registration, email verification, key management | Developer Accounts |
| Billing | /api/v2/billing/* | Plans, checkout, subscription management | Billing |
| Courses | /api/v2/course/* | Course CRUD, modules, enrollments, merged views | |
| Projects | /api/v2/project/* | Project CRUD, tasks, contributors, merged views | |
| Transactions | /api/v2/tx/* | Build, register, status, SSE stream (17 build endpoints) | Transactions |
| Users | /api/v2/users/* | User state, owned/enrolled/completed resources | |
| Token Registry | /api/v2/token/* | Native asset registration and listing | |
| Dashboard | /api/v2/user/dashboard | Consolidated user view (courses + projects) |
For the complete endpoint reference with request/response schemas, see the API Docs.
For transaction building and submission, see Transaction Handling.
Environment URLs
Start on preprod — it uses test ADA.
| Environment | Gateway URL | App URL | Network |
|---|---|---|---|
| Preprod (start here) | preprod.api.andamio.io | preprod.app.andamio.io | Cardano Preprod |
| Production | api.andamio.io | app.andamio.io | Cardano Mainnet |
All code examples in these docs use preprod URLs.
Ready for Mainnet?
When your app is tested and ready for production:
- Generate a mainnet API key at app.andamio.io/api-setup — the same portal that manages your preprod keys
- Update your environment variables:
NEXT_PUBLIC_ANDAMIO_GATEWAY_URL="https://api.andamio.io" NEXT_PUBLIC_CARDANO_NETWORK="mainnet" - Update the Access Token policy ID (contact team for mainnet ID)
See Environment Reference for full configuration details.
Error Responses
The Andamio API uses two error shapes depending on the endpoint. Both are in active use.
Legacy shape
Used by auth, transaction, billing, and most existing endpoints:
{
"status_code": 401,
"message": "Unauthorized: Invalid or missing credentials.",
"details": "optional debug info"
}| Field | Required | Description |
|---|---|---|
status_code | Yes | HTTP status code repeated in the body |
message | Yes | Human-readable error message |
details | No | Optional debug information |
Error envelope shape
Used by merged data endpoints (/v2/course/*/merged, /v2/project/*/merged, module, lesson, SLT endpoints):
{
"error": {
"code": "NOT_FOUND",
"message": "Assignment not found",
"details": "optional debug info"
}
}| Field | Required | Description |
|---|---|---|
error.code | Yes | Semantic error code string |
error.message | Yes | Human-readable error message |
error.details | No | Optional debug information |
HTTP status to error code mapping
| HTTP | Semantic code |
|---|---|
| 400 | BAD_REQUEST |
| 401 | UNAUTHORIZED |
| 403 | FORBIDDEN |
| 404 | NOT_FOUND |
| 409 | CONFLICT |
| 422 | UNPROCESSABLE_ENTITY |
| 429 | TOO_MANY_REQUESTS |
| 500 | INTERNAL_SERVER_ERROR |
| 502 | BAD_GATEWAY |
| 503 | SERVICE_UNAVAILABLE |
A 429 from your tier's rate limits or request quota does not use this envelope. See Quota Headers.
See Error Handling for recovery patterns.
Quota Headers
This section covers the Andamio API, called with a developer key. Each request that counts against your developer quota returns what is left in its response headers:
| Header | Description |
|---|---|
X-Quota-Remaining-Monthly | Requests left this month, after this one |
X-Quota-Reset-Monthly | When the monthly quota resets, as an RFC 3339 timestamp (the start of next month, UTC) |
X-Quota-Remaining-Daily | Requests left today, after this one |
X-Quota-Reset-Daily | When the daily quota resets, as an RFC 3339 timestamp |
No header reports the per-second or per-minute limits.
When you exceed a limit, the API returns 429 Too Many Requests. A 429 carries none of these headers, and its body is { "error": "<message>" } rather than the error envelope. The message names the limit you hit: per second, per minute, daily or monthly. After a per-second or per-minute 429, back off and retry within the minute. After a daily or monthly 429, wait until the reset time from your last successful response.
Andamio Issuer keeps its own quota and returns 402 QUOTA_EXHAUSTED when it runs out. See Andamio Issuer API integration.
Your billing tier sets the limits. See Billing for the limits per plan.
Issuer Route Auth
Some endpoints under /api/v2/auth/issuer/* operate with stricter auth requirements than standard v2 routes. These routes reject requests that supply both X-API-Key and Authorization — sending both returns 400 Bad Request. Supply only the credential the endpoint requires.
For all other /api/v2/* routes, both headers are accepted together (the standard pattern above).
Next Steps
- API Concepts — Source field, safe refetch timing, event queries
- Transaction Handling — Build, sign, and submit transactions
- Error Handling — Recovery patterns and failure modes
- API Docs — Full endpoint reference