Docs

Client Code

Havala publishes no client packages, so these are recipes rather than SDKs: a complete signed-request client in each language โ€” create an invoice, verify a webhook โ€” meant to be pasted into your codebase and owned by you.

Node.js

No dependencies โ€” node:crypto and fetch are built in on Node 18+

Read the recipe
Python

pip install requests # hmac and hashlib are standard library

Read the recipe
PHP

No dependencies โ€” hash_hmac and cURL ship with PHP 8

Read the recipe
Go

No dependencies โ€” crypto/hmac and net/http are standard library

Read the recipe
Java

No dependencies โ€” javax.crypto.Mac and java.net.http on JDK 17+

Read the recipe
.NET

No dependencies โ€” System.Security.Cryptography on .NET 8+

Read the recipe

What each recipe covers

The whole canonical string

Timestamp, method, path, body hash โ€” and the idempotency line that only POST, PUT, PATCH and DELETE carry. Getting that line wrong is the most common reason a first request comes back SIGNATURE_INVALID.

Nothing to depend on

There is no package to pin, audit or wait on for a release. The recipe is a few dozen lines you can read end to end and change when your stack does.

Standard library first

Most of these add nothing to your lockfile: node:crypto, hmac and hashlib, hash_hmac, crypto/hmac, javax.crypto.Mac. Only Python's recipe pulls a dependency, and only for the HTTP call.

Webhook verification included

Each recipe also verifies X-Webhook-Signature against the raw request body, before any parsing that would reorder it. That half of the integration is what actually protects you.