API v1 versus v2

Core APIs are offered in two versions - v1 and v2.

Both are currently supported and have no planned deprecations.

Both are available on all sites although Premium endpoints within them may not be enabled everywhere.

Core v1

For full documentation see APIDocs.

These may get a few new endpoints over time, but will not get new functionality or have fields renamed ore removed.

Core v2

For full documentation see APIDocs.

V2 APIs are in more constant development. There may be some breaking changes to field names or functionality.

Differences from v1:

• Total results returned from a Search query is a maximum of 100.
• A custom_results   parameter can be accepted. This takes a list of system API parameters or custom field names to include in the response. The UUID for the result and whatever identified fields will be returned. This can make the results much faster since less data has to be colleced for the response. An empty array - custom_results = []  - will result in just the UUID being returned.
• Custom Fields can be included in the Search Parameters.
• Custom Fields on subtables (like Litigations, Charges, or Services) can be included when getting a Matter or Searching for Matters.
• Case Restrictions are honored. If a case is restricted, it will not appear in the API results unless the API User is in the appropriate Office/Program/Case or has the API Access All Cases   permission.
• UPSERT is an available function in Creating Records. You can specify an Update   search parameter and if one record is found meeting those search criteria, it will update that record. Otherwise it will create a new record instead.
• Dates (and some other fields) are not returned as objects with raw_value   and text_value .
• Multiselect lookups are returned as an array of strings instead of an object with all_values   and individual_values .
• Lookup values are not returned as text. In APIv1, you would see: "client_gender": "male"  . In API v2 you would get an object instead:

"client_gender": {
  "lookup_value_id": 100156,
  "lookup_value_name": "Male",
  "lookup_value_uuid": "22b9854d-cbbc-430f-ad9c-bb580bcb447c",
  "lookup_type_name": "Genders",
  "lookup_type_table_name": "gender",
  "lookup_type_custom": false,
  "lookup_type_uuid": null
}

This gives you the ability to then make a followup API call to get the other values in the Lookup list to know what are appropriate alternatives. Since client_gender   is a system field you would use the Generic Lookup API to get the values, substituting in the lookup_type_table_name   in the URL. If this were a custom lookup, you could substitute in the lookup_type_uuid   into the Custom Lookup API Values endpoint URL.