> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senderz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Core concepts

> The data model and pipeline behind Senderz: workspaces, contacts, segments, campaigns, flows and the send pipeline.

Understanding six objects explains almost everything in Senderz.

## The objects

<CardGroup cols={2}>
  <Card title="Workspace" icon="building">
    Your tenant. Every contact, campaign, domain and integration belongs to
    exactly one workspace. A user can belong to several.
  </Card>

  <Card title="Contact" icon="user">
    A recipient. Carries identity, consent per channel, tags, custom
    properties and predictive scores.
  </Card>

  <Card title="Segment" icon="filter">
    A live filter over contacts. Dynamic segments re-evaluate on read;
    static segments are a fixed membership list.
  </Card>

  <Card title="Campaign" icon="paper-plane">
    A one-off send to a segment on a single channel — email, SMS or push.
  </Card>

  <Card title="Flow" icon="bolt">
    A triggered automation. Reacts to events forever with wait timers,
    branches and multi-channel steps.
  </Card>

  <Card title="Template" icon="file-lines">
    Reusable content. Email blocks, raw HTML, SMS text or a push
    notification.
  </Card>
</CardGroup>

## Public vs internal IDs

Your **Workspace ID** — the value you send as `X-Sender-Tenant` — is the workspace **slug** (a short, human-readable string), not the internal UUID. The API accepts either the slug or the UUID, but the slug is what the UI shows and copies.

<Note>
  Internal foreign keys, JWTs and row-level security use the UUID. You only
  ever handle the slug.
</Note>

## The send pipeline

Every message — campaign, flow, test or transactional — flows through the same gates in the same order. This is why a bug in a builder can't produce a non-compliant send: enforcement lives at the worker, not the UI.

<Steps>
  <Step title="Suppression">
    Hard bounces, complaints and unsubscribes suppress a contact within
    seconds. Suppressed recipients are dropped first. Push suppression is
    per-browser-endpoint.
  </Step>

  <Step title="Consent">
    The recipient must have recorded opt-in for that channel. Source, IP,
    timestamp and channel are logged on every consent change.
  </Step>

  <Step title="Frequency caps & quiet hours">
    Per-contact caps shared across channels. Marketing SMS, voice and push
    to Israeli numbers respect quiet hours and Shabbat. Email is exempt from
    the legal block.
  </Step>

  <Step title="SMS wallet (SMS only)">
    No tenant SMS reaches a carrier without a wallet authorisation. Push and
    email have no per-message carrier cost, so no wallet step.
  </Step>

  <Step title="DKIM signing (email only)">
    Signed at the worker using a per-tenant key held in AWS KMS. The private
    key never leaves KMS.
  </Step>

  <Step title="Provider dispatch">
    Email routes through a failover provider chain; SMS through Israeli
    carriers; push through Web Push (VAPID); voice through the carrier TTS.
  </Step>
</Steps>

## Channels at a glance

| Channel  | Marketing | Transactional           | Quiet-hours block         | Wallet |
| -------- | --------- | ----------------------- | ------------------------- | ------ |
| Email    | Yes       | Yes                     | Exempt (product decision) | No     |
| SMS      | Yes       | Yes (OTP/transactional) | Yes (Israeli marketing)   | Yes    |
| Web push | Yes       | —                       | Yes (Israeli marketing)   | No     |
| Voice    | Flow node | OTP                     | Yes (Israeli marketing)   | Yes    |

## Consent states

Every channel on a contact carries one of four states:

<ParamField path="subscribed">Opted in — can receive marketing on this channel.</ParamField>
<ParamField path="unsubscribed">Opted out — marketing is blocked; transactional/OTP still allowed.</ParamField>
<ParamField path="never_subscribed">No opt-in ever recorded — the conservative default on import.</ParamField>
<ParamField path="cleaned">Removed by hygiene (e.g. repeated bounces).</ParamField>

## Marketing vs transactional

Transactional mail — order confirmations, password resets, OTP codes — flows through a **separate path** that bypasses frequency caps and quiet hours. This separation is at the message-type level, not the campaign level. Marketing sends always carry tracking, unsubscribe headers and (where applicable) the SMS wallet debit; transactional sends never do.

<Warning>
  Don't try to send marketing content through the transactional API to skip
  quiet hours or consent. The compliance gates exist to protect your
  reputation and keep the platform's shared carrier accounts in good
  standing.
</Warning>

## Where to go next

<CardGroup cols={2}>
  <Card title="Workspaces & team" icon="users" href="/en/getting-started/workspaces">
    Roles, multiple workspaces and switching.
  </Card>

  <Card title="Contacts" icon="address-book" href="/en/audience/contacts">
    The contact model in depth.
  </Card>
</CardGroup>