When people propose connecting farms, feed companies, and verification bodies through an API, the first discussion often concerns “which endpoints to build.” But being technically connected is different from understanding the same fact in the same way. If a farm’s feed_amount means the amount actually fed rather than the amount purchased, a feed company’s batch_id means a production lot rather than a delivery unit, or a verification body’s approved means receipt of data rather than completed verification of the reduction, the API becomes a channel that propagates errors quickly.

A carbon data API is not a simple system integration. It is a digital contract that exchanges who submitted which evidence, which calculation used that evidence, and who reached which determination under what criteria. Define the business meaning and responsibilities first, and design the URLs and JSON afterward.

Misconception: putting all raw data in one database makes verification easier

Centralization may make searching easier, but it does not resolve rights and responsibilities. Farms hold work logs and raw sensor data; feed companies manage product specifications and batch information; and verification bodies retain independent determinations and evidence. If every original for which each party is responsible is copied unconditionally into one place, the latest version, correction authority, trade secrets, and retention periods become ambiguous.

Giving a verification body write access to every system can also undermine its independence. A verifier must review submitted materials and record queries, determinations, and requests for supplementary information, but must not modify a farm’s raw data or a feed batch. Rather than focusing on combining data, the API should clearly separate ownership of the original from permissions to read, submit, and determine.

Nor does the mere existence of an API create interoperability. Field names, units, time zones, identifiers, state transitions, error handling, and version policies must all align. The OpenAPI Specification provides a language-neutral interface description that enables people and computers to understand an HTTP API’s capabilities without inspecting its source code. The carbon meaning of the domain, however, must be agreed separately by the organizations involved.

The first step is to separate each stakeholder’s originals and events

A farm’s originals include barn, sensor, animal or group identifiers; animal numbers; feeding, ventilation, cleaning, and movement events; measured values; calibration; and device status. A feed company’s originals include product codes, production batches, composition, shelf life, shipping and delivery quantities, instructions for use, and change histories. A verification body’s originals include the verification scope, criteria, materiality determinations, samples, queries, findings, determinations, and signature times.

The three parties need to share the minimum events required for linkage, not all their internal materials. For example, they could define business events such as FeedDelivered, FeedApplied, SensorObserved, CalibrationPerformed, DataExcluded, CalculationExecuted, EvidenceSubmitted, FindingRaised, and StatementVerified. Names may vary with the implementation, but “feed was delivered” and “feed was actually given to livestock” must not be merged into one event.

GS1 EPCIS is a visibility-event standard for sharing supply-chain events in a common language. Adoption is not mandatory here, but it can serve as a reference model that separates products, locations, times, and business steps.

Items that must be included in a shared data contract

The first is stable identifiers. Assign different IDs to organizations, farms, barns, devices, sensors, feed products, batches, deliveries, application programs, and verification engagements. Display names can change, so do not use them as keys. Do not confuse external identifiers with internal IDs; record the issuing authority and namespace.

The second is values and units. Do not send only 12.3; send the value, unit, measurement principle, detection limit, and quality status together. A ppm concentration and kg CH₄ emissions are different concepts, so distinguish them in fields and schemas. Unit conversion must not overwrite the original; retain the conversion formula and version used.

The third is time and validity periods. Distinguish observation time, event time, system receipt time, and correction time. Use a format containing a UTC offset, such as RFC 3339, and specify the start, end, and boundary-inclusion rules for a period. The feed-application period and verification period may differ, so do not reduce them to a single date field.

The fourth is states and state transitions. Define what draft, submitted, accepted, questioned, superseded, verified, and rejected mean and who may change them. accepted may mean only that a format check passed, not that content verification was completed. Document the responsibility and the next permitted action for each state.

The fifth is lineage. W3C PROV-O provides a foundation for representing data Entities, Activities that used or generated them, responsible Agents, and the relationships among them. The implementation need not use RDF, but it can consistently retain relationships such as derived_from, generated_by, attributed_to, method_version, and source_hash. To make a hash reproducible, specify both its algorithm and whether the hashed object is the original bytes or a normalized record. It must be possible to trace a final reduction amount back to the raw data and the calculation run.

The sixth is the correction method. If submitted raw data are edited in place, the version the verifier saw disappears. When an error is found, create a new version, link the previous version as superseded, and record the reason for the correction and the approver. Because deletion requests may conflict with legal retention requirements, establish separate retention, de-identification, and access-blocking policies for each data type.

Field scenario: 2 tonnes of feed do not equal 2 tonnes of reduction activity

Suppose a feed company sends a delivery event for 2 tonnes of low-methane feed. The farm system confirms receipt, but the actual feeding record is 1.7 tonnes, while 0.2 tonnes remain in inventory and 0.1 tonnes were discarded. If the API treats the delivered amount as the applied amount, the reduction activity is overstated. The verification body must query the relationship among the delivery note, inventory, feeding log, and number of target animals.

