@vorluno/niiko-sdk
Generated client for the niiko actions API — it exposes verbs, not rows.
158downloads / month
project · open source
niiko
The actions API that exposes verbs, not rows — and every client generated from the same plan.
Two SDKs (TypeScript and Python), a CLI, an n8n node and a remote MCP server, all generated from one plan: when an action opens, every client knows it the same day. Refusals come back as data you can act on.
- packages
- 4
- repos
- 7
- downloads / month
- 936
- stars
- 5
Packages
niiko-cli
The niiko actions API from the terminal. Generated from the same plan as the SDKs.
313downloads / month
n8n-nodes-niiko
The niiko node for n8n: every action open to the outside, as an operation. English and Spanish. Generated from the same plan as the SDKs.
325downloads / month
niiko
Generated client for the niiko actions API — it exposes verbs, not rows.
140downloads / month
Repositories
n8n-nodes-niiko
The niiko node for n8n — every public action as an operation, refusals as data, usable as an AI Agent tool. English and Spanish.
niiko-cli
The niiko actions API from the terminal — four commands, JSON output, the outcome in the exit code. Generated from the action manifest.
niiko-mcp-server
The remote MCP server of niiko — connect Claude or any OAuth-capable MCP client and every action you grant becomes a tool.
niiko-sdk-python
The Python client for the niiko actions API — one typed method per action, three outcomes, zero dependencies. Generated from the action manifest.
niiko-sdk-typescript
The TypeScript client for the niiko actions API — one typed method per action, three outcomes, zero dependencies. Generated from the action manifest.
niiko-cookbook
Integration recipes you copy and run. Each one is a single file, and every one runs with no credentials and no network.
niiko-events
The event catalog of niiko: every event defined once, with its payload schema. Generated, read-only.
Docs · README of niiko-cookbook
Integration recipes you copy and run. Each one is a single file that does one thing, and every one of them runs with no credentials and no network.
git clone https://github.com/vorluno/niiko-cookbook.git
cd niiko-cookbook && bun install
bun run recipes # all four, in order
Each recipe prints what it does as it does it. Read the output next to the file and the point should be obvious; if it is not, that is a defect in the recipe and worth telling us about.
The recipes
| What you get out of it | |
|---|---|
| 01 · Verify a WhatsApp webhook | The signature check, and the four cases that matter — including the two that quietly stop a check from checking: no header, and no secret configured. Both answer false. |
| 02 · Onboard a number | Embedded Signup end to end against a stand-in for Meta: four calls, in the only order that works, with every request printed. The order is the part people get wrong. |
| 03 · A cap in its own unit | Why a cap in dollars on something measured in percent and days is not a weak cap but an uncomparable one — and how that makes an action ask for permission forever without ever erroring. |
| 04 · Propose and sign | The approval loop that is worth having: freeze the input, re-check the world at execution, and refuse with a name the caller can act on. |
How these are written
They run. Not "should run" — every recipe in this repository was executed before it was published, and its output is what you will see. A recipe that does not run teaches the wrong thing twice: once about the subject and once about whether to trust anything else here.
No credentials. Recipe 01 signs its own payload the way Meta signs one. Recipe 02 talks to a stand-in that
answers what the Graph API answers — and that stand-in is not scaffolding we added for the demo: every
function in whatsapp-cloud-client takes an injectable fetch, which is how its own tests run. Swap it for
the real one and the same code talks to Meta.
They say what they do not cover. Recipe 04 hands you the loop and tells you plainly which four pieces are yours to build, and why a library that guessed them would be wrong in a way you could not fix.
The packages behind them
- whatsapp-cloud-client — a typed WhatsApp Cloud API client: signature verification in constant time, a tolerant webhook parser, and error classification that knows which failures are worth retrying.
- @vorluno/ratchet — per-capability autonomy for AI agents: caps in their own unit, and refusals you can act on.
Both are extracted from niiko, where they run against live customer conversations.
Contributing
A recipe that stopped working is the most valuable thing you can report here — more than anywhere else, because a broken demonstration teaches the wrong thing. Open an issue and say what you ran and what happened.
New recipes are a conversation first: the bar is that a recipe must run with no credentials and teach one thing. See CONTRIBUTING.md.
Vulnerabilities go to security@vorluno.dev, never to an issue — see SECURITY.md.
License
Apache-2.0 — see LICENSE. These are meant to be copied: that is what the licence is for and why this repository is not a package.
Built by Vorluno — a software studio from Panamá.