Master Service Level Agreement
Green Story API Services
This Master Service Level Agreement (“SLA”) applies to the production API services provided by Green Story Europe B.V. (“Green Story”) to the customer identified in the applicable Statement of Work (“Customer”) for Green Story’s API-based services.
This SLA is incorporated by reference into the Master Services Agreement and/or Statement of Work (“SOW”) between the parties. It applies only to the production API environment made available under the applicable SOW. Sandbox, staging, demo, beta, and trial environments are excluded unless expressly agreed in writing.
Interpretation and SOW Parameters
Values marked as SOW Parameters (see the SOW SLA Parameter Schedule) are set in the applicable SOW. Where the SOW sets a value, it applies; where it is silent, the default in this SLA applies. Precedence and versioning are governed by Sections 19 and 20.
1. Scope of Services
Green Story will provide Customer with access to its production API services as described in the applicable SOW (the “Covered Services”). The Covered Services may include, without limitation, generation and retrieval of life cycle assessment and product footprint outputs, traceability and supply-chain data exchange, and other API functionality made available by Green Story. The specific endpoints, functionality, and scope applicable to Customer are those set out in the SOW.
This SLA applies only to the production environment for the Covered Services. Sandbox, staging, demo, beta, or trial environments are excluded from this SLA unless expressly agreed in writing.
2. Service Availability
Green Story will use commercially reasonable efforts to make the production API available at least the Availability Target (default: 99.0%) in each calendar month, excluding Permitted Downtime.
“Availability” means the production API is operational and able to receive and process valid API requests in accordance with the agreed API documentation.
Monthly availability is calculated as (Total Minutes in the calendar month, less Permitted Downtime, less Downtime) divided by (Total Minutes in the calendar month, less Permitted Downtime), expressed as a percentage. Green Story’s monitoring systems shall be the primary source of measurement for determining availability.
“Permitted Downtime” means any downtime, degradation, delay, or unavailability caused by:
- scheduled maintenance;
- emergency maintenance;
- Customer systems, applications, integrations, credentials, infrastructure, or networks;
- incorrect, incomplete, unsupported, or malformed API requests;
- Customer’s failure to implement the API in accordance with Green Story’s documentation;
- third-party hosting, cloud, telecommunications, internet, security, or infrastructure failures outside Green Story’s reasonable control;
- force majeure events;
- suspension of service in accordance with the agreement;
- excessive or abusive API usage outside agreed usage limits or rate limits;
- issues arising from incomplete, incorrect, or unsuitable input data provided by Customer or Customer’s clients.
3. Support Hours
Standard support is provided during the Support Hours (default: Monday to Friday, 09:00–21:00 IST, excluding public holidays in India).
For the purposes of this SLA, “Business Day” means Monday to Friday excluding public holidays in India; “Business Hour” means an hour falling within the Support Hours; and references to “business hours” and “business days” are construed accordingly.
Support outside the Support Hours is not included unless specified in the SOW.
4. Support Channels
Customer may submit support requests by email to Green Story’s nominated support or account contact. Green Story may provide additional support channels from time to time, but email shall remain the primary support channel unless otherwise agreed.
For P1 incidents, Customer may in addition contact the Priority Escalation Contact specified in the SOW (by telephone or other channel notified by Green Story), so that critical production issues can be raised outside standard email handling.
Green Story may also make available an AI voice agent for logging and triaging support requests. Tickets logged through the AI voice agent are recorded and prioritised in the same manner as email requests. The AI voice agent provides intake, logging, and triage only; it does not itself constitute resolution or a guaranteed response, and the response times in Section 5 continue to apply.
Customer should include sufficient information for Green Story to investigate the issue, including:
- description of the issue;
- affected endpoint or workflow;
- relevant request ID, payload, timestamp, and response/error message where available;
- business impact;
- steps already taken by Customer to troubleshoot the issue.
5. Incident Priority Levels and Response Times
Green Story will use commercially reasonable efforts to respond to support requests within the Target Initial Response times below, unless different values are specified in the SOW.
| Priority | Description | Target Initial Response |
|---|---|---|
| P1 — Critical | Production API is unavailable or materially prevents Customer from generating or retrieving product footprint results across its production workflow. | 6 business hours |
| P2 — High | Major degradation, repeated failures, or material issues affecting a significant number of valid production requests, but where the service is not fully unavailable. | 1 business day |
| P3 — Normal | Non-critical bugs, data mapping issues, endpoint questions, configuration issues, or standard support queries. | 2 business days |
| P4 — Low | Documentation questions, minor clarifications, enhancement requests, non-urgent issues, or general product feedback. | 5 business days |
“Initial Response” means Green Story’s acknowledgement of the support request and commencement of internal review. It does not guarantee resolution within the same timeframe. Target response times are measured from Green Story’s receipt of the request during Support Hours; a request received outside Support Hours (including one logged automatically via the AI voice agent) is treated as received at the start of the next Business Hour.
6. Resolution Efforts
For P1 and P2 incidents, Green Story will use commercially reasonable efforts to investigate, mitigate, and restore the affected service as soon as reasonably practicable.
Resolution times may vary depending on the cause, severity, complexity, third-party dependencies, quality of information provided by Customer, and whether the issue requires changes to data models, methodology, infrastructure, or code.
Green Story does not guarantee a fixed resolution time unless expressly agreed in writing.
7. Scheduled Maintenance
Green Story may perform scheduled maintenance to improve security, reliability, performance, infrastructure, models, datasets, or functionality.
Where reasonably practicable, Green Story will provide at least the Scheduled Maintenance Notice Period (default: 48 hours) prior notice of scheduled maintenance that is expected to materially affect production API availability.
Green Story will use commercially reasonable efforts to schedule maintenance outside peak usage hours and to limit scheduled maintenance that materially affects production API availability to no more than the Scheduled Maintenance Monthly Cap (default: 8 hours per calendar month).
Scheduled maintenance shall not count as downtime for the purpose of calculating monthly availability.
8. Emergency Maintenance
Green Story may perform emergency maintenance without prior notice where required for security, stability, continuity, data integrity, or urgent operational reasons.
Green Story will use commercially reasonable efforts to minimise disruption and notify Customer as soon as reasonably practicable.
Emergency maintenance shall not count as downtime where it is reasonably required to protect the service, Customer data, platform integrity, or security.
9. API Usage and Rate Limits
The production API will be configured to support Customer’s agreed annual usage allocation under the applicable SOW or agreement.
Green Story may apply reasonable rate limits, throttling, concurrency limits, authentication controls, or usage controls to protect platform stability, security, fair usage, and service continuity.
Green Story will use commercially reasonable efforts to ensure such controls do not materially prevent Customer from using the service within the agreed annual allocation, provided Customer’s usage pattern is reasonable and aligned with the agreed commercial scope.
Customer shall not attempt to bypass API limits, authentication controls, or usage restrictions.
10. Usage Allocation
Customer’s Annual Usage Allocation and the Billable Unit against which it is measured (for example, product footprint outputs generated, traced units, or API transactions) shall be set out in the applicable SOW. The Allocation tracks Billable Units as defined in the SOW, not every technical API call.
Unless otherwise specified in the SOW, re-running or retrieving an existing result does not consume additional Allocation where no new Billable Unit is generated.
Unused annual Allocation does not roll over into the next contract year unless expressly agreed in writing in the SOW.
11. Migration Support
Migration support is optional and applies only where expressly included in the applicable SOW. The migration scope (including volume) and target timeline are set out in the SOW. Where migration support is included, the following standard terms apply.
The target migration timeline runs from Green Story’s receipt of complete and validated migration files from Customer in the agreed format, and is dependent on:
- Customer providing complete, accurate, and structured input data;
- timely clarification of data issues;
- availability of required mapping fields;
- absence of material inconsistencies in the migration data;
- the scope remaining within the agreed migration volume and complexity.
Migration support does not include remediation of incomplete or inaccurate source data unless separately agreed.
12. Customer Responsibilities
Customer is responsible for:
- implementing the API in accordance with Green Story’s documentation;
- maintaining the security of API credentials, keys, and secrets;
- validating input data before submission;
- ensuring Customer and its clients provide complete and accurate product data;
- monitoring its own systems, integrations, queues, retry logic, and downstream workflows;
- promptly notifying Green Story of suspected issues;
- providing sufficient technical information for troubleshooting;
- ensuring its use of outputs is consistent with the agreed methodology, documentation, and applicable claims guidance.
Green Story is not responsible for issues arising from Customer’s systems, implementation choices, payload errors, unsupported use cases, or misuse of outputs.
13. Methodology and Output Limitations
Green Story’s API outputs are generated using Green Story’s LCA models, datasets, assumptions, and internal expert review processes.
Unless expressly agreed in writing, API-generated outputs are not independently certified, critically reviewed, or validated by a third-party certification body by default.
If Customer or Customer’s clients require formal third-party validation, critical review, certification, or claim substantiation for specific outputs or claims, this must be separately scoped and agreed.
Customer acknowledges that LCA outputs depend on the quality, completeness, granularity, and accuracy of input data. Where input data is incomplete or generic, Green Story may use assumptions, proxies, default values, or secondary datasets in accordance with its methodology.
14. Service Credits
If Green Story fails to meet the Availability Target in a calendar month, Customer may request a service credit as set out below, unless different bands are specified in the SOW.
| Monthly Availability | Service Credit |
|---|---|
| Below the Availability Target but at or above 95.0% | 5% of the monthly equivalent fee |
| Below 95.0% | 10% of the monthly equivalent fee |
Service credits are calculated against the monthly equivalent fee for the affected month, being one twelfth (1/12) of the annual subscription fee (or the applicable monthly fee, where Customer is billed monthly). This basis applies equally to customers on annual and monthly plans.
To claim a service credit, Customer must submit a written request within the Service Credit Claim Window (default: 30 days) after the end of the month in which the alleged SLA failure occurred. The request must include reasonable supporting details.
Service credits shall not apply where downtime or degradation falls within Permitted Downtime.
Service credits are Customer’s sole and exclusive remedy for any failure by Green Story to meet the Availability Target. The total service credits payable in respect of any calendar month shall not exceed the Service Credit Cap (default: 10% of the monthly equivalent fee for that month). No service credit will be payable while Customer is in material breach of the agreement or has undisputed fees overdue. Service credits have no cash value and are applied against the next invoice due to Customer or, where Customer has prepaid for the current term and no further invoice is due before renewal, against the renewal invoice.
15. Security Incidents
If Green Story becomes aware of a confirmed security incident materially affecting the production API or Customer data, Green Story will notify Customer without undue delay and, where the incident constitutes a personal data breach, within any notification timeframe required under the applicable Data Processing Agreement, and take commercially reasonable steps to investigate, mitigate, and remediate the incident.
Customer is responsible for promptly notifying Green Story of any suspected compromise, misuse, or unauthorised access involving Customer’s API credentials or systems.
16. Changes to the API
Green Story may update, modify, or improve the API, documentation, models, endpoints, infrastructure, authentication, or available functionality from time to time.
Green Story will use commercially reasonable efforts to provide reasonable notice of material changes that are expected to require Customer-side implementation updates.
Green Story will avoid unnecessary breaking changes where reasonably practicable. Where breaking changes are required, Green Story will aim to provide a transition period unless immediate change is required for security, stability, legal, methodological, or operational reasons.
17. Exclusions
This SLA does not apply to:
- sandbox, test, staging, demo, or beta environments;
- third-party systems or services not controlled by Green Story;
- Customer-side implementation, infrastructure, or connectivity issues;
- incorrect or unsupported API usage;
- errors caused by incomplete, inaccurate, or inconsistent input data;
- disputes over LCA methodology, assumptions, impact factors, or interpretation of outputs unless separately addressed in the SOW;
- third-party validation, certification, or critical review;
- scheduled or emergency maintenance;
- service suspension permitted under the agreement;
- force majeure events.
18. Term
This SLA will apply for the duration of the applicable SOW or agreement, unless replaced or amended in writing by both parties.
19. Order of Precedence
In the event of conflict between this SLA and the main agreement or SOW, the following order of precedence shall apply unless expressly stated otherwise:
- the main agreement;
- the applicable SOW;
- this SLA;
- the API documentation.
For the avoidance of doubt, SOW-specific terms prevail over this SLA for the relevant engagement.
20. Version and Change Control
This SLA is version-controlled. Green Story may issue updated versions of this SLA from time to time. Cross-cutting changes are made to this master SLA and are not pushed through individual SOWs.
Each SOW pins the version of this SLA in effect on its effective date, and that version continues to apply to that engagement for its term. Green Story will provide at least 30 days’ notice of material adverse changes to the standard SLA. Such changes take effect for an existing engagement only on its next renewal, unless the parties agree otherwise or Customer is offered a right to terminate the affected engagement. Non-material updates (clarifications, formatting, contact details, and the like) may apply immediately.
21. Review and Amendments
The parties may review this SLA periodically as usage volumes, technical requirements, or commercial terms evolve. Any customer-specific changes to this SLA must be agreed in writing in the SOW.
Version history
| Version | Effective date | Notes |
|---|---|---|
| 1.0 | 1 October 2025 | Current version. First version published at greenstory.io/legal. |
Each SOW pins the SLA version in effect on its effective date (Section 20). Prior versions are archived in the legal-agreements repository and available on request at [email protected].