In a correct model, FeedDelivered and FeedApplied are separate events linked by the same batch ID. An application event contains the period, barn or target group, quantity, unit, recording method, author, and evidence links. Without modifying the original, the verification body creates a FindingRaised event to request an explanation of the 0.3-tonne difference. The farm adds inventory and disposal events and creates a new version of the submission package.

The calculation service then produces a result using the approved applied amount, measurement period, and method version. The verification determination refers not only to the result, but also to the evidence package and calculation-run ID used. This makes it possible to identify affected results and reports later if feed-batch information is corrected or the calculation formula changes.

Align authentication and authorization with actions, not partner types

RFC 9700, published in 2025, presents the latest security best current practice for OAuth 2.0, addressing relevant mitigations for token replay attacks and designs that constrain privileges and target scope. For server-to-server integration, separate organizational identities from workload identities and establish token-lifetime and key-rotation policies appropriate to the risk and service architecture.

Authorization must not stop at one broad role such as “feed-company user.” Restrict the target and action with scopes such as farm:A/read:aggregates, farm:A/write:delivery, and verification:case-123/read:evidence. Bulk downloads, access to raw data, corrections, and verification determinations should require higher privileges and be subject to auditing. When farm consent is withdrawn or a contract ends, do not merely revoke the token; address the rights to use and retain existing copies as well.

Retries, errors, and versions determine operational trust

Farm networks may disconnect frequently, so retrying is a default behavior. Use event IDs and idempotency keys to prevent the same delivery or observation from being registered more than once. The server must return a clear processing result and treat a resent request identically when its successful response was lost. For bulk uploads, provide a batch ID, per-item success or failure results, and a resumption point.

Distinguish format, authorization, duplicate, missing reference ID, expired schema, and pending-review errors, and provide both retry eligibility and a correlation ID for tracing. Status values such as completed and rejected are examples; the actual API specification must fix the permitted states and transition conditions in a table.

Versioning is not merely a number in a URL. Define compatibility policies for changes to fields, enumeration values, and units, and manage the OpenAPI document alongside the code. Notify partners of deprecation schedules and alternatives as well.

An API for verification bodies must provide auditability

Verification is not a matter of confirming that an API returned 200. ISO 14064-3 covers principles and requirements for the verification and validation of greenhouse-gas statements concerning organizations, projects, and products. A specific program may impose additional requirements. Rather than automatically declaring compliance with a particular standard, the API should therefore provide the materials a verifier needs to assess boundaries, criteria, evidence, change histories, and material errors.

A verification read view or export should include the snapshot at the time of submission, schema and method versions, raw-data hashes, the exclusion list, queries and responses, and the determination history. Querying only the current values makes it impossible to reproduce what was reviewed in the past. Large raw datasets can be supplied through a signed URL, a time-limited access URL, or a separate data package, but access and downloads must be recorded.

Implementation checklist

  • Have the farm, feed company, and verification body each defined the originals and shared events for which they are responsible?

  • Are delivery, receipt, actual feeding, inventory, and disposal distinguished as separate events?

  • Are there stable IDs for organizations, farms, barns, devices, feed batches, and verification engagements?

  • Does every value include its unit, time, quality status, and measurement or calculation method version?

  • Are submission, format acceptance, content review, and completed verification distinguished as separate states?

  • Do corrections remain as a new version and a reason instead of overwriting the original?

  • Can a final claim be traced back to the raw data, activities, and responsible parties?

  • Are token permissions restricted to the minimum scope for each farm, period, data type, and action?

  • Do retries and bulk uploads avoid creating duplicate aggregates?

  • Are error codes, correlation IDs, and retry eligibility clear?

  • Are there an OpenAPI specification, examples, change notices, and consumer contract tests?

  • Can a verifier inspect the snapshot at submission and its change history with read-only access?

Conclusion: a good API preserves responsibility and meaning, not merely connectivity

The success of an API cannot be judged by call volume. It must distinguish delivery from application, concentration from emissions, and receipt from verification, while preserving responsibility for the original source of each dataset. If identifiers, units, times, states, lineage, corrections, and permissions are not agreed, a fast connection creates confusion just as quickly.

The proper sequence is therefore to define responsibility for events and evidence, establish the data contract and least privilege, set retry and version policies, and design the verification snapshot. Standards such as OpenAPI, OAuth, EPCIS, and PROV are tools for expressing and exchanging this contract. The name of a particular standard does not automatically establish the eligibility of a carbon claim. Connections between systems lead to trust only when the API presents an uninterrupted Evidence Chain in accordance with each program’s methodology and verification criteria.

Sources