This advice is most important for data providers and publishers, rather than data consumer or readers.
As a data provider, your system's users will not always want to provide all data as part of a regular or periodic data exchange. To avoid oversharing data, provide some kind of user-friendly interface or tool that allows your system users to select which data should be sent to an API. Because API exchanges are generally regular, this configuration info should generally be captured and re-used.
By default, data elements should be turned off and require a clear and deliberate action by a user with the proper authority to enable them. This helps ensure that your systems's user is making an active choice to provide the data, and is authorized to perform that action.
Often, a simple starting point is to allow the users to select which API resources should be shared as part of a regular data exchange. However, the specific use case should be considered as well. For example, if a system integration will be supporting programs only at certain schools or in certain programs, then the API client should allow the configuration to be restricted in this same manner – to particular schools.
Note: The data consumer has similar responsibilities and should also restrict access accordingly.
For example, if the consumer is an API implementation where data is being written by a provider who is an API client, the API implementation should secure the API such that only data for the use case is allowed to be published to the API.