Skip to content
k-msg

Package Selection

K-Message is modular. You do not need every package in every app. This guide maps common project shapes to the package set that usually fits best.

Default recommendation

Section titled “Default recommendation”

Most applications should start with:

  • k-msg
  • @k-msg/provider

That gives you the unified send facade plus built-in provider implementations.

Package roles

Section titled “Package roles”
PackageUse it whenTypical consumer
k-msgYou want the main send API and standard app wiringMost application teams
@k-msg/coreYou need low-level types, Result helpers, or custom provider workLibraries and advanced integrations
@k-msg/messagingYou need queueing, delivery tracking, or runtime adaptersBackground workers and infrastructure services
@k-msg/providerYou want built-in provider implementationsMost production apps
@k-msg/templateYou manage template parsing, interpolation, or validation directlyTemplate-heavy apps
@k-msg/channelYou need provider-aware channel lifecycle helpersProvider onboarding or admin tooling
@k-msg/webhookYou build webhook ingestion and delivery runtime flowsPlatform or backend services
@k-msg/analyticsYou aggregate tracking data into dashboards or reportsReporting pipelines

Common setups

Section titled “Common setups”

1. Simple application sending SMS or AlimTalk

Section titled “1. Simple application sending SMS or AlimTalk”

Install:

Terminal window
bun add k-msg @k-msg/provider

Choose this when:

  • your app sends messages directly
  • you do not need custom queue orchestration yet
  • you want the smallest learning surface

2. Application with custom queueing or delivery tracking

Section titled “2. Application with custom queueing or delivery tracking”

Install:

Terminal window
bun add k-msg @k-msg/provider @k-msg/messaging

Choose this when:

  • you want background processing
  • you need runtime adapters for Bun, Node, or Cloudflare
  • you persist delivery state outside the main request path

3. Platform team building provider-aware or reusable primitives

Section titled “3. Platform team building provider-aware or reusable primitives”

Install:

Terminal window
bun add @k-msg/core @k-msg/provider @k-msg/messaging

Choose this when:

  • you are building abstractions on top of K-Message
  • you need direct access to Result, error, or queue primitives
  • your app already has its own orchestration layer

4. Template-heavy Kakao workflows

Section titled “4. Template-heavy Kakao workflows”

Add @k-msg/template when:

  • you validate template payloads before sending
  • you run custom interpolation or button parsing
  • you manage template lifecycle outside provider dashboards

5. Webhook-heavy deployments

Section titled “5. Webhook-heavy deployments”

Add @k-msg/webhook when:

  • you need webhook endpoint registries
  • you want retry and persistence helpers around webhook delivery
  • you are deploying runtime webhook infrastructure, especially on Cloudflare

Runtime adapter note

Section titled “Runtime adapter note”

Some capabilities live behind runtime-specific subpaths. For example:

  • k-msg/adapters/bun
  • k-msg/adapters/node
  • k-msg/adapters/cloudflare
  • @k-msg/messaging/adapters/cloudflare

Pick these only when your runtime needs them.

Decision checklist

Section titled “Decision checklist”

Start with k-msg if all of these are true:

  • you are building an application, not a library
  • you want a stable top-level send API
  • built-in provider integrations are enough

Drop to lower-level packages if any of these are true:

  • you need your own provider implementation
  • you want to control queueing and tracking separately
  • you are composing a reusable platform layer for multiple apps

Next steps

Section titled “Next steps”