Fuxam API v4
Industry-standard REST API for integrating with the Fuxam platform — authentication, pagination, errors, and endpoint reference.
The Fuxam API v4 is a versioned REST API that lets your institution connect student information systems, identity providers, reporting tools, and custom middleware to the same data your staff manage in Fuxam Web. Every endpoint shares one set of conventions for authentication, response shape, pagination, errors, and concurrency — so once you learn the patterns on this page, you can apply them across users, courses, curricula, and the rest of the resource catalog.
Base URL: https://fuxam.app/api/v4
Why institutions integrate
Universities rarely run on a single system. Admissions may live in one product, HR in another, and the learning platform in a third. The Fuxam API exists so those systems can exchange authoritative data without duplicate data entry:
- Provision and sync identities with the same users your administrators manage in User Management.
- Read and update academic structure — courses, modules, curricula, study programs, and terms — in line with FuxamCMS and FuxamLMS.
- Automate operational workflows such as room lookups, appointment data, and progress reads that would otherwise require manual export.
Integration is institution-scoped: credentials you create under Organization → API integrations authenticate as that institution’s integration, not as an individual staff user.
How this fits into Fuxam
The API is the programmatic surface of concepts you already know from Handbook Web. A user in the API is the same identity as in User Management; a course id addresses the same course staff open in Courses Management or the LMS.
| API resource area | Related Handbook Web topics |
|---|---|
| Users, roles, user groups | User Management, Roles and permissions, User groups |
| Courses, content blocks, progress | Courses Management, LMS courses, Content |
| Modules, curricula, study programs, terms | Academic structure, Study programs and cohorts |
| Rooms, appointments | Rooms, Calendar |
Key concepts
| Concept | Meaning |
|---|---|
| Integration | An API client registered under Organization → API integrations, with a clientId and clientSecret. |
| Response envelope | Successful responses wrap the payload in { data, meta } (single resource) or { data, pagination, meta } (lists). |
| Cursor pagination | Keyset paging with ?limit= and ?cursor= — never offset/page based. |
| Sparse fieldsets | Optional ?fields= to request only the properties you need. |
| Problem details | Errors use RFC 7807 application/problem+json with a stable machine-readable code. |
| Idempotency | Create (POST) requests can send Idempotency-Key to avoid duplicate resources on retry. |
| Optimistic concurrency | Single-resource writes use ETag / If-Match so concurrent updates do not silently overwrite each other. |
Conventions at a glance
- One response envelope everywhere:
{ data, meta }for a single resource,{ data, pagination, meta }for lists. - Cursor pagination:
?limit=&cursor=; responses carrypagination.next_cursor,pagination.has_more, andpagination.limit. No offsets. - RFC 7807 errors (
application/problem+json) with a stable, machine-readable top-levelcode. - Idempotent creates via the
Idempotency-Keyheader. - Sparse fieldsets via
?fields=id,email,…. - Optimistic concurrency on single-resource writes:
GETresponses include a strongETag; send it back asIf-MatchonPATCH,PUT, orDELETE.
Every response includes a meta object with requestId, timestamp, and version ("v4").
Typical request flow
Authentication
All requests use HTTP Basic Auth with your integration credentials (clientId:clientSecret, base64-encoded):
Authorization: Basic <base64(clientId:clientSecret)>
Create an integration under Organization → API integrations to obtain your clientId and clientSecret. API-key permission scopes are not implemented in v4 — Basic Auth is all-or-nothing for the integration.
For a full walkthrough of credential handling and security practice, see Authentication.
Response envelope
Single resource:
{
"data": { "id": "usr_123", "email": "user@example.com" },
"meta": {
"requestId": "req_1700000000000_abc123",
"timestamp": "2026-01-15T10:30:00.000Z",
"version": "v4"
}
}
List (with cursor pagination):
{
"data": [{ "id": "usr_123" }, { "id": "usr_456" }],
"pagination": {
"next_cursor": "eyJpZCI6MTIzfQ==",
"has_more": true,
"limit": 25
},
"meta": {
"requestId": "req_1700000000000_abc123",
"timestamp": "2026-01-15T10:30:00.000Z",
"version": "v4"
}
}
Use ?fields= to request a sparse fieldset on supported endpoints. Details and loop examples are in Pagination and filtering.
Cursor pagination
List endpoints accept ?limit= (1–100) and ?cursor= query parameters:
| Parameter | Description |
|---|---|
limit |
Page size (1–100; server default applies if omitted) |
cursor |
Opaque cursor from the previous page’s pagination.next_cursor |
Cursors are HMAC-signed and bound to your institution and integration. Tampered or foreign cursors return 400 with code invalid_cursor. Pagination uses keyset cursors over (sortField, id) — never offset-based paging.
When pagination.has_more is false, you have reached the last page.
Error model (RFC 7807)
All errors use application/problem+json with type as the URI https://fuxam.app/errors/{code}.
There are two distinct code namespaces:
- The top-level
codeis the closedApiErrorCodeunion — machine-readable and stable. - Each entry in
errors[].codeis a Zod issue code (e.g.invalid_string) with an RFC-6901pointer(e.g./email).
{
"type": "https://fuxam.app/errors/resource_not_found",
"title": "Not Found",
"status": 404,
"code": "resource_not_found"
}
v4 emits no 403. Cross-tenant access returns the same 404 resource_not_found as a truly missing resource — existence is never leaked. Validation failures return HTTP 422.
Common status codes: 200 read/update, 201 created, 204 deleted, 409 conflict or in-flight idempotency lock, 412 ETag mismatch, 428 missing required If-Match, 429 rate limit (honor Retry-After).
Deep coverage of error handling, idempotency, concurrency, and rate limits is in Errors and idempotency.
Idempotency
POST requests that create resources accept an Idempotency-Key header. Submitting the same key twice within the idempotency window returns the cached response (including the original 201) without creating a duplicate. Conflicting in-flight keys may return 409.
Idempotency-Key: a1b2c3d4-e5f6-7890-abcd-ef1234567890
Optimistic concurrency
Single-resource GETs emit a strong ETag. Send it back as If-Match on PATCH, PUT, or DELETE:
- 412
precondition_failed— the resource changed since you read it. - 428
precondition_required—If-Matchwas required but absent.
Rate limits
Each integration shares a 1000 requests/min budget (sliding window, keyed by integration + institution). Responses include RateLimit-* headers; 429 responses include Retry-After.
In this section
Start with the guides below, then use the resource cards for endpoint reference.
Getting started
Create an integration, authenticate, and make your first list request.
Authentication
Basic Auth, credentials, rotation, and security practice.
Pagination and filtering
Cursors, sparse fieldsets, and filter patterns.
Errors and idempotency
Problem details, retries, ETags, and rate limits.
Recipes
End-to-end patterns for sync, lookup, and safe writes.
Where to start
- Follow Getting started to create credentials and call
GET /users. - Read Authentication before storing secrets in production.
- Use Pagination and filtering when you need to walk large collections.
- Apply Errors and idempotency before any create or update automation.
- Copy a pattern from Recipes, then open the matching endpoint reference below.
Browse by resource
Endpoint reference pages are grouped by resource tag, organized into the sections below. These routes are generated from the OpenAPI specification.
Users
Users
User profiles, membership, lifecycle, contact details
Roles
Institution roles and user role grants
Courses
Courses
Courses (addressed by id; filter by code)
Content Blocks
Course content blocks
Workbenches
Course workbenches
User Progress
User progress across content blocks
Appointments
Appointments and room bookings
Academics
Course Modules
Course modules, versions, and groups
Curricula
Curricula, versions, and nested structure
Study Programs
Study programs, versions, cohorts
Organization Terms
Academic term chronology