DEV Community: Spubhi

Why HMAC Is the Right Choice for Webhook Security (and Why Spubhi Makes It Simple)

Spubhi — Mon, 05 Jan 2026 16:19:57 +0000

Webhooks are one of the most common integration patterns today. They’re also one of the easiest places to make security mistakes.

In this post, I’ll focus on why HMAC is a better approach for securing webhooks and how Spubhi keeps the implementation simple and predictable.

This is not a comparison-heavy or theory-heavy article — it’s about practical implementation and reliability.

The Core Problem with Webhook Security

A webhook endpoint is publicly accessible by design.
That means anyone can send a request to it unless you validate the sender.

The real challenge is not adding authentication, but ensuring that:

The request was not modified

The sender actually knows a shared secret

The validation works reliably across different clients and platforms

This is where many webhook implementations break down.

Why HMAC Works Well for Webhooks

HMAC (Hash-based Message Authentication Code) solves a very specific problem:
verifying both authenticity and integrity of a request.

When using HMAC:

The sender signs the raw request body using a shared secret

The receiver independently generates the same signature

If the signatures match, the request is trusted

No secrets are sent over the wire.
Only a signature is transmitted.

This has a few important implications:

1. No secret exposure

Unlike tokens or passwords, the shared secret is never transmitted in the request.

2. Payload integrity is guaranteed

If even one character in the request body changes, the signature validation fails.

3. Stateless validation

The server does not need to store sessions or tokens per request.
It only needs the shared secret and the incoming payload.

4. Language-agnostic

HMAC works the same way in Java, Node.js, Python, Go, or any other language.

This makes it ideal for webhook-based systems.

Common HMAC Implementation Pitfalls

Most HMAC failures don’t come from cryptography — they come from inconsistencies.

Some common issues:

Signing parsed JSON instead of the raw body

Different JSON serialization on sender and receiver

Header mismatches or late header injection

Async signing issues in tools like Postman

A reliable HMAC implementation must:

Use the exact raw request body

Normalize the payload consistently

Use a predictable header for the signature

Validate before any business logic executes

Why Spubhi Keeps HMAC Simple

Spubhi was designed with webhook security as a first-class concern.

Here’s what Spubhi does differently:

1. Raw body handling is explicit

Spubhi validates HMAC against the actual incoming payload, not a re-serialized version.

This avoids subtle mismatches that break signature verification.

2. Header-based authentication only

Spubhi expects the HMAC signature in a single, clear header:

X-SPUBHI-SECRET

No ambiguity. No hidden behavior.

3. No encoding or decoding of secrets

Secrets are treated as-is.
There’s no unnecessary base64 wrapping or transformation.

What you sign on the client is exactly what Spubhi verifies on the server.

4. Authentication happens before flow execution

If authentication fails, the request is rejected immediately.
No partial execution, no side effects.

This makes webhook behavior predictable and safe.

Minimal Client-Side HMAC Example

// Normalize JSON exactly like your current logic
const body = JSON.stringify(JSON.parse(pm.request.body.raw));

// HMAC secret
const secret = "hmac_Qv33h2Yp7SpLwl7mQ8geU7R8SrfRZ27BpX5j0tHM";

// Encode inputs
const encoder = new TextEncoder();
const keyData = encoder.encode(secret);
const bodyData = encoder.encode(body);

// Generate HMAC-SHA-256
crypto.subtle.importKey(
  "raw",
  keyData,
  { name: "HMAC", hash: "SHA-512" },
  false,
  ["sign"]
).then(key => {
  return crypto.subtle.sign("HMAC", key, bodyData);
}).then(signature => {
  const hmac = Array.from(new Uint8Array(signature))
    .map(b => b.toString(16).padStart(2, "0"))
    .join("");

  // SAME header name you already use
  pm.request.headers.upsert({
    key: "X-SPUBHI-SECRET",
    value: hmac
  });
});

That’s it.

No SDKs.
No custom formats.
No hidden transformations.
**
Minimal Server-Side Validation Logic**

On the server:

Read the raw request body
Generate HMAC using the same secret
Compare it with the incoming header
Reject if it doesn’t match

Simple logic — easy to audit, easy to debug.

Final Thoughts

Webhook security doesn’t need to be complex — it needs to be correct and consistent.

HMAC works well because it:

Protects payload integrity

Avoids secret exposure

Scales without state

Works across platforms

Spubhi keeps this model simple by:

Avoiding magic

Enforcing clear boundaries

Treating authentication as a first step, not an afterthought

If you’re building webhook-driven integrations, HMAC done right is enough — and simplicity is what makes it reliable.

webhooks

apissecurity

hmac

backend

integration

How Easy It Is to Convert Complex JSON to JSON in Spubhi

