ICR Program
HomeProjectsCreditsTransactionsInsights
  • Welcome to the ICR program documentation
    • About ICR
      • ICR Team
        • Gudmundur Sigbergsson
        • Olafur "Oli" Torfason
        • Bjorn H. Helgason
        • Thordur "Thor" Agustsson
        • Alondra Silva Munoz
        • Dr. Rannveig Anna Guicharnaud
        • Robert Huldarsson
        • Ria Antil
        • Alvaro Vallejo Rendón
      • ICR's Mission Statement
      • ICR's Context
      • Leadership
        • Leadership and Commitment
        • Policies
          • Quality policy
          • KYC/KYB Compliance Policy
          • Grievance policy
          • Anti-Corruption Compliance Policy
          • Impartiality policy
          • ICR Privacy and Cybersecurity Policy
          • Diversity, Equality, and Inclusion policy
        • Organizational Roles, Responsibilities, and Authorities
          • Leadership
            • Chief Executive Officer (CEO)
            • Chief Operating Officer (COO)
            • Chief Technology Officer (CTO)
            • Chief Product Officer (CPO)
            • Chief Science Officer (CSO)
            • Chief Marketing Officer (CMO)
            • ICR Board
              • Members
                • Daníel F. Jónsson
                • Kristján I. Mikaelsson
              • ICR Board Procedures v3.0
            • ICR Program Advisory Panel
              • Members
              • ICR Program Advisory Panel 3.0
          • ICR Program Advisory Panel
            • Amit Sharma
            • Geetha Gopal
            • Javier Castro
          • Forums
            • ICR Project Proponent and Developer forum
              • ICR Project Proponent and Developer Forum Terms of Reference
            • ICR Stakeholder forum
              • ICR Stakeholder Forum - Terms of Reference
            • ICR VVB forum
              • ICR VVB Forum Terms of Reference
            • ICR Forum Guidelines
            • Forum Application
          • Committees
            • Appeals Committee
              • ICR Appeals Committee Terms of Reference
      • Articles of Association for International Carbon Registry ehf.
  • Fundamentals
    • Climate change
    • Kyoto protocol
    • Paris Agreement
      • Nationally Determined Contributions
      • Carbon Markets Under the Paris Agreement
    • Voluntary Carbon Markets
    • Compensation
      • ÍST 92
      • ISO 14068-1:2023
  • ICR Program
    • Overview
    • Fundamentals
      • ISO
        • ISO 14064
          • ISO 14064-1
          • ISO 14064-2
          • ISO 14064-3
          • ISO 14068-1
      • Project Origination
      • Additionality
      • ICR Registration Process
      • Validation and verification
        • Accreditation
    • Definitions
      • ICR Definitions v3.1
        • Version history
          • ICR Definitions v3.0
          • ICR Definitions v2.0
          • ICR Definitions v1.0
    • Methodology Development
      • Criteria
        • ICR Methodology Requirements v3.0
        • Version history
          • ICR Methodology Requirements 2.0
          • ICR Methodology Requirements 1.0
      • Procedural
        • ICR Methodology Approval Process v3.0
        • Version history
          • ICR Methodology Approval Process v2.0
          • ICR Methodology Approval Process v1.0
      • ICR Methodologies
        • Under development
          • M-ICR001
          • M-ICR002
          • M-ICR003
          • M-ICR004
          • M-ICR005:
          • M-ICR006
          • M-ICR007
          • M-ICR009
          • M-ICR011
        • Approved ICR Methodologies
      • Templates
        • Concept note
          • Older versions
        • Methodology description
          • Older versions
        • Methodology summary
          • Older versions
    • Project development
      • Criteria
        • ICR Requirement Document v6.0
          • Version history
            • ICR Requirement Document v5.0
            • ICR Requirement Document v4.0
      • Procedural
        • ICR Process Requirements v6.1
          • Version history
            • ICR Process Requirements v6.0
            • ICR Process Requirements v5.0
            • ICR Process Requirements v4.0 Final
            • ICR Process Requirements v3.0
        • ICR Article 6 2 procedures v1.0
      • Templates
        • Project concept description (PCD)
          • Older versions
        • Project design description (PDD)
          • Older versions
        • Monitoring report (MR)
          • Older versions
        • Project design description and monitoring report
          • Older versions
        • Letter of attestation
        • Non-performance report
          • Older versions
        • Non-permanence event report
          • Older versions
        • Non-permanence risk assessment
        • Non-performance risk assessment
      • Tools
        • ICR Tool for Environmental and Socio-economic Safeguards and Sustainable Development
      • Approved methodologies, modules and tools
        • ICR approved methodologies, modules and tools v4.0
    • Validation and verification
      • Validation and Verification Bodies
      • Criteria
        • ICR validation and verification specifications v2.0
          • Version history
            • ICR validation and verification specifications v1.0
      • Templates
        • Methodology validation report (MValR)
          • Older versions
        • Validation report (ValR)
          • Older versions
        • Verification report (VerR)
          • Older versions
        • Validation and verification report (ValVerR)
          • Older versions
    • Terms and conditions
      • Terms and Conditions - Users
      • Terms and Conditions - Project
      • ICR Terms and Conditions Market Participants
      • Fee Schedule 2024-2025
      • 🔦ICR KYC/KYB Complience Policy
      • ICR Terms and Conditions - Organizations
        • Older versions
          • ICR Terms and Conditions - Organizations
    • Public consultation
      • Methodologies
        • 2023
          • M-ICR0001
          • M-ICR0002
          • M-ICR0003
          • M-ICR0004
          • M-ICR0005
        • 2024
          • M-ICR0006
        • 2025
          • M-ICR009
          • M-ICR007
          • M-ICR011
      • ICR Program
        • 2023
          • Specifications to guide validation and verification
          • Program revision August 2023
        • 2024
          • Program Revision - July 2024
    • Grievance
      • ICR Grievance process
        • Submit a Complaint
    • Document Library
      • Documents
  • Biodiversity Program
    • Overview
    • Fundamentals
    • Definitions
    • Requirements
      • Templates
        • Concept note
    • Public consultation
    • Document Library
    • Fee Schedule - Biodiversity Pilot Phase 2024-2025
  • Carbonregistry.com
    • Marketplaces
      • Terms and Conditions - Trading Hub
    • On Chain
      • How it works
      • Credit data
      • Contracts
      • Retiring Credits Onchain
    • Registry user guide
      • Introduction
      • Get started
        • Create a user account
          • User profile
            • Authentication
            • Documents
            • API
          • KYC
        • Create an organizational account
          • KYB
      • Account management
        • User account management
        • Organizational account management
          • Projects
          • Users
          • Documentation
          • Settings
          • API
      • Project proponents and developers
        • Registering a project
          • Create a New Project
            • New Project Home Screen
            • Project mitigations
            • Project location
            • Benefits
            • Documents and files
            • People and Organizations
              • People
              • Organizations
            • Home screen tabs
              • Overview
              • Mitigations
              • Benefits
              • Documents
              • People
              • Media
              • VVB
            • Submit for ICR Review
          • Manage a project
          • Transition
          • Page
          • Transition
          • Validation/verification
          • Authorized representatives
          • Finish
        • Credits
          • Ex-ante issuance
          • Ex-post issuance
          • Transferring credits
          • Retiring credits
          • Cancelling credits
        • Side Panel
        • Page 1
      • Organizations
        • Account management
        • Credits
        • Retiring credits
      • Insights
    • API
      • Apps
        • Using ICR apps
          • Approve new permissions
          • Review installations
        • Creating ICR apps
          • About creating ICR apps
            • Best practices
          • Registering an ICR app
            • Permissions
            • Webhooks
              • Webhook actions and payloads
              • Handle deliveries
              • Validate deliveries
              • Handle failed deliveries
            • Callback URLs
        • Authentication
          • Authenticate as an app
          • Generate a JWT
          • Authenticate as an installation
          • App private keys
          • Authenticate as an organization
        • Examples
          • Setting up an ICR app
          • Requesting credit action for organization
          • Interacting with the organization warehouse
      • Endpoints
        • V0.5
          • Apps
          • Organizations
          • Inventory
          • Projects
          • Retirements
          • Warehouse
          • Credits
          • Documents
          • Utility
        • V1 - Beta
          • Organizations
          • Projects
          • Transactions
          • Retirements
          • Credit actions
          • Subaccounts
          • Utility
      • Environments
      • Versions
      • Authentication
    • The Credit Bundler
      • Purchasing Credits
      • Post Purchase: Accepting Credits
  • Quality management system
    • ICR QMS
