Core argument

CO₂ calculation must be integrable into line-of-business systems without creating new structural dependencies. Especially in the public sector, the question is not only whether a calculation works technically. What matters is whether it remains governable, replaceable, testable and organisationally accountable over time.

Manual calculations may work for individual cases, but they do not scale. Direct API integrations are convenient, yet they often create a tight coupling between the domain system, provider logic, data model and operating model. A configurable API library can act as an intermediate layer: it decouples specialist software from calculation providers, makes providers comparable and keeps governance decisions with the organisation and the contracting authority.

The goal is not to pretend that providers are interchangeable as if methodological differences did not matter. The goal is to make those differences visible, testable and manageable. Only then can an organisation make an informed decision about which provider to use, when to change providers and what technical or substantive consequences such a change may have.

Starting point: manual calculation does not scale

Many CO₂ calculation processes begin pragmatically. Someone opens a web form, enters origin and destination, copies the result and pastes it into a form, spreadsheet or domain system. For pilot projects or isolated cases, this may be sufficient. For recurring administrative or institutional processes, it is not.

Manual calculation creates media breaks. It is error-prone, difficult to audit and hard to automate. Different people may use different tools, interpret inputs differently or document results in inconsistent ways. As soon as case numbers grow, reporting requirements increase or central steering is needed, this becomes a structural problem.

The obvious answer is automation. But automation alone does not solve the problem. It merely shifts the problem to the integration architecture. That is where it becomes clear whether an organisation remains capable of acting over time or enters into a new dependency.

Direct API integration: convenient, but binding

The direct integration of a provider into a domain system is initially attractive. It appears fast, manageable and cost-efficient: the specialist software calls an API, passes the required parameters and receives a CO₂ value. For a first technical proof of concept, this is often the easiest path.

This simplicity has a price. The domain system implicitly adopts the provider’s data model, parameter logic, error codes, response structure and methodological assumptions. The more these assumptions become embedded in forms, validations, workflows, tests and reports, the harder a later change becomes.

Vendor lock-in therefore does not start only when a contract runs for a long time or when a provider holds exclusive rights. It already starts when an organisation turns one provider’s interface into its own internal integration logic.

Technical dependency

Technical dependency arises when code, data model and process logic are tailored directly to one provider. Changing providers then means more than changing a URL. It means adapting inputs, error handling, result interpretation and tests.

Methodological dependency

Methodological dependency arises when a provider’s calculation logic silently becomes the norm. If a different provider is used later, results may differ, while it remains unclear whether those differences stem from methodology, factors, distance modelling, travel class logic or data quality.

Organisational dependency

Organisational dependency arises when responsibilities, support processes, documentation and reporting routines are built around one specific provider. A provider change then becomes not only a technical project, but an organisational one.

Controlled decoupling through an API library

A configurable API library forms an intermediate layer between the domain system and the calculation provider. The domain system no longer integrates Provider A or Provider B directly. Instead, it integrates a stable internal interface. The library translates this internal structure into the respective provider format.

This does not create magical provider independence. But it creates a controlled place where differences between providers can be described, tested and managed. Coupling does not disappear completely. It is deliberately moved into a layer that is designed for it.

Provider profiles: making differences visible

Providers differ in more than price and availability. They differ in supported inputs, response formats, calculation methods, versioning, signature capability, batch requests, handling of stopovers, error logic and metadata quality.

A library should not hide these differences completely. If it pretended that all providers could do the same thing, it would create a new form of opacity. A better approach is a provider profile that describes, in machine-readable form, which capabilities are supported and which are not.

{
  "provider": "example-provider",
  "profile_version": "1.0",
  "capabilities": {
    "multiple_flights_per_request": true,
    "via_segments": true,
    "custom_rfi": true,
    "custom_price_per_ton": true,
    "calculation_date": true,
    "model_version_returned": true,
    "factor_version_returned": true,
    "signed_responses": false,
    "audit_profile": true
  },
  "limits": {
    "max_flights_per_request": 50,
    "supported_airport_identifiers": ["iata", "icao", "coordinates"]
  }
}

