Next project2025–2026
Turquoise Dream
Connecting dive discovery, booking and diver preparation with the operation behind them.
Messaging infrastructure / 2026 — ongoing
WapKit
Building WhatsApp infrastructure once, so every product doesn't have to
Kode Pundit was repeatedly building products that needed WhatsApp — booking tools, commerce experiences and internal applications. WapKit was created as a reusable messaging infrastructure layer so those products could integrate with WhatsApp through one consistent system instead of rebuilding the same provider logic, security and reliability work each time.
- Industry
- Messaging Infrastructure / Business Software
- Engagement
- Internal product development
Product Strategy · API Design · Messaging Infrastructure · Automation · Systems Engineering
Messaging architecture · conceptual illustration
ApplicationsWapKit.WhatsApp
providers
providers
One messaging layer.
Across products.
Context
WhatsApp was becoming infrastructure, not a feature
As Kode Pundit built more software around bookings, commerce and operational workflows, the same requirement kept appearing: the product needed to communicate with customers through WhatsApp.
But adding WhatsApp was rarely just a matter of sending a message.
Each implementation also needed to deal with credentials, incoming events, delivery states, duplicate callbacks, templates, retries and enough operational history to understand what happened when something failed.
Rebuilding that foundation product by product meant duplicating work — and creating another place for subtle messaging failures to appear.
WapKit was created to move that responsibility out of individual applications and into one reusable infrastructure layer.
Challenge
The difficult part wasn't sending the message
Sending a request to a messaging provider is relatively straightforward.
Building a system that can be trusted around that request is different.
A provider may send the same callback more than once. Status events may arrive later than expected. Credentials need to remain protected. Failed downstream webhooks need controlled retries. And when something behaves unexpectedly, there needs to be enough history to understand why.
There was another complication: businesses may connect to WhatsApp in different ways. Some integrations can sit behind third-party providers, while others can connect through Meta Cloud API. Credentials, onboarding, webhooks and failure modes can differ between those paths.
The real problem was not how to send WhatsApp messages. It was how to make WhatsApp a dependable, reusable capability across different products and providers.
Approach
Keep business logic in the product. Centralize WhatsApp infrastructure.
WapKit was deliberately designed as a boundary.
The consuming application still decides what should happen: who needs a reminder, what a booking means, when a workflow should run or which customer action matters.
WapKit handles the messaging infrastructure underneath it: project authentication, WhatsApp connections, sending, templates, message state, provider events and operational history.
That separation also shaped the API.
Applications express intent — for example, send a particular template to a particular phone number with these variables — rather than constructing provider-specific payloads themselves.
Provider complexity stays inside WapKit instead of leaking into every product that uses it.
Applications express intent. WapKit handles the provider boundary.
01Business application
02WapKit
WhatsApp provider
Meta Cloud API
Normalized events & message history
Messaging Experience
Multiple providers, one contract
WapKit places different WhatsApp connection paths behind a common provider boundary, including support designed around Meta Cloud API.
The consuming application does not need a separate messaging implementation depending on which provider sits underneath. It talks to WapKit, while WapKit handles provider-specific credentials, requests, callbacks and behaviour.
That separation also creates a path toward businesses connecting their own WhatsApp infrastructure through Meta without requiring downstream products to be rewritten around the change.
Why it matters
Provider choice becomes an infrastructure decision rather than something embedded throughout the business application.
Reliability around every send
A successful provider request is only the beginning of a message's lifecycle.
WapKit was built with idempotent sending, webhook deduplication and ordered message-state handling so repeated or late provider events cannot silently corrupt the application's understanding of what happened.
Credentials are treated similarly: sensitive connection credentials remain protected rather than becoming ordinary application data, while project API keys establish boundaries between consuming applications.
The goal is a stronger guarantee than simply:
"The API request succeeded."
The system also needs to know which message it represented, how its state changed and whether anything unusual happened afterwards.
Automation that can be inspected
WapKit includes deterministic automation for messaging workflows rather than making reliable messaging dependent on AI.
Rules can respond to incoming activity using ordered matching and per-contact state, while a tester can exercise the real rule engine without actually sending messages. The same operational layer keeps messages and provider events inspectable when behaviour needs to be traced.
Why it matters
Automation is considerably easier to trust when its behaviour can be reproduced and inspected instead of existing as an opaque background process.
Beyond the Interface
The product is mostly what the customer never sees
WapKit has an operational console, but the interface is not the core product.
Underneath it sits project-scoped authentication, provider abstraction, credential handling, message normalization, webhook processing, contact and template management, automation and an operational event trail.
A consuming application can take a project API key, request a text or approved-template send through WapKit's API, and receive normalized events without understanding the provider implementation underneath.
Build the complicated messaging plumbing once, then let each application concentrate on the business problem it exists to solve.
That is the role WapKit was designed to play.
Details That Mattered
Project isolation
Every application operates within its own project boundary. Authentication resolves the project from its API key rather than allowing a caller to choose another project's identity.
Credentials are not ordinary data
Project API keys are designed to be revealed once and stored as hashes, while messaging credentials remain server-side and protected from logs or consuming applications.
Providers stay behind the boundary
Provider-specific credentials, payloads and webhook behaviour are translated into WapKit's own messaging concepts before they reach consuming applications.
This allows the application-facing contract to remain stable even as the underlying WhatsApp connection changes.
Operations remain inspectable
Messages, statuses, errors and provider activity remain available for debugging rather than disappearing behind a successful or failed API response.
Public examples stay separate from customer data
Public-facing product imagery uses authored fixtures rather than operational customer information. Tests were added to prevent real identities, phone numbers or secrets from reaching those public surfaces.
Result
One messaging layer instead of repeated WhatsApp plumbing
Before WapKit, adding WhatsApp to another product meant solving many of the same infrastructure problems again.
With WapKit, the intended integration becomes much smaller:
Create project → Connect WhatsApp → Create API key → Configure templates → Call WapKit API
The core messaging path has also been exercised with real WhatsApp traffic: an inbound message matched a rule, triggered an automated response, and progressed through provider callbacks to a recorded read state.
The direct Meta onboarding path is built but should not yet be presented as production-proven for external businesses. App publication remains a dependency before that path can be validated in that environment.
There are no adoption, revenue or customer-satisfaction figures being claimed at this stage.
The next meaningful proof point is repeated use across real applications and businesses.
What We Delivered
- Product Strategy
- WhatsApp Messaging Infrastructure
- Provider-independent Messaging Layer
- Project-scoped API
- Meta Cloud API Integration
- Embedded Signup Architecture
- Webhook Processing & Normalization
- Deterministic Messaging Automation
- Message & Delivery Tracking
- Credential & API-key Security
- Operational Console & Debugging Tools
Takeaway
WapKit demonstrates a type of work that often sits behind the visible product.
The starting request might sound simple — "this application needs WhatsApp" — but the durable solution was to identify the infrastructure that would otherwise be rebuilt repeatedly and give it a clear boundary of its own.
That is the broader approach behind Kode Pundit's custom software work: understand which parts of a problem belong to existing platforms, which belong to the business itself, and build the missing layer between them.
Building a product that needs to connect with the rest of your business?
The useful software is often not another standalone dashboard. It is the layer that makes the systems, workflows and customer touchpoints you already depend on work together.
Discuss your project