REST API and App

Learnomy ships a full REST API that powers both the mobile/web app and third-party integrations. Everything students and instructors can do through the browser is also accessible through the API.

Overview

The REST API is built on top of the WordPress REST API framework. All Learnomy endpoints are registered under the namespace learnomy/v1, making them available at:

https://yoursite.com/wp-json/learnomy/v1/

The API is what the Learnomy mobile app and web app use to communicate with your site. If you are building an integration, a custom mobile app, or connecting Learnomy to another system, the REST API is the right layer to work with.

---

What the API Covers

The API provides endpoints for every major data type in Learnomy:

• Courses, sections, lessons, and topics
• Quizzes, questions, and quiz attempts
• Enrollments and student progress
• Certificates
• Reviews
• Memberships and subscriptions
• Coupons
• Earnings, commissions, and withdrawals
• Notifications and announcements
• Webhooks
• Admin operations (student management, settings, revenue reports)

Learnomy Pro adds its own endpoints under the learnomy-pro/v1 namespace for Pro-only features such as Cohorts, Learning Paths, Spaces, Assignments, and Membership Analytics.

---

What a learner can read about themselves

Two additions in 1.9.2 close the gap between what the website shows a student and what an app could retrieve:

• GET /account/quiz-attempts - the caller's own attempt history, paginated (per_page, offset), each row carrying its quiz and course title. This is the same list the website shows at /account/quiz-results/, read from the same source, so the two cannot drift. A row opens into the existing GET /attempts/{id} for the full review. The user is always taken from the session, never from the request.
• GET /courses/{id}/lessons now returns a quizzes[] array on every lesson, always present even when empty. Each quiz carries a viewer block (is_locked, lock_reason, unlocks_at, lock_message) resolved on the server, exactly like the lesson's own.

That last point matters for anyone building a client: do not evaluate lock rules yourself. Whether a lesson or its quiz is open can depend on drip mode, a per-student unlock, a section date, course-level sequencing, or the previous lesson's completion requirement, in any combination a site owner chooses - and a rule added in a later release would render as "open" in an app already on someone's phone. Ask the server and render its answer, including its lock_message, which is already translated into the site's language.

Two things that changed in 1.9.4

Bulk course actions take one request, not one per course. POST /courses/bulk accepts an action plus a list of ids, and the action may be either a verb (publish, archive, trash, restore, draft, delete) or a canonical status (published, archived, trashed, draft). Both forms are accepted so existing callers keep working; verbs are normalised server-side. restore deliberately returns a course to draft rather than republishing it, so bringing something back from the trash never silently makes it public again.

Some routes only exist when their integration is present. The H5P completion route and the WP Fusion rule routes register only when their companion plugin is active, and return 404 otherwise. They are marked CONDITIONAL ROUTE in the generated catalogue, with the condition stated in the description. If you build a client against the spec, treat those as optional rather than assuming a 404 means a broken install.

Authentication

The API accepts four kinds of credential. They are resolved in order and an already-authenticated session is never overridden (includes/api/class-api-key-auth.php:28-56).

Application Passwords (what the app uses)

The Learnomy companion app signs in with WordPress core Application Passwords, not with Learnomy's JWT. This is deliberate and is the same across the Wbcom portfolio: the app relies on a core credential a site owner can see and revoke from the user's profile screen. Nothing in Learnomy needs enabling for it.

API keys

Long-lived keys for server-to-server integrations ship today. Create one with POST /wp-json/learnomy/v1/auth/api-keys, list with GET, and revoke with DELETE /wp-json/learnomy/v1/auth/api-keys/{key_id}. Send the key in the X-API-Key header; a key in a query parameter is ignored. There is no wp-admin screen for keys - the API Keys settings section was removed in 1.5.0 and keys are managed over REST. See API Keys.

JWT (obtaining a token)

Send a POST request to /wp-json/learnomy/v1/auth/token with a valid WordPress username and password. The response returns an access token and a refresh token.

Pass the access token in the Authorization header on every authenticated request:

Authorization: Bearer <token>

Tokens expire and can be refreshed using the /auth/token/refresh endpoint.