Powered by GitBook
On this page
  • Create a webhook secret
  • Validating webhook deliveries
  • Testing webhook validation
  • Typescript example
  • Signed payload
  1. Carbonregistry.com
  2. API
  3. Apps
  4. Creating ICR apps
  5. Registering an ICR app
  6. Webhooks

Validate deliveries

PreviousHandle deliveriesNextHandle failed deliveries

Last updated 1 year ago

LogoLogo

Once your server is configured to receive payloads, it will listen for any delivery that's sent to the endpoint you configured. To ensure that your server only processes webhook deliveries that were sent by CarbonRegistry and to ensure that the delivery was not tampered with, you should validate the webhook signature before processing the delivery further. This will help you avoid spending server time to process deliveries that are not from CarbonRegistry and will help avoid man-in-the-middle attacks.

To do this, you need to:

  1. Create a secret token for a webhook.

  2. Store the token securely on your server.

  3. Validate incoming webhook payloads against the token, to verify that they are coming from CarbonRegistry and were not tampered with.

Create a webhook secret

Go to the "General" tab of your CarbonRegistry app's dashboard.

There you'll be able to define a webhook secret that CarbonRegistry will use to sign webhook POST requests.

Validating webhook deliveries

CarbonRegistry will use your secret token to create a hash signature that's sent to you with each payload. The hash signature will appear in each delivery as the value of the x-icr-signature-256 header. For more information, see "Webhook events and payloads."

