Connections
Last updated
Last updated
Connections allow for users of your applications to easily share data. They can be created by a user and can extend access to objects from that user to another.
For example, we have User A and User B. User A has a patient file that they'd like to share with User B. However, User B doesn't have any inherent access to this file.
Here User A has the highest level of access to their patient file, Delete access (level 7) because they are the owner of the file. However, User B has no access to the file.
To grant User B access to the file, User A simply needs to create a connection between the patient file and User B and specify the level of access that should be granted.
Here the connection is created and User A specifies that Read access (level 4) should be granted to User B.
Through the connection, User B is able to access the file. However, User A has control over User B's access. If User A no longer wants user B to have access, User A simply has to delete the connection.
For all of the access levels, see Access Control in the API documentation.
Retrieve Connections
First find all the connections available to you
Accept Connection
Once that token is retrieved, you can accept the connection with a POST utilizing the connection token.
📘NoteThe state of the connection is now "1" or "Active"Auto-Accept
Automatically Applying Connections
In some scenarios, it may be necessary to create connections without the target needing to accept the connection. This is possible if the following apply:
The context object is not an Account
The context object does not require connection acceptance
The target is already a registered user and the account _id is used in the target instead of email
"auto":true is sent in the connection target
Optionally you can uncheck Send Connection Notifications to prevent notifications from going out when connections are created as well.
Automatically applying a connection is then very much like creating a connection like above but with "auto":true added to the target.HTTP
Request Body
JSON Response
📘NoteThe connection is immediately created in state "1" or "Active" without any acceptance needed.
For more details on the connection object, it's properties, and available API routes, see Apply Connection
To create a connection you need
The context: An object instance you'd like to share
The targets: A target user or team of users you'd like to extend access to
A connection can have multiple targets, so an array of targets is sent when creating the connection. A target takes the form of:JSON
For an individual target if you have only an email address. In cases when you only have the account id, you can also pass in:JSON
When inviting an individual, object will always be "account".
Then, either email or _id of the account must be sent. email is useful for inviting individuals when the account _id is either not known or if the individual does not yet have a user account. If a user with that username exists in the org, the user account will automatically be used. If using email you can optionally specify the name as illustrated above. This can be useful in connection notification templates. For example, you can send personalized emails with the recipient's name included in the message.
access is the level of context access you are granting to the target.
Creating a connection is a matter of calling a route with the following pattern:HTTP
Where your_org_code is the org code you specified when signing up. object_name is the plural name of the object you are creating a connection to and object_id is the _id of the object instance that you are creating a connection to.
Here's an example on a c_prescription instance:HTTP
Request Body
JSON Response
The above created a connection with fred.banting@example.org to the c_prescription instance with _id 5519c01aae2fd2b02915c81f. But notice that the state of the connection is "0" of "Pending". This is because it has not yet been accepted by Mr. Banting.
Mr. Banting would then receive an email notification at fred.banting@example.org notifying him that John Smith at NewHealthCo would like to share a Prescription file. Once Fred registers as a user, he can then accept or decline the connection. If accepted, Mr. Banting would have Read access to the c_prescription (level 4).
Once in place, User B now has access to the patient file and is able to read it.
To configure your object to not require connection acceptance, when creating your object or editing your object settings, be sure that Require Connection Accept is unchecked.
