> 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/field-reference.md). # Field Reference Custom fields are found by their own name or ID, so there is nothing to look up for those. Case fields and contact fields are different: they are a fixed list, and the names must be spelled exactly as they appear here, capitalisation included. ## Case fields Requested as `case.`, for example `case.CaseReference`.

Field	Value
`CaseReference`	The full case reference.
`CaseDescription`	The case description.
`CaseType`	The name of the case type.
`CaseStatus`	The case status as text.
`CaseEmail`	The case's own email address.
`Labels`	The labels on the case.
`OpenDate`	When the case was opened. Returned with a type of `DateTime`.
`PlannedCompletionDate`	The planned completion date. Returned with a type of `DateTime`.
`FullDetailsOfTransaction`	The transaction details held on the case.

### People on the case

Field	Value
`FeeEarner`	The fee earner's display name.
`FeeEarnerEmail`	The fee earner's email address.
`PartnerEarner`	The partner's display name. Note the name of this field.
`ClientName`	The client's display name.
`ClientCode`	The client's contact code.
`SourceName`	The source's display name.
`SourceCode`	The source's contact code.

### The current user These describe whoever is using the system at the time, not anyone recorded on the case. They are useful for scripts that behave differently depending on who is looking.

Field	Value
`CurrentUserName`	The signed-in user's display name.
`CurrentUserInitials`	The signed-in user's initials.
`CurrentUserEmail`	The signed-in user's email address.

### Billing

Field	Value
`HourlyRateApplicable`	`True` or `False`, as text.
`HourlyRate`	The billing rate, when an hourly rate applies. Empty otherwise.
`FixedFee`	The fixed fee amount.

## Contact fields Requested as `contact..`, for example `contact.Client.Email`. The same field names apply whichever relationship you ask for.

Field	Value
`Name`	The contact's display name.
`KnownAs`	What the contact is known as.
`ClientCode`	The contact's code.
`Labels`	The labels on the contact.
`Email`	The contact's main email address.
`Phone`	The contact's main phone number.

### Personal details

Field	Value
`Title`	Mr, Mrs, Dr and so on.
`FirstName`	The contact's first name.
`LastName`	The contact's last name.
`Gender`	The contact's gender as text.
`DOB`	The date of birth, formatted as `dd/MM/yyyy`.
`SocialSecurityNumber`	The contact's national insurance or social security number.

{% hint style="warning" %} These six fields only exist on contacts that are people. Asking for one on a company contact does not return a polite error, it fails the whole request. If a relationship might hold either a person or a company, request `Name` instead, or handle the failure. {% endhint %} ### Address

Field	Value
`AddressBlock`	The whole address as one block of text, ready to display.
`AddressLine1`	The first line of the street address.
`AddressLine2`	The second line of the street address.
`City`	The town or city.
`State`	The county or state.
`Zip`	The postcode.
`Country`	The country.

Where a contact has more than one email address, phone number or address, these fields return the first one held. There is no way to ask for a specific one. ## Anything not on these lists A name that is not recognised comes back as an entry with an `error` rather than failing the whole request, so a typo in one token still leaves the others usable. See [Response Format](/developer-documentation/case-data-api/response-format.md) for how those errors appear. For anything beyond these lists, use a custom field. Custom fields are requested by their own name or ID, and there is no fixed vocabulary to match. --- # 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/field-reference.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.