For public-sector buyers and institutional clients, this is crucial. Requirements can be formulated not only in general terms, but tested concretely: Does the provider support the required metadata? Can calculations be repeated? Are versions returned? Are signed responses available? Can multiple flights be processed in a single request?

Making providers testable

An API library enables not only switchability, but also testability. This is at least as important. A provider change is only realistic if an organisation can first examine how different providers behave with the same inputs.

This requires shared test cases. They should include typical, critical and boundary scenarios: simple direct flights, connections, missing airport codes, different travel classes, historical travel dates, multiple flights in one request and deliberately invalid inputs.

Keeping in-house and partner-developed models connectable

A configurable library is not only relevant for external providers. It also makes in-house developments connectable. If an organisation or scientific partner develops its own calculation model, that model should not become a special case outside the infrastructure. It should be usable through the same integration logic.

This is particularly relevant when models evolve: new factors, different assumptions, additional modes of transport, more differentiated datasets or methodological corrections. A good architecture allows such developments to be incorporated without rebuilding the domain system each time.

This creates a shared integration framework for external providers, internal models and project-specific extensions. Different calculation logics can coexist, be compared and be replaced step by step.

Governance remains with the organisation and the contracting authority

The most important effect of a decoupled architecture is organisational: governance remains with the organisation and the contracting authority. It is not silently delegated to the provider whose API happened to be integrated first.

Governance here means more than access control. It is the ability to define rules, check requirements, approve providers, control versions, document test results and make provider-change decisions traceable.

Governance questions

Governance means that the organisation decides which dependencies it accepts - not that these decisions disappear unnoticed into integration code.

calco2la.to

Architecture principle: stable internal interface, replaceable providers

The central architecture principle is simple: the domain system does not speak directly to a specific provider. It speaks to a stable internal interface. The library handles mapping, validation, provider selection, error normalisation and the return of a consistent result format.

Domain system
    ↓
Stable internal CO₂ interface
    ↓
Configurable API library
    ↓
Provider adapter A / Provider adapter B / In-house model
    ↓
CO₂ calculation, metadata, evidence

This makes the specialist software smaller, more stable and less dependent on individual provider decisions. At the same time, methodological differences between providers remain visible because they are documented in profiles, tests and configurations.

Example configuration

{
  "default_provider": "ifeu-model",
  "fallback_provider": "provider-b",
  "required_response_profile": "audit",
  "provider_selection": {
    "public_sector_reporting": "ifeu-model",
    "quick_estimate": "provider-b"
  },
  "requirements": {
    "must_return_model_version": true,
    "must_return_factor_version": true,
    "must_support_multiple_flights": true,
    "must_support_replayability": true
  }
}

Switchability does not mean arbitrariness

Provider change is often misunderstood. The aim is not to swap providers arbitrarily while ignoring methodological consequences. Different models can produce different results. That is normal and may be scientifically justified.

Switchability therefore does not mean that all providers are the same. It means that differences can be handled in a controlled way. A change should be prepared, tested, documented and communicated. That is precisely why a decoupling layer is needed.

Implementation path

A decoupled integration architecture can be built step by step. The important point is to make the right interface decisions early, so later requirements for governance, testing and provider change are not blocked.

Conclusion: governability instead of mere integration

Integrating CO₂ calculation into domain systems is necessary. Manual processes do not scale, are not sufficiently reviewable and are organisationally too weak over time. But the answer should not be an unreflective direct provider integration.

Direct API integration is convenient, but it can create new dependencies: technical, methodological and organisational. A configurable API library offers a better path. It enables a stable internal interface, controlled decoupling, provider profiles, shared tests and later integration of in-house models.

This keeps the decisive steering capability where it belongs: with the organisation, the contracting authority and substantive governance. Providers supply calculation capability, models and expertise. The architecture must ensure that this does not turn into an uncontrolled dependency.