BigID API/Best Practices: Difference between revisions

From BigID Developer Portal
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
Before you start developing, there's some things you should keep in mind.
The BigID API has hundreds of endpoints and even more data points. To best utilize the API, keep the following best practices in mind:


== Start with the data you need ==


== Start with the data you need ==
When developing an integration, first write down what data you need. There's a lot of data inside of our API and it's easiest to search for something when you know what you're looking for. Once you have your list of what you need for your integration, search the [https://docs.bigid.com BigID Docs] for an API that provides that data.
 
== Every API has a reference example, the UI ==
 
The API powers our UI as well as your integrations. That means anything you can see within the UI is accessible to you programmatically. If you're struggling to find a piece of information in the API documentation, find it in the user interface. The network activity of that page will give you the API endpoint you're looking for. See how to examine network activity [https://developer.chrome.com/docs/devtools/network/ here].
 
== Copy, don't modify ==


When developing an integration, first write down what data you need. There's a lot of data inside of our API and it's easiest to search for something when you know what you're looking for. Once you have your list of what you need for your integration, search the [https://docs.bigid.com|BigID Docs] for an API that provides that data.  
If your integration is going to modify data it didn't create, copy records instead of modifying them. Modifying data sources and other sensitive objects could cause important processes like Subject Access Requests to return the wrong data. Copy these resources then apply your modifications to the copy. That way you aren't causing ripple effects in the system.


== Every API has a reference example - The UI ==
== Ask before performing intensive operations ==


The API powers our UI as well as your integrations. That means anything you can see within the UI is accessible to you programmatically. If you're struggling to find a piece of information in the API documentation, find it in the user interface. The network activity of that page will give you the API endpoint you're looking for. See how to examine network activity [https://developer.chrome.com/docs/devtools/network/|here].
Some operations like scans are intensive. You should ask the user before performing these tasks because they may cause significant database load on an organization's operational systems. Ideally, confirm with the user prior to performing any task that puts load on an external data source (scans, SARs, previews).

Latest revision as of 03:35, 8 March 2022

The BigID API has hundreds of endpoints and even more data points. To best utilize the API, keep the following best practices in mind:

Start with the data you need

When developing an integration, first write down what data you need. There's a lot of data inside of our API and it's easiest to search for something when you know what you're looking for. Once you have your list of what you need for your integration, search the BigID Docs for an API that provides that data.

Every API has a reference example, the UI

The API powers our UI as well as your integrations. That means anything you can see within the UI is accessible to you programmatically. If you're struggling to find a piece of information in the API documentation, find it in the user interface. The network activity of that page will give you the API endpoint you're looking for. See how to examine network activity here.

Copy, don't modify

If your integration is going to modify data it didn't create, copy records instead of modifying them. Modifying data sources and other sensitive objects could cause important processes like Subject Access Requests to return the wrong data. Copy these resources then apply your modifications to the copy. That way you aren't causing ripple effects in the system.

Ask before performing intensive operations

Some operations like scans are intensive. You should ask the user before performing these tasks because they may cause significant database load on an organization's operational systems. Ideally, confirm with the user prior to performing any task that puts load on an external data source (scans, SARs, previews).