Overview

This schema represents the foundational structure for data entries served over the API. At this stage, all attributes are defined within a single model for simplicity. However, we recognize that more structured representations—such as dedicated models for activities, locations, products, and measurements—would improve clarity, reusability, and validation. These improvements are planned for Version 1, which will introduce a more modular and extensible schema while maintaining backward compatibility where possible.

For now, this prototype serves as a working implementation that supports early integrations. Developers should expect refinements in future releases. Feedback is welcome as we iterate toward a more robust v1!

Forming queries

Searches are served by GET requests to the /footprint-<tier> endpoint. For best performance we recommend being as specific as you can, and use thecountry, activityID, scope, year values to construct a query. However, all fields are optional and are used to filter records in our impact factor database.

Example query parameters

This example will retrieve the direct and indirect


 {**'activityID': 'wheat',
  'impactCategory': ['Water_stress_Agriculture_water_stress',
   'Land_use_Extensive_forestry'],
  'country': 'India'}**

Match criteria

All fields are case-insensitive. activityID ,company, and product allow partial matches (e.g. "activityID":"Rice" will match paddy_rice) whereas all other fields require exact matches. Use the aggregation endpoints to obtain lists of possible values for other field types.

String format conventions

Fields in our database, and in your query parameters, have names in camel-case, with capitalized acronyms (see below). In contrast, endpoint URLs

Returned values

The body of the HTTPS request returned by the API may contain several records, which contain the following fields:

Activity information