Short answer: FieldsToReturn will not do this. You can send it, and the request will succeed, but the response comes back with the full record shape regardless. The same is true of ClearObjectProperties.
For your specific case there is a better option. There are two user endpoints, and the second one is the lighter shape:
| Endpoint | Shape | Approx. fields |
|---|
POST /api/v1.0/users | Full user record | ~35 |
POST /api/v1.0/users/list | Simplified record | ~19 |
The simplified shape includes both UserId and SchoolIdNumber, so this gets you close to what you are after:
POST /api/v1.0/users/list?$s=500
Content-Type: application/json
{}
Each item comes back as:
{
"UserId": "00000000-0000-0000-0000-000000000000",
"SiteId": "00000000-0000-0000-0000-000000000000",
"Name": "Example User",
"FirstName": "Example",
"LastName": "User",
"Email": "user@example.org",
"Username": "example.user",
"SchoolIdNumber": "123456",
"LocationId": "00000000-0000-0000-0000-000000000000",
"LocationName": "Example School",
"RoleId": "00000000-0000-0000-0000-000000000000",
"RoleName": "Student"
}
Two things to know about that endpoint:
- It carries no
CreatedDate, ModifiedDate, or custom field values. If you need any of those, use POST /api/v1.0/users and drop the fields you do not want on your side. SchoolIdNumber is populated from a Student Information System integration. Without one it will be empty on every record.
One naming note: the field is SchoolIdNumber rather than StudentIdNumber.
More generally, most endpoints do not have a lighter variant like this, so for other entities the practical approach is to take the response and select what you need in your own code. If the goal is reducing the total volume of a large pull rather than the width of each record, the settings that actually move it are page size ($s) and filtering the rows down with the Filters array, since response size is driven far more by how many records come back than by how many fields each one has.