Spubhi — Sat, 03 Jan 2026 13:02:02 +0000

Most integration work isn’t about calling APIs.
It’s about reshaping data.

Different systems send JSON in different formats, and almost every integration needs:

Renaming fields
Aggregating values
Handling missing data
Producing a clean, predictable output

In this post, I’ll show how complex JSON → JSON transformation can be done cleanly in Spubhi, without loops, glue code, or custom scripts.

The Problem: Real JSON Is Never Flat

Let’s start with a realistic payload received via a webhook:

{
  "invoiceId": "INV-101",
  "customer": {
    "name": {
      "first": "Ravi",
      "last": "Sharma"
    }
  },
  "items": [
    { "name": "Laptop", "price": 50000.258 },
    { "name": "Mouse", "price": 800.756 }
  ]
}

What downstream systems usually want is something simpler:


{
  "invoiceId": "INV-101",
  "customerName": "Ravi Sharma",
  "itemCount": 2,
  "totalAmount": 50801.014
}

This requires:

Navigating nested fields
Combining values
Aggregating arrays
Preserving decimal precision

The Traditional Way (and Why It’s Painful)

In most platforms, this means:

Writing loops
Manually summing values
Handling nulls defensively
Worrying about floating-point precision

The transformation logic ends up scattered and hard to maintain.

The Spubhi Way: JSON-First Transformation

Spubhi treats everything as JSON internally, even if the input was XML or another format.

The transformation logic looks like this:

{
  "invoiceId": payload.invoiceId,
  "customerName": payload.customer.name.first + " " + payload.customer.name.last,
  "itemCount": sizeOf(payload.items),
  "totalAmount": sumBy(payload.items, "price")
}

That’s it.

No loops.
No glue code.
No precision loss.

Why This Works Well

1. JSON-First by Design

You always work with JSON, regardless of how the data came in.

2. Built-in Aggregation

Functions like sizeOf and sumBy are first-class, not hacks.

3. Decimal-Safe Calculations

Sums preserve natural decimal values instead of forcing rounding.

4. One Concept per Line

Each output field clearly shows:

Where data comes from

How it’s derived

Why This Matters

Integration code tends to live for years.
The simpler the transformation logic, the easier it is to:

Debug
Extend
Hand off to another developer

By keeping transformations declarative and JSON-focused, Spubhi reduces the mental overhead that usually comes with integration work.

Final Thoughts

Most integration platforms can transform JSON.
The difference is how much work you have to do to get there.

If your integrations involve:

Webhooks
Event-driven payloads
Aggregations
Complex JSON reshaping

A JSON-first approach makes a noticeable difference.

Why I Built My Own Self-Hosted Integration Runtime

Spubhi — Mon, 15 Dec 2025 12:55:03 +0000

Most integration tools I’ve used over the years were impressive on the surface—rich UIs, hundreds of connectors, and quick demos.

But once things moved closer to production, the problems started showing up.

The problem I kept running into

Tools like workflow automators and enterprise integration platforms usually break down in the same ways:

Execution-based pricing that grows unpredictably

Queues, retries, and error handling hidden behind abstractions

Self-hosting treated as a secondary option

Too much emphasis on UI, not enough on runtime behavior

These tools work well for demos.
They become painful when reliability and control actually matter.

What I actually needed

Instead of more UI, I wanted:

A runtime-first integration engine

Explicit control over queues, retries, and parallelism

Predictable costs by running on my own hardware

A simple way to define flows without locking myself into a SaaS

That’s what led me to build Spubhi.

What Spubhi is (and isn’t)

Spubhi is a self-hosted integration runtime, built with a few clear constraints.

What it does:

Executes JSON-defined flows

Supports API-triggered and queue-triggered executions

Uses a payload-based transformation DSL

Runs on Docker / VM / server

Focuses on reliability over visual design

What it doesn’t try to be:

Not a Zapier replacement

Not a no-code tool

Not a marketplace of connectors

It’s built for developers who want control, ownership, and transparency.

Lessons learned while building it

A few things surprised me while working on this:

Queues are harder than UI — but also more valuable

Retry logic becomes complex very quickly in real systems

“Easy” integrations hide painful failure modes

Simplicity at runtime matters more than feature count

Most of the real work wasn’t writing code—it was deciding what not to abstract away.

Why I’m writing this

I’m not launching anything here.
I’m sharing this because I want feedback from people who’ve dealt with integration systems in production.

If you’ve used tools like MuleSoft, n8n, WSO2, or homegrown scripts:

What part frustrated you the most?

Where did things break in real usage?

What would instantly make you reject a new integration tool?

I’m building this in the open and learning as I go.

Thanks for reading.