---

Response Shape

Every API response uses a consistent envelope format:

• List responses: { "data": [...], "meta": { "total": N, "cursor_next": "..." } }
• Single resource: { "data": { ... } }
• Errors: { "error": { "code": "...", "message": "...", "details": [...], "request_id": "..." } }

This shape is the same whether you are calling a Free endpoint or a Pro endpoint.

---

Rate Limiting

Learnomy applies rate limiting to write endpoints flagged as sensitive (login, password reset, quiz start, coupon validation, and others). The default limit is 60 requests per minute per user. Administrators and instructors are exempt from the rate limit. You can adjust this in Learnomy Settings > API and Performance.

---

Where to Find More

This page is a conceptual overview. The full endpoint reference is part of the Developer Guide:

• Full endpoint reference: docs/api/openapi.json in the plugin repository - an OpenAPI 3 document generated from the live route table, covering both namespaces. At 1.9.4 it describes 396 paths (learnomy/v1 217, learnomy-pro/v1 179) across 510 operations. This is the reference to build a client against; it is the same document the mobile app generates from.
• Curated inventory with per-endpoint purpose notes: audit/manifest.json (222 entries). Free registers 226 register_rest_route call sites under includes/api/ - the three counts differ legitimately, because one call site can register several methods on one path, and the curated list is a documented subset rather than a total.
• CAPABILITIES.md is the buyer-facing source of truth for what those endpoints add up to.
• Code: REST controllers live in includes/api/ in the Free plugin and includes/extensions/*/rest/ in Learnomy Pro.

---

Tips

• The REST API is always available as long as the plugin is active. There is no separate toggle.
• All endpoints use permission_callback for access control. Anonymous requests to protected endpoints receive a 401 response. There are no unprotected write endpoints.
• ETag headers on read endpoints allow your HTTP client to use conditional requests and avoid re-downloading unchanged data.
• Application Passwords are the companion app's primary credential, not a fallback for JWT. Both work; pick per the table in Authentication above.

---

Developer hooks (1.2.0)

Learnomy 1.2.0 added two groups of extension points so integrations can ride the existing editors and the WordPress privacy pipeline without forking templates or touching lrn_* tables. Every hook below was confirmed in the plugin source.

Editor field seams

Courses, lessons, and quizzes are custom-table rows, not custom post types, so there is no meta-box path for third-party fields. These seams give integrations one render hook per editor plus one save action per entity. Render your inputs on the *_editor_fields action, then read $request and persist your own user meta or option storage on the matching *_saved action. Account fields work the same way across the registration forms and the account-details page.

This is what the WP Fusion bridge (Pro) and the built-in custom account fields feature build on. Learnomy's own Custom_Fields service is a first-party consumer of the account-field hooks, so admin-defined fields and developer-registered fields render through the same seam.

The render hooks pass the entity being edited (or null / 0 when the row does not exist yet). Field storage stays in the consumer plugin; Learnomy only exposes the surface. A minimal round-trip:

// Render an input in the course editor.
add_action( 'learnomy_course_editor_fields', function ( $course ) {
    $value = $course ? get_post_meta( (int) $course->id, 'crm_tag', true ) : '';
    printf( '<input name="crm_tag" value="%s">', esc_attr( $value ) );
} );

// Persist it when the course is saved.
add_action( 'learnomy_course_saved', function ( $course_id, $request ) {
    update_post_meta( $course_id, 'crm_tag', sanitize_text_field( (string) $request->get_param( 'crm_tag' ) ) );
}, 10, 2 );

Privacy and anonymisation

Three additive filters let an extension hide individual learner identity (name, email, avatar) from the instructor roster while keeping counts and metrics intact. Each filter receives an $is_admin flag (or the admin scope), so a consumer can keep manage_options users at full visibility and only mask for instructors. These were added so the BTC Instructor_Privacy integration survives plugin updates. None changes behaviour unless something hooks it.

The $is_admin argument is true when the caller has full visibility (no course scope), so consumers can short-circuit and never mask for administrators.

---

Related

• Outgoing Webhooks
• Incoming Payment Webhook Log
• Settings Overview