What is a Destination Model in Slashbin?

A Destination Model is the exact payload shape one specific destination expects. It is derived from the Golden Model through field mapping — renaming, restructuring, dropping, or computing fields so the outbound payload matches what the destination requires.

Why have a Destination Model separate from the Golden Model?

The Golden Model is source-shaped and stable; the Destination Model is target-shaped and changes whenever the destination changes. Separating them means a vendor rename on the inbound side never forces you to rewrite every outbound mapping, and a destination API change never leaks into the canonical schema.

Can one Golden Model feed multiple Destination Models?

Yes — that is the whole point. A single Golden Model can fan out to as many Destination Models as you need: one for your CRM, one for your warehouse, one for analytics. Each Destination Model has its own mapping, its own filters, and its own retry behavior.

What happens when a destination changes its API?

You update only that one Destination Model — its field mapping, its required fields, or its payload structure. The Golden Model, every other Destination Model, and every other inbound source stay untouched.

How is a Destination Model different from a destination connector?

The Destination Model is the schema and field mapping — what the payload looks like. The destination connector is the transport — where it gets sent and how it authenticates. You can swap connector configurations (URL, auth method, headers) without rewriting the Destination Model.

Destination Model

A Destination Model is the exact payload shape one specific destination expects, derived from your Golden Model through field mapping. It is target-shaped, not source-shaped — its field names, casing, structure, and constraints match what the destination's API demands. One Golden Model can power many Destination Models, each tailored to a different system.

Why use a Destination Model?

The Golden Model captures what your business cares about. The Destination Model captures what one specific system on the other end expects. Those are different concerns, and conflating them creates two recurring problems:

Destination changes pollute your canonical schema. Klaviyo wants $email with a dollar prefix. Your warehouse expects customer.email nested. Your analytics tool wants flat customer_email. If you bake that into the Golden Model, you get a Frankenstein schema that serves nobody.
One destination's quirks break every other delivery. When the destination team renames a field, you have to touch the Golden Model, which touches every other Destination Model that derives from it.

Splitting them isolates the blast radius. The Golden Model defines what the business owns. Each Destination Model handles one system's quirks — renaming, restructuring, casting, dropping — without touching anything else.

How it works

Each Destination Model declares its own field mapping against the Golden Model. The mapping can rename fields, restructure objects, compute derived values (concatenations, conditional flags, formatted dates), and drop fields the destination does not need.

graph LR
  G["Golden Model\n(canonical, source-shaped)"] -->|map| DM1["Destination Model\n(Klaviyo profile)"]
  G -->|map| DM2["Destination Model\n(Warehouse order)"]
  G -->|map| DM3["Destination Model\n(Analytics event)"]
  DM1 --> D1["Klaviyo"]
  DM2 --> D2["Warehouse API"]
  DM3 --> D3["Analytics"]
  style G fill:#a855f7,color:#fff
  style DM1 fill:#7c3aed,color:#fff
  style DM2 fill:#7c3aed,color:#fff
  style DM3 fill:#7c3aed,color:#fff

When a webhook arrives, it's validated against the Golden Model first. Each Destination Model then runs its own mapping against the validated record to produce its destination-shaped payload. Filters can drop the delivery for any destination (e.g., "only send subscription orders to the CRM") without affecting the others.

Example

Consider a slashbin customer's quiz-response → email-platform pipeline. The Golden Model is a 16-field QuizResponse: respondent identifiers, answer payload, timestamps, source attribution, and a few derived classification flags.

The Destination Model for Klaviyo is a 22-field profile shape:

$email, $first_name, $last_name (Klaviyo's dollar-prefixed reserved attributes)
quiz_segment_v2 (a computed segment string derived from three Golden Model fields)
last_quiz_completed_at (Golden Model submitted_at, reformatted to Klaviyo's expected ISO-8601 with milliseconds)
A handful of properties.* keys that namespace custom attributes the way Klaviyo expects

The Golden Model has 16 fields. The Destination Model has 22. The extra six come from mapping logic: derived classifications, reformatted timestamps, and Klaviyo-specific reserved attributes. If the customer adds a Postgres warehouse destination tomorrow, they author a new Destination Model — the Golden Model stays exactly the same.

Related concepts

Golden Model — the canonical, source-shaped schema every Destination Model derives from.
Fan-out Routing — how one Golden Model fans out to many Destination Models, each delivering independently.
Getting Started — a 15-minute walkthrough covering Golden Model and Destination Model setup.

Golden Model Fan-out Routing