edeXa Signature API

edeXa provides open, standardized APIs and smart contract specifications that enterprises can self-host and fully control. With the edeXa Signature API, each company can integrate edeXa’s blockchain signing capabilities into their own workflow while retaining complete ownership of infrastructure and data.

edeXa Signature API offers a straightforward and secure method for digitally signing documents, generating cryptographic hashes, and verifying previously signed documents on the edeXa blockchain. It ensures data integrity, avoids duplicate submissions, and guarantees blockchain transparency.

Key Features

• Accepts files via multipart/form-data uploads.

• Converts uploaded documents to SHA-256 hash.

• Checks if the document hash is already signed.

• Signs new document hashes on the edeXa blockchain.

• Returns the blockchain transaction hash.

---

Security Highlights

• We do not store original documents on the server or blockchain.

• Only the SHA-256 hash is stored on-chain.

• Blockchain-backed proof of authenticity.

• API key-based access control.

---

API Service Demonstration

For a better understanding of the edeXa Signature API in action, we have prepared short demonstration videos.

🎯 What You’ll See

• Sign a Document → Upload a file, generate its SHA-256 hash, and store hash on the edeXa blockchain. Instantly receive a transaction hash as proof of signing.

• Verify a Document → Check if a document is already signed by comparing its hash against the blockchain records.

• Validate on Blockchain → Use the transaction hash to confirm the signature on the edeXa Blockchain Service for complete transparency.

📄 Sign Document

🔍 Verify Document

👉 Access the UI here: edeXa-Signature

Project Setup

1. Clone the Repository

git clone https://github.com/devEdexa/signing-service-api.git
cd signing-service-api

1. Configure Environment

• We provide a sample .env.example file to help you get started.

cp .env.example .env

Then update the .env file with values that match your project setup and environment

Key	Description
RPC_URL	edeXa JSON-RPC URL (https://rpc.edexa.com & https://rpc.edexa.network)
PRIVATE_KEY	The private key of the signer wallet is used to sign transactions.
CHAIN_ID	Chain ID of the blockchain network (e.g., 5424 for edeXa mainnet).
CONTRACT_ADDRESS	Address of the deployed smart contract for document signing
API_AUTHENTICATION	Enables or disables api_key based access control (true or false).
SIGN_DOC_API_KEY	api_key to access the sign endpoint (optional if API_AUTHENTICATION=false)
VERIFY_DOC_API_KEY	api_key to access the verify endpoint (optional if API_AUTHENTICATION=false)
EXPLORER_URL	Explorer URL of the edeXa Blockchain(https://explorer.edexa.network/)

ℹ️ All environment variables should be configured as needed to match the deployment target and security model.

▶️ Run the Project

cargo build
cargo run

• service will be available at http://localhost:3000.

---

🚀 Deployment Options

The signing service supports deployment through Docker for local development or Kubernetes for production environments.

🐳 Option 1: Docker Compose (Local Deployment)

A pre-built Docker image is available for quick deployment without requiring a Rust environment.

📜 Docker-Compose File:

docker-compose.yaml

services:
  signing-service:
    image: ghcr.io/devedexa/signing-service-api:latest
    container_name: signing-service
    ports:
      - "3000:3000"
    env_file:
      - .env
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M
    networks:
      - signing-network

networks:
  signing-network:
    driver: bridge

▶️ Start the Service

Run this docker-compose.yaml file using the below command..

docker-compose up -d

The API will be available for local testing at: http://localhost:3000

☁️ Option 2: Kubernetes Deployment (Production-Ready)

The signing service can be deployed to any Kubernetes cluster such as AWS EKS, Google GKE, or Azure AKS.

📜 Kubernetes File:

deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: signing-service
  labels:
    app: signing-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: signing-service
  template:
    metadata:
      labels:
        app: signing-service
    spec:
      containers:
        - name: signing-service
          image: ghcr.io/devedexa/signing-service-api:latest
          ports:
            - containerPort: 3000
          envFrom:
            - configMapRef:
                name: signing-env
          resources:
            limits:
              memory: "512Mi"
              cpu: "500m"
            requests:
              memory: "256Mi"
              cpu: "250m"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 30
          livenessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 30
            periodSeconds: 30
---
apiVersion: v1
kind: Service
metadata:
  name: signing-service
spec:
  selector:
    app: signing-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: ClusterIP

📜 Deployment Script: We also provide a helper shell script to simplify deployment.

deploy.sh

# Create or update the ConfigMap from .env
kubectl delete configmap signing-env --ignore-not-found
kubectl create configmap signing-env --from-env-file=.env

# Apply deployment & service configuration
kubectl apply -f deploy.yaml

▶️ Execute the Script

chmod +x deploy.sh
./deploy.sh

---

API Usage

Authentication

To access the Signing API, all requests must include an api_key, which is used to authenticate the request and authorize access to protected endpoints. This key is typically passed as a form field in API requests

Sign Document

post

Submit a document for signing. The request must include the document file and a valid API key.

Body

multipart/form-data

docstring · binaryRequired

The document file to sign.

api_keystringRequired

API key for authentication.

Responses

200

Document signed successfully

application/json

400

Bad request (file missing or too large)

application/json

401

Invalid or missing API key

application/json

409

Document already signed

application/json

post

/sign

HTTPcURLJavaScriptPython

POST /api/sign HTTP/1.1
Content-Type: multipart/form-data
Accept: */*
Content-Length: 33

{
  "doc": "binary",
  "api_key": "text"
}

{
  "message": "Document signed successfully",
  "tx_hash": "0xf108555e73a50ceb18f61c7f479e7b2f1b9cd529c61dfda057bd087ec8fc508b",
  "doc_hash": "0x83ae7c97f752cebd10121105d64189907b39888f2bc02291aa5a899ac5ca2c3d",
  "timestamp": "2025-08-18T04:29:37.348091086+00:00",
  "explorer_url": "https://explorer.testnet.edexa.network/tx/0xf108555e73a50ceb18f61c7f479e7b2f1b9cd529c61dfda057bd087ec8fc508b"
}

Verify Document

post

Verify whether a document has already been signed and recorded on the blockchain.

Body

multipart/form-data

docstring · binaryRequired

The document file to verify.

api_keystringRequired

API key for authentication.

Responses

200

Document verification successful

application/json

400

Document not signed or file missing

application/json

401

Invalid or missing API key

application/json

post

/verify

HTTPcURLJavaScriptPython

POST /api/verify HTTP/1.1
Content-Type: multipart/form-data
Accept: */*
Content-Length: 33

{
  "doc": "binary",
  "api_key": "text"
}

{
  "message": "Document is signed",
  "verified": true
}