REST API Introduction
A detailed reference guide exposing all of the REST API endpoints/options is available here:
https://docs.bipsync.com/reference
To understand the various objects that Bipsync contains, and how they relate to one another, please see this document:
https://docs.bipsync.com/v1/docs/bipsync-domain-objects
Accessing the API
Bipsync’s API is available to all clients upon request. The API allows agents to perform CRUD (Create-Read-Update-Delete) operations on Bipsync’s internal data objects, including notes, files, companies and much more. It also exposes more complex functionality such as Bipsync’s Full Text Search, and its archiving capabilities.
The API is web-hosted and is usually accessed on a subdomain similar to the client’s main Bipsync URL, i.e. if the client has a Bipsync installation hosted at
Then the API is usually hosted at
Though this is configurable and can be changed to specification.
The API has a number of endpoints which can be communicated with over HTTPS. The API responds with data in JSON format, and expects JSON in kind (where applicable).
Security and Authorization
In order to restrict access to authorized agents the API is secured in two ways.
Access Token
Firstly all HTTP requests sent to an endpoint must include an HTTP header with the name Authorization.
The API expects the value of this header to be an access token, which is a JSON Web Token issued via OAuth.
See the guidance on OAuth for more details.
IP Restriction
Secondly the API is restricted by IP range to limit the agents that are able to access the server. Typically whitelisted IPs are limited to Bipsync’s servers/offices and the clients’ servers/offices. The whitelist can be expanded on request.
While the IP restriction is not mandatory and can be disabled entirely, Bipsync does not recommend this approach be taken unless absolutely necessary.
HTTP GET requests with POST bodies
Some stricter libraries don't allow GET requests with POST body content, so for these we provide alternative paths suffixed with "-get" using POST verbs, for example:
- Verb: GET Path: /v1/user
- Verb: POST Path: /v1/user-get
Both support the same parameters/features. These alternative paths are provided for ALL endpoints that specify the GET verb.
Updated 3 months ago