Select the carrier contract before defining SMS

SMS is a research route without a chosen carrier or communications provider, sender model, resource schema, method set, event contract, or commercial release plan.

Research surface only. The access contract and release decision remain open; no connector has been selected.

Talk to us ↗Read technical guides →

Capability boundary

No SMS provider surface is committed

The capability catalog intentionally leaves resources, methods, and events empty. A carrier or communications API contract must be selected before DewEngine can define authentication, sending, receipts, or pricing behavior.

Catalog status and access: SMS — research, undecided
Authentication: The future connection boundary depends on the selected provider and may involve customer-owned sender registrations, numbers, messaging services, or delegated project credentials; no model is chosen.
Resources: none declared while research remains open
Target actions: none declared while research remains open
Target events: none declared while research remains open
Limitations and failures: No carrier/provider contract or implementation; No declared send or delivery-receipt capability; Sender registration, consent, regions, encoding, throughput, and cost remain undecided
Release gates: SMS — Select a carrier or communications API contract before defining capability

Sender identity

Start with the number and registration owner

An SMS command cannot be designed safely until the product knows who owns the sender identity, which workspace may use it, and which registrations or regional rules apply. A generic connected account is not enough.

Consent

Keep opt-in and suppression in the calling product

The application needs a documented purpose, recipient permission, suppression state, and escalation path before asking a connector to send. Provider acceptance cannot substitute for those controls.

Message model

Account for encoding, segments, and media explicitly

Text length, character encoding, segmentation, and multimedia support affect cost and delivery behavior. These must be derived from the selected provider rather than copied from another messaging channel.

State

Separate submission, delivery evidence, and reply

A future command record should distinguish queued, provider-accepted, failed, and provider-reported delivery states. Replies and delivery receipts need their own events only when the carrier path supplies verifiable evidence.

Provider selection

Evaluate coverage, throughput, failures, and cost together

The go/no-go review should cover supported countries, sender types, registration, pacing, retries, number health, webhook authenticity, deletion, and a commercial model the customer can understand.

Research contract

Review the open integration boundary.

This shape records the questions DewEngine must resolve before selecting an access path. It is not callable, approved, or connected to a provider.

Explicit connected-account ownership
Stable public resource identifiers
Truthful provider outcome state
Release status beside every capability

Illustrative shapeResearch · not callable

const unreleasedContract = {
  resource: "message",
  account_id: "acc_example",
  provider: "target_provider",
  availability: "not_implemented"
} as const;

No selected connector · no provider request

Questions

Before you build.

Can DewEngine send SMS today?+

No. SMS has no selected provider, declared method, or connector implementation.

Will SMS use the same delivery states as chat messages?+

Not automatically. Only states backed by the selected carrier or provider contract should be normalized.

Build with us

Does this match the workflow your users need?

DewEngine is in development. Real use cases decide what ships first.

Share your use case ↗