BigID API/Best Practices: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
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 [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 == | |||
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). | |||
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).