Getting started

Create a Fuxam API v4 integration, build Basic Auth, call GET /users, read the response envelope, and paginate your first list.

This guide walks you from zero to a working authenticated request against the Fuxam API v4. By the end you will have created an integration, built an Authorization header, called GET /users, interpreted the { data, meta } envelope, and fetched a second page with a cursor.

Base URL: https://fuxam.app/api/v4

Why it matters

A first successful call proves three things at once: your credentials work, your network path to fuxam.app is open, and your client correctly parses the shared response shape. Getting those foundations right early prevents hours of debugging when you later add writes, retries, and multi-page sync jobs.

Before you start

You need:

• Access to your institution’s Fuxam Web organization settings so you can create an API integration.
• A terminal with curl (or any HTTP client that can send Basic Auth).
• A secure place to store the clientSecret — treat it like a password.

Related reading: Authentication for credential security, Overview for the full convention summary, and User Management for how users appear in the product UI.

How to create an integration

How to build the Authorization header

HTTP Basic Auth encodes clientId:clientSecret as Base64 and sends it in the Authorization header:

Authorization: Basic <base64(clientId:clientSecret)>

Generate the value with your shell (replace the placeholders):

CLIENT_ID="your_client_id"
CLIENT_SECRET="your_client_secret"
AUTH=$(printf '%s:%s' "$CLIENT_ID" "$CLIENT_SECRET" | base64 | tr -d '\n')
echo "Authorization: Basic $AUTH"

How to make your first request

List users with GET /users. This is a safe read-only call and a good smoke test.

curl -sS \
  -u "${CLIENT_ID}:${CLIENT_SECRET}" \
  -H "Accept: application/json" \
  "https://fuxam.app/api/v4/users?limit=25"

Equivalent raw HTTP:

GET /api/v4/users?limit=25 HTTP/1.1
Host: fuxam.app
Authorization: Basic <base64(clientId:clientSecret)>
Accept: application/json

A successful response looks like:

{
  "data": [
    { "id": "usr_123", "email": "user@example.com" },
    { "id": "usr_456", "email": "another@example.com" }
  ],
  "pagination": {
    "next_cursor": "eyJpZCI6MTIzfQ==",
    "has_more": true,
    "limit": 25
  },
  "meta": {
    "requestId": "req_1700000000000_abc123",
    "timestamp": "2026-01-15T10:30:00.000Z",
    "version": "v4"
  }
}

Reading the envelope

Keep meta.requestId when you open a support ticket — it is the fastest way to locate the request.

How to paginate

If pagination.has_more is true, request the next page with the opaque next_cursor value:

curl -sS \
  -u "${CLIENT_ID}:${CLIENT_SECRET}" \
  -H "Accept: application/json" \
  "https://fuxam.app/api/v4/users?limit=25&cursor=${NEXT_CURSOR}"

GET /api/v4/users?limit=25&cursor=eyJpZCI6MTIzfQ== HTTP/1.1
Host: fuxam.app
Authorization: Basic <base64(clientId:clientSecret)>
Accept: application/json

Stop when has_more is false. Do not invent or edit cursors — they are HMAC-signed and bound to your institution and integration. A bad cursor returns 400 with code invalid_cursor.

Full details (including a complete walk-all-pages loop) are in Pagination and filtering.

Checklist after your first call

Best practices for first integrations

• Start with list reads (GET /users, GET /courses) before any create or update.
• Log meta.requestId on every response in your integration client.
• Use a modest limit (for example 25) while developing; raise toward 100 only when syncing at scale.
• Store credentials in a secrets manager, not in source control. See Authentication.
• When you are ready to write, follow Errors and idempotency and the patterns in Recipes.

Common pitfalls

FAQ

Related pages