The LexisNexis® CounselLink® Integration Application Programming Interface (CL-INT-API) uses specialized endpoints to facilitate integration and the processing of data from a customer's system to CounselLink. These specialized endpoints are grouped and sequenced according to a typical customer's integration needs, and is a recommendation only.
The CL-INT-API includes functionality that allows client customers to systematically:
- Receive invoice information from CounselLink
- Apply payments to invoices in CounselLink
- Create new matters or updating existing matters in CounselLink
Open API Documentation
-
Full JSON inbound/outbound payload examples
-
Detailed schema information
-
Ability to populate 3rd party REST client tools for development and testing
-
Support for automatic code generation
OpenAPI Documentation: https://api.counsellink.net/api/
Download OpenAPI YAML File: https://api.counsellink.net/openapi.yaml
Click one of the following topics to access below:
Prerequisites:
|
What's needed before you start |
How to obtain |
Note(s) |
|---|---|---|
|
|
The AccessKey and SecretKey will be provided to you by the Business Consultant during implementation. |
The SecretKey is used to calculate the HMAC of a string. See signing the request, where the output of the HMAC algorithm is the signature which is sent along with the request in the Authorization header and the AccessKey. |
Media Types
The CL-INT-API uses JSON format to encode each HTTP request and response. When the client sends an HTTP request to the server, the server expects a JSON formatted body. When the client receives the HTTP response, if the response has body, it will parse the body as JSON format.
HTTP Response and Error Codes
The CL-INT-API returns responses as an HTTP status code, indicating the result of the operation for every request. For most GET and some PUT requests, a response message is returned in JSON format, along with the status code. For other PUT requests, only the status code is returned to indicate whether the operation is successful or not.
Error Responses
| Code | Reason |
|---|---|
| 429 |
Too many requests - Occurs when excessive API calls are made in a given time span, exceeding the client's quota. |
| 503 | Service Unavailable - Likely due to temporary overloading (e.g., rate limit exceeded). |
To interpret any error response that was returned by an API Endpoint, access the Open API Documentation.
Content Types
The CL-INT-API utilizes the Content-Type := type "/" subtype *[";" parameter] format for the Content-Type field/MIME which indicates the data contained in the body of message/entity.
As denoted in the field example "content-type": "application/vnd.cl.int.api.v1.0.0+json;charset=UTF-8, the CL-INT-API supports the non-ASCII (UTF-8) character set.
Date Time
All date and timestamps are returned in ISO 8601 format: YYYY-MM-DDThh:mm:ssz, and uses [hh][mm][ss] as the basic format and [hh]:[mm]:[ss] as the extended format.
where:
YYYY = four-digit year
MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01 through 31)
T = combined date and time representation, where the letter 'T' is the delimiter, and a valid time expression (e.g., 2015-09-01T14:30)
hh = two digits of hour (00 through 23) (am/pm NOT allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
z = time zone designator (e.g., 2015-09-01T14:30Z" or "2015-09-01T12:30-02:00)
Time zones in ISO 8601 are expressed in UTC (Coordinated Universal Time), with a special UTC designator Z.
If no UTC relation information is given with a time representation, the time is assumed to be in local time.
If the time is in UTC, add a Z directly after the time without a space (e.g., 2015-09-01T14:30Z), where Z is the zone designator for the zero UTC offset; '09:30 UTC' is represented as '09:30Z' or '0930Z'; and '14:45:15 UTC' would be '14:45:15Z' or '144515Z'. So for example, a timestamp of 2016-06-15T21:19:00Z corresponds to 5:19 EDT and a timestamp of 2016-11-27T11:55:00Z corresponds to 6:55 EST.
UTC does not observe daylight savings time, so Eastern Time (E.S.T.) is five hours behind UTC during the winter months and Eastern Daylight Time is four hours behind UTC during summer months when daylight savings is in effect.
The offset between local time and UTC is often useful information and is calculated as 'local time minus UTC'. The equivalent time in UTC can be determined by subtracting the offset from the local time:
- A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC.
- A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC and is appended to the time in the form ±[hh]:[mm], ±[hh][mm], or ±[hh]. timestamps
If the time being described is one hour ahead of UTC (i.e., the time in Berlin during the winter), the zone designator would be "+01:00", "+0100", or simply "+01". To represent a time behind UTC the offset is negative (i. e., the time in New York in winter is UTC−05:00). For other time offsets see List of UTC time offsets.
The signature for a request is created by applying the HMAC function to the access key, the service name, and the timestamp. The timestamp identifies the time at which the request was signed, and is only valid for 15 minutes.
For information regarding combined date and time representations, intervals, durations, and additional formatting requirements, see ISO 8601.
Field Lengths
The length for numeric/decimal fields are measured in (numeric precision, numeric scale), where numeric precision is the number of digits in a number, and numeric scale is the number of digits to the right of the decimal point in a number. Using the 'exchangeRate' field length as an example (with precision=23 and scale=6, allows a value that has 17 digits before the decimal and 6 digits after the decimal, for a maximum of 23 digits.
The length for a character String or Unicode data type is the number of characters.
API Rate Limitations
This section contains current restrictions and limitations on the use of the CL-INT-API.
The CL-INT-API enforces the following limitations on customer usage:
| Limitation | Type of Measure | Limit | Unit of Measure |
|---|---|---|---|
| Rate Limit | Requests | 10 per second | Per Client |
Clients are allowed 10 requests/second per client API key, which is equivalent to 10 transactions per second (TPS), across all of their API users.
The API Rate limitations are applied across all active API keys unless a request header of 'client-key' is added to the API request containing the API key.
Cursors
Whenever a cursor driven response is returned that is less in size than the total size of the response, a maximum of 3 links / URLs can be returned, with each response having a unique cursor or no cursor (e.g., initial request). These links can then be used to retrieve the:
- Current content again (SELF) - This link returns the current response. The initial self link has no cursor.
- Previous content (PREV) - This link returns the response that was prior to the current response. There is no previous link on the initial response.
- Next content (NEXT) - This link returns the response following the current response. There is no next link on the final response.
Use the link URLs as they are; the values are URL encoded, so there is no need to encode the cursor.
Initial Request
Start Date: Not required. Defaults to 2 days prior.
Size: Not required. If not provided, all results are returned with a SELF link and no cursor.
Cursor: Not provided on initial request.
Initial Response Example:
Cursor values are for example purposes only.
Next Request
Link: /client/client-contacts/events?startDate=2021-01-20T05:00:00Z&searchFilter=CONTACT_GROUP&size=1&cursor=eyJzeW5jSWQiOjEyODM2MDE3LCJtb2RlIjoiTkVYVCIsImVuZERhdGUiOjE2MTE1ODQ3MTYwMDB9
Next Response Example:
Final Response Example:
Pagination
Some endpoints associated with the CL-INT-API use pagination (the size of the page). It has a default size of 500 and is a part of the Response Header information.
In terms of the cursors, they are sent back in the response in the Link Headers. The Link Header has a URI part, and a relation part. A relation of 'next' specifies the URL needed to get the next set of records. A relation of 'prev' specifies the URL to get the previous set of records.
To get the next set of records, you need to get a Link Header where the relation is 'next'. From the URI, you can extract the query parameter called 'cursor' and send subsequent requests.
Use the following scenario as the example:
On the first call if the number of contacts in the list is more than 20, the endpoint provides a link to navigate to the NEXT page. The maximum page size allowed is 500 records per page, and if the page size is greater, then the API defaults the page size to 500.
The endpoint continues to provide the page link(s) until the user reaches the last page. The available count in the response is the total count of contacts.
Versioning
The CounselLink Integration API continues to evolve. Please update your apps for each version. Any calls not using the identified version number may break or return errors.
- Information about changes to the API may be found on our What's New page.
- If there has been no API changes noted, continue to use the prior version in the call.
- If there is change introduced for an API call in a new version, you must implement the changes on your client side before the old format is deprecated.
Basic Data Types
| Term | Description |
|---|---|
| Array[LfoAssignment] | Collection/list of LFO Assignment parameters |
| Array[MatterAllocation] | Collection/list of allocation contacts |
| Array[Message] | Collection/list of messages |
| availableCount | The total number of invoices pending extraction |
| BigDecimal | An exact way of representing numbers |
| Boolean | Simple true (Yes) or false (No) conditions |
| Code | The matter to be created or updated |
| Cursor | A control structure that enables traversal over the records in a database to include retrieval, addition, and removal of database records |
| Date | Date in ISO 8601 format YYYY-MM-DD (2015-09-01) not to include the time stamp |
| DateTime | Timestamp in ISO 8601 format (2015-07-17T04:00:13Z) |
| Double | Double-precision 64-bit IEEE 754 floating point |
| Enum | Set of restricted/designated values |
| Error | Generated when the primary action of the endpoint has failed |
| fetchedCount | The number of invoices returned |
| INFO | Informational message |
| Integer | A whole number, positive or negative (32-bit signed numeric value without a decimal) |
| int64 | Signed 64-bit (8-bytes) integers |
| Long | 64-bit signed numeric value (8 bytes or 64-bits) |
| MatterAllocation | Allocation contact information |
| MatterStatus | The status or ‘state’ the matter is in. Valid statuses are "Active" and "Closed". When the matter status is not provided, it will be set to “Active”. If a status other than "Closed" is provided, then matter status will be set to “Active”. |
| Map[string,string] | Collection of key/value pairs representing text type UCDFs |
| MD5 | A widely used cryptographic hash function producing a 128-bit (16-byte) hash value, typically expressed in text format as a 32 digit hexadecimal number. MD5 has been utilized in a wide variety of cryptographic applications, and is also commonly used to verify data integrity. |
| Message | A message is sometimes provided when the code is not sufficient to troubleshoot the issue |
| Number | Integer/whole number (e.g., 0,1,2,3, 12355, 23) |
| Object | Collection of named data referring to a single entity -- also contains functions on that data (key-value pairs) |
| Payment | List of payment records for an invoice |
| RID | Request identifier/Id |
| String | Sequence/list of characters (i.e., letters, numbers, alpha-numeric, other) |
| TEXT | Variable-length non-Unicode data |
| Type | Type of adjustment indicates if the adjustment is flat or percentage based |
| Void | No value(s) is/are available |
| Warn | Generated when the primary action of the endpoint succeeds but a secondary operation has failed |