Build Custom Web Service APIs for Moodle LMS

Walks through building a custom external web service API for Moodle LMS following Moodle's own three-method framework: execute_parameters() defines input types via external_value/external_single_structure/external_multiple_structure (with PARAM_INT/PARAM_TEXT/PARAM_RAW/PARAM_BOOL/PARAM_FLOAT types and VALUE_REQUIRED/VALUE_OPTIONAL/VALUE_DEFAULT flags), execute() holds the business logic and must call validate_parameters(), validate_context(), and require_capability() before touching data, and execute_returns() declares the exact return shape. It walks through registering the service in db/services.php (classname, methodname, type: read|write, ajax, required capabilities), covers error handling with try/catch and custom file-based debug logging that captures the last SQL and stack trace, and gives advanced patterns for delegated transactions ($DB->start_delegated_transaction()), programmatically creating course modules and quiz instances, group-based access restrictions via an availability JSON condition, and randomized question selection filtered by tag and category.

curl -X POST "https://yourmoodle.com/webservice/rest/server.php" \
  -d "wstoken=YOUR_TOKEN" \
  -d "wsfunction=local_yourplugin_your_api_name" \
  -d "moodlewsrestformat=json" \
  -d "userid=2" \
  -d "courseid=3"

Use it when creating custom Moodle web service endpoints - REST/AJAX APIs for course management, quiz operations, user tracking, reporting, or a mobile-app backend built on Moodle. It's Moodle-specific: classes must extend external_api, live under a namespaced local_pluginname\external or mod_modname\external path, and require externallib.php - this is not a generic REST-framework pattern transferable outside Moodle's plugin architecture. Five documented pitfalls each have a named fix: a "Function not found" error usually means stale caches (purge them) or a services.php/class-name mismatch; "Invalid parameter value detected" means a parameter-type or required/optional mismatch; SQL injection risk means raw string concatenation instead of Moodle's parameterized get_record()/get_records() methods; permission-denied errors mean a missing validate_context()/require_capability() call; and transaction deadlocks mean transactions held open too long or nested.

Inputs are the parameters declared in execute_parameters(), such as userid, courseid, or an optional nested options structure; output is the structure declared in execute_returns(), which must match exactly what execute() returns. The guide gives a full read-API example (get_quiz_attempts, returning a count via a parameterized SQL join across {quiz_attempts} and {quiz}) and points to a companion write-API example (create_quiz_from_categories.php) that performs multiple inserts, course-module creation, quiz configuration, tag-based random question selection, and group-based access restriction inside a transaction. Testing paths are the Moodle Web Services Test Client, a curl call against /webservice/rest/server.php with a token from /login/token.php, and a JavaScript core/ajax call for in-browser testing.

Built entirely on Moodle's own APIs: external_api/externallib.php for the service contract, the Moodle DML layer ($DB->get_records_sql, start_delegated_transaction) for data access, context_course/require_capability for permissions, and the db/services.php registration mechanism that exposes a function over REST, AJAX, or the official mobile app service. Reference tables cover the core Moodle schema most APIs touch: {user}, {course}, {course_modules}, {quiz}, {quiz_attempts}, {question}, {grade_items}, {groups}, and {logstore_standard_log}.

PHP developers building Moodle plugins that need to expose LMS functionality - course data, quizzes, grades, user tracking - to external applications or a mobile app backend, following Moodle's own coding standards and security model rather than inventing a parallel API layer.