Moodle API Function Index

The Moodle API function index is a generated, grep-oriented reference that catalogues every Moodle Web Services function available on the integration target. It is used by the /moodle-api-agent slash command inside api.faculytics and by engineers who need to locate the right wsfunction when wiring a new Moodle call.

The index is a flat list of ~760 rows — one per Moodle Web Services function. Each row records:

Rows are pipe-delimited:

wsfunction | description | page | params | return_shape | ajax

The index is regenerated when the upstream Moodle Web Services documentation changes (typically once per Moodle major-version bump). It is not authored by hand — edits to individual rows would be overwritten on the next regeneration.

The index is shaped for grep-style lookups because it must answer "which Moodle function do I call for X?" quickly, without parsing a 1500-page PDF.

grep "core_message" api.faculytics/docs/moodle/moodle_api_index.md
grep "core_enrol" api.faculytics/docs/moodle/moodle_api_index.md
grep "core_course" api.faculytics/docs/moodle/moodle_api_index.md

grep -i "send.*message" api.faculytics/docs/moodle/moodle_api_index.md
grep -i "completion" api.faculytics/docs/moodle/moodle_api_index.md
grep -i "enrol.*user" api.faculytics/docs/moodle/moodle_api_index.md

The /moodle-api-agent slash command in api.faculytics wraps these greps behind a natural-language interface — ask it "which wsfunction creates a category?" and it searches the index for you.

A handful of representative entries, formatted for readability:

core_course_create_categories | Create course categories | 412 | categories[](name,parent,idnumber,description,descriptionformat,theme) | [{id,name,idnumber,description,descriptionformat,parent,sortorder,coursecount,visible,visibleold,timemodified,depth,path,theme}] | yes

core_course_create_courses | Create new courses | 419 | courses[](fullname,shortname,categoryid,idnumber,summary,...) | [{id,shortname}] | yes

core_enrol_get_enrolled_users | Get enrolled users by course id | 665 | courseid(int), options[](name,value) | [{id,username,firstname,lastname,email,...,groups[]}] | yes

core_user_create_users | Create users | 1188 | users[](username,password,createpassword,firstname,lastname,email,auth,...) | [{id,username}] | yes

core_webservice_get_site_info | Return some site info / user info / list of available functions | 1321 | serviceshortnames[] | {sitename,username,firstname,lastname,fullname,lang,userid,siteurl,userpictureurl,functions[],downloadfiles,uploadfiles,release,version,mobilecssurl,advancedfeatures,usercanmanageownfiles,userquota,usermaxuploadfilesize,userhomepage,userprivateaccesskey,siteid,sitecalendartype,usercalendartype,userissiteadmin,theme,limitconcurrentlogins} | yes

These five rows illustrate the patterns you'll see across the full index: list-endpoint get_* functions return arrays of objects, write-endpoint create_* functions return minimal identifiers, and the service-discovery core_webservice_get_site_info is the go-to probe for "what can I actually call on this Moodle instance?".

All Moodle calls inside api.faculytics go through MoodleClient (see Core Components for the connectivity and error-handling pattern). When adding a new call:

1. Grep the index to confirm the wsfunction name and parameter shape.
2. Add a typed wrapper to the relevant service (MoodleService, MoodleProvisioningService, etc.).
3. On a fresh Moodle instance, the function must be added to the external service whitelist — MoodleClient surfaces a dedicated error hint for webservice_access_exception that explicitly names the Site Admin path to fix this.