REST API: Difference between revisions
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
The authentication method (flow) depends on the use case: | The authentication method (flow) depends on the use case: | ||
* Applications and integrations that perform operations in ContactsLaw on behalf of an interactive user should authenticate using the ''authorisation code'' flow. This requires registering an '''interactive''' application with CPMS ID and prompting the user for credentials. In some cases, it may be possible to leverage an existing access token; e.g. for [[Embedded Content|embedded content]]. ''Examples: Custom reports/dashboards, productivity tools, pre-filling services'' | * Applications and integrations that perform operations in ContactsLaw on behalf of an interactive user should authenticate using the ''authorisation code'' flow. This requires registering an '''interactive''' application with CPMS ID (using a developer account) and prompting the user for credentials. In some cases, it may be possible to leverage an existing access token; e.g. for [[Embedded Content|embedded content]]. ''Examples: Custom reports/dashboards, productivity tools, pre-filling services'' | ||
* Applications and integrations that perform operations autonomously should authenticate using the ''client credentials'' flow. This requires registering an '''application (M2M)''' with CPMS ID, as well as a [[Member|service account]] under which they will run in each [[subscription]]. ''Examples: Scheduled jobs, client portals, data synchronisation'' | * Applications and integrations that perform operations autonomously should authenticate using the ''client credentials'' flow. This requires registering an '''application (M2M)''' with CPMS ID (using a developer account), as well as a [[Member|service account]] under which they will run in each [[subscription]]. ''Examples: Scheduled jobs, client portals, data synchronisation'' | ||
In both cases, | In both cases, users must authorise the application in CPMS ID before it can access their subscription. | ||
== Clients == | == Clients == | ||
| Line 26: | Line 26: | ||
== Data Transfer == | == Data Transfer == | ||
The REST API primarily uses <abbr title="JavaScript Object Notation">JSON</ | The REST API primarily uses <abbr title="JavaScript Object Notation">JSON</abbr> for requests and responses. Some endpoints also allow uploading/downloading binary data (e.g. [[document]] content). | ||
Endpoint behaviour (time zones, confirmation prompts, etc) can be modified using HTTP headers. | |||
Latest revision as of 12:23, 9 May 2025
ContactsLaw provides a REST API which underpins the functionality available in the Desktop App.
The REST API can also be used by third-party applications and integrations to perform operations within ContactsLaw.
Authentication
The REST API uses CPMS ID for authentication, leveraging industry-standard technologies such as OAuth 2.0 and OpenID Connect.
The authentication method (flow) depends on the use case:
- Applications and integrations that perform operations in ContactsLaw on behalf of an interactive user should authenticate using the authorisation code flow. This requires registering an interactive application with CPMS ID (using a developer account) and prompting the user for credentials. In some cases, it may be possible to leverage an existing access token; e.g. for embedded content. Examples: Custom reports/dashboards, productivity tools, pre-filling services
- Applications and integrations that perform operations autonomously should authenticate using the client credentials flow. This requires registering an application (M2M) with CPMS ID (using a developer account), as well as a service account under which they will run in each subscription. Examples: Scheduled jobs, client portals, data synchronisation
In both cases, users must authorise the application in CPMS ID before it can access their subscription.
Clients
The official REST API client for ContactsLaw is available for .NET 8 and .NET Standard 2.0 (includes legacy .NET Framework versions). It is supported on all platforms and architectures.
Features include:
- Strongly-typed endpoints
- Authentication and access token management
- Automatic failover/retry
- Additional functionality for push notifications, deep links and CPMS ID
For other languages and environments, API clients can be built from the OpenAPI 3.0 specification, available from CPMS.
Data Transfer
The REST API primarily uses JSON for requests and responses. Some endpoints also allow uploading/downloading binary data (e.g. document content).
Endpoint behaviour (time zones, confirmation prompts, etc) can be modified using HTTP headers.