> For the complete documentation index, see [llms.txt](https://docs.agilecase.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.agilecase.com/developer-documentation/case-data-api/requesting-values.md). # Requesting Values Everything you want from a case goes into the single `getValues` parameter. It holds a list of tokens separated by semicolons, and each token says what kind of data you want and which field: ``` ?getValues=Custom.CustomerRating;case.FeeEarner;contact.Client.Email ``` A token is made of segments separated by full stops. The first segment is always the type, and it decides how the rest of the token is read. ## The six types
TokenReturns
custom.<field>A custom field on the case.
case.<field>A built-in case field, such as the reference or the fee earner.
contact.<relationship>.<field>A field on a contact linked to the case.
casetable.<table>Every row of a custom field table.
client.custom.<field>A custom field on the case's client contact.
source.custom.<field>A custom field on the case's source contact.
The type itself is not case sensitive, so `Custom.CustomerRating` and `custom.CustomerRating` are the same request. What follows it often is, as described below. ## Custom fields ``` custom.CustomerRating custom.6364 ``` Name the field or give its numeric ID. Names are matched with spaces removed and capitalisation ignored, so a field called "Customer Rating" is found by `custom.CustomerRating`. Writing the name without spaces also avoids having to encode them in the URL. Using the numeric ID is more precise, since two field groups can hold fields with the same name. The ID is shown when you edit the field in settings. A field that exists but has never been given a value on this case returns its configured default rather than an error. {% hint style="warning" %} A full stop separates the segments of a token, so a custom field whose name contains one cannot be requested by name. Use its numeric ID instead. {% endhint %} ## Case fields ``` case.CaseReference case.FeeEarner ``` These are the built-in fields of the case rather than anything you have configured. Unlike custom fields, the names here must be spelled exactly as listed in the [Field Reference](/developer-documentation/case-data-api/field-reference.md), including capitalisation. `case.CaseReference` works; `case.casereference` returns an error saying the field name is invalid. ## Contact fields ``` contact.Client.Email contact.Borrower1.LastName ``` The middle segment is the contact's relationship to the case, and the last is the field you want. Relationship names are matched with spaces, hyphens and capitalisation ignored, so a relationship called "Next of Kin" is reached as `contact.NextOfKin.Email`. `Client` and `Source` are recognised as relationships without being configured as such, and these two are matched exactly, so the capital letter matters. Field names must also match the list in the [Field Reference](/developer-documentation/case-data-api/field-reference.md) exactly. ## Custom fields on contacts ``` client.custom.CreditScore source.custom.4821 ``` These read a custom field belonging to the contact record rather than the case. The field is named in the final segment, by name or ID, following the same matching rules as case custom fields. The middle segment is only there for readability; `custom` is the conventional choice. These two types are only for the client and the source. To read a custom field on any other contact, you need that contact's own record rather than the case. ## Custom field tables ``` casetable.RiskAssessments casetable.1176 ``` Name the table's custom field group, or give its numeric ID, and every row on the case comes back with all of its columns. Table group names are matched ignoring capitalisation but not spaces, so use the ID if the name has spaces in it. Only groups that are actually configured as tables can be requested this way. Asking for an ordinary field group returns an error saying the table was not found. ## Putting it together ```javascript var wanted = [ 'case.CaseReference', 'case.CaseStatus', 'custom.CustomerRating', 'contact.Client.Email', 'casetable.RiskAssessments' ].join(';'); $.get('/api/case/' + caseid + '/data?getValues=' + wanted, function (data) { // ... }); ``` Results arrive grouped by kind rather than in the order you asked for them, so read them out by name rather than by position. How to do that is covered in [Response Format](/developer-documentation/case-data-api/response-format.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.agilecase.com/developer-documentation/case-data-api/requesting-values.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.