Search jobs with the filters POST /api/jobs/search documents: status IDs, estimated start date range, the mobile users they are allocated to, job types, a description, priority, backlog and whether a duration is set. Returns job ID, description, status ID, type, priority, dates and allocation; the job's location is withheld unless include_contact_details is set. In descriptions, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses typed into them are not. This search is a POST request that only reads. Pages hold 500 jobs; a page with fewer than 500 is the last.

One job by ID: description, status, type, priority, dates, allocation, its history (status changes with narrative) and its job data (the fields of the job's form). Unless include_contact_details is set, the job location and job data fields whose names mark them as personal (names, contact details, addresses, signatures, photos, locations) are withheld; in the description, the history narratives and other fields, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses written in that free text are not. Uses GET /api/jobs/{id}.

WorkMobile's static list of job statuses and their IDs (GET /api/jobs/jobstatuslist), to decode job_status_id and to pick status_ids for list_jobs. The response format is not documented, so it is returned as WorkMobile sends it.

Job types available to the API user (GET /api/jobtypes): ID, name, description, whether live, the form each uses, default duration and location settings.

One job type (GET /api/jobtypes/{id}) and the fields a job of this type takes, read from its JSON Schema document (GET /api/jobtypes/{id}/schema): name, type, whether required, allowed values and limits. Call this before create_job.

Forms visible to the API user (GET /api/forms): ID, name, description, whether live and visible on mobile, whether it is a sub-form, and when data was last uploaded. The API returns the whole list without paging.

Search the records submitted on one form (POST /api/forms/{FormId}/completedrecords/search): by created or uploaded date, job, mobile user, user group, or searchable field values. Each record comes back with its Id, OriginalId and JobId, the system columns, and the answers. Unless include_contact_details is set, answers in fields whose names mark them as personal (names, contact details, addresses, postcodes, signatures, photos, locations, dates of birth, health, pay) and links to media are withheld; in other answers, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses typed into free text are not. This search is a POST request that only reads. Pages hold 500 records.

One record submitted on a form, found by its record Id (the search criterion id of POST /api/forms/{FormId}/completedrecords/search): system columns and answers. Unless include_contact_details is set, answers in fields whose names mark them as personal and links to media are withheld; in other answers, emails, phone numbers, postcodes and coordinates are redacted, but names and street addresses typed into free text are not. Files and media are never downloaded.

Without form_id: the API user's approval inbox totals (badge counts) from GET /api/approvals/getinboxtotals, returned as WorkMobile sends them with text redacted (the format is not documented). With form_id: the records on that form waiting for the API user's approval (records search with onlyMyPendingApprovals), with personal answers withheld unless include_contact_details is set.

Mobile (field) users visible to the API user (GET /api/mobileusers) with their names, job titles, user group (named from GET /api/usergroups) and whether active. Usernames only with include_contact_details. The API returns the whole list without paging.