In your code that handles webhook deliveries, you should calculate a hash using your secret token. Then, compare the hash that CarbonRegistry sent with the expected hash that you calculated, and ensure that they match.

There are a few important things to keep in mind when validating webhook payloads:

  • CarbonRegistry uses an HMAC hex digest to compute the hash.

  • The hash signature always starts with sha256=.

  • The hash signature is generated using your webhook's secret token and a base64 encoding of the payload contents, stored in the signedData key in the root of the request payload body.

  • If your language and server implementation specifies a character encoding, ensure that you handle the payload as UTF-8. Webhook payloads can contain unicode characters.

  • Never use a plain == operator. Instead consider using a method like secure_compare or crypto.timingSafeEqual, which performs a "constant time" string comparison to help mitigate certain timing attacks against regular equality operators, or regular loops in JIT-optimized languages.

Testing webhook validation

You can use the following secret and payload values to verify that your implementation is correct:

  • secret: "turtleSecret"

  • payload: "It's no secret turtles rock."

If your implementation is correct, the signatures that you generate should match the following signature value:

  • x-icr-signature-256: sha256=622744da2f7b232aec4663a66d7604bd4f867330487c706b58dbac45af3bb104

Typescript example

require("dotenv").config();
import express, { Request, Response } from "express";
import * as crypto from "crypto";

const app = express();
app.use(express.json());
app.post("/webhook", (req: Request, res: Response) => {
  const signature = req.header("x-icr-signature-256");
  const signedData = req.body.signedData;
  const verified = verify_signature(signature ?? "", signedData ?? "");

  if (!verified) return res.status(403).send("Forbidden");
  res.status(202).send("Accepted");

  console.log("SIGNATURE:", signature);
  console.log("EVENT:", req.body.event);
  console.log("Installation:", req.body.installation);
  console.log("Organization:", req.body.installation.organization);
  console.log("Sender:", req.body.sender);

  const signedDataDecoded = Buffer.from(signedData ?? "", "base64").toString();
  const signedPayload = JSON.parse(signedDataDecoded);
  console.log("Signed Payload:", signedPayload);
});

const verify_signature = (signature: string, signedData: string) => {
  const signatureCheck = crypto
    .createHmac("sha256", process.env.WEBHOOK_SECRET ?? "")
    .update(signedData)
    .digest("hex");
  const trusted = Buffer.from(`sha256=${signatureCheck}`, "ascii");
  const untrusted = Buffer.from(signature, "ascii");
  try {
    return crypto.timingSafeEqual(trusted, untrusted);
  } catch (error) {
    return false;
  }
};

app.listen(4040, () => {
  console.log("Server is listening on port 4040");
});

For repository see here.

Signed payload

If, for security reasons, you only want to use data that has been signed with your defined secret key you can instead of using the payload body decode the signed data like this:

  const signedDataDecoded = Buffer.from(signedData ?? "", "base64").toString();
  const signedPayload = JSON.parse(signedDataDecoded);
  console.log("Signed Payload:", signedPayload);

The signedPayload will match the request body exactly (except perhaps for the ordering of the keys)