Build on the API the fkra apps run on.
The studio, the player, and the admin area read and write through one REST API. Your service calls the same endpoints for organizations, paths, modules, and progress.
If the apps can do it, the API can too
Docs/Developers/Introduction
The fkra API
One REST API behind every fkra surface. Same objects, same permissions, same audit trail, whether the call comes from the studio, the player, or your own service.
NoteEach snippet shows a request and the response it returns. Non-production deployments serve the full OpenAPI reference at /docs.
Quickstart
#Three calls, from sign-in to content. Sign in, read the current user, then list the learning paths.
Send the email and password, get back an access token and a refresh token. The call also needs a solved CAPTCHA token. Accounts with two-factor on get a challenge instead of tokens.
1curl -X POST "https://<your-api-host>/api/v1/public/user/login/credential" \2 -H "Content-Type: application/json" \3 -H "x-api-key: $FKRA_KEY:$FKRA_SECRET" \4 -H "x-captcha-token: $CAPTCHA_TOKEN" \5 -d '{ "email": "amina@acme.edu", "password": "…", "from": "website" }'
Authentication
#Signed-in calls carry two credentials. The API key identifies your app and goes on every request; the access token identifies the user and goes on every route behind sign-in.
curl "https://<your-api-host>/api/v1/shared/user/session/list" \ -H "x-api-key: $FKRA_KEY:$FKRA_SECRET" \ -H "Authorization: Bearer $ACCESS_TOKEN"
CarefulThe secret is shown once, when an admin creates the key. Keep it on your server, and reset the key from /admin/system/api-keys.
Define your own module types
#An admin registers a module type with two JSON schemas, one for its settings and one for its content. The studio builds its editing forms from them.
{ "key": "practice.branching_scenario", "learnerAction": "Decide", "configSchema": { "properties": { "branches": { "type": "array", "minItems": 2 }, "endings": { "type": "array", "minItems": 2 }, "scoring": { "enum": ["rubric", "points"] } } }, "bodySchema": { "properties": { "persona": { "type": "string" } } }}
Organizations, roles, and permissions
#Each organization is its own tenant on its own subdomain. Protected routes check the user's role, then a permission written as a subject and an action, and both are read fresh on every request.
Arabic and English, built in.
#Every surface ships in Arabic and English with right-to-left layout: content, dashboards, certificates.
Send x-custom-lang: ar and the message comes back in Arabic, with metadata.language set to match. Learner content routes read Accept-Language and report which locale they served, with a flag when they fell back to another.
Endpoints
#Eight endpoints to start with, from sign-in to certificate checks. The fkra apps call the same ones. Open one to see what it needs and what it returns.
{ "isTwoFactorEnable": false, "tokens": { "tokenType": "Bearer", "expiresIn": 3600, … } }Responses and paging
#Every response carries a numeric status code, a message in the caller's language, request metadata, and the data. Paginated lists add their paging state to the metadata.
"metadata": { "language": "en", "path": "/api/v1/shared/user/session/list", "version": "1", "type": "cursor", "perPage": 20, "hasNext": true, "hasPrevious": false, "nextCursor": "eyJ…", "orderBy": [{ "createdAt": "desc" }], "availableOrderBy": ["createdAt", "updatedAt"]}
Errors and limits
#Errors use the same envelope. The HTTP status names the kind of failure, and statusCode in the body is fkra's own code for the exact cause. Validation failures add an errors array with one entry per field.
HTTP/1.1 422 Unprocessable Entity { "statusCode": 5030, "message": "There are validation errors.", "metadata": { "language": "en", "version": "1", … }, "errors": [ { "key": "isNotEmpty", "property": "password", "message": "password cannot be empty." } ]}
Limits100 requests every 10 seconds, counted per client address, not per key. Past that the API answers 429 with a Retry-After header in seconds. Certificate checks have their own limit of 60 a minute.
An audit trail
#Sign-ins, content edits, role and API key changes, and issued certificates are logged with the user, the action, the IP address, and the device. Failed attempts are logged too, and admins can export role events as CSV.
The rest of the platform
#Every workspace gets all of it.
Build on fkra
#Admins create and reset keys in the admin area, under System, API keys. Your service sends the key with every request.
Start using fkra Rolling out for your company?The same platform as private SaaS, white-label, or on-premise.
See the deployment modelsStraight to the founders, with no sales sequence and no qualification form. hello@fkra.ai