What is a Third-Party Model in Slashbin?

A Third-Party 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 Third-Party Model separate from the Golden Model?

The Golden Model is source-shaped and stable; the Third-Party 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 Third-Party Models?

Yes — that is the whole point. A single Golden Model can fan out to as many Third-Party Models as you need: one for your CRM, one for your warehouse, one for analytics. Each Third-Party 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 Third-Party Model — its field mapping, its required fields, or its payload structure. The Golden Model, every other Third-Party Model, and every other inbound source stay untouched.

How is a Third-Party Model different from a destination connector?

The Third-Party 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 Third-Party Model.

Third-Party Model

A Third-Party 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 Third-Party Models, each tailored to a different system.

Why use a Third-Party Model?

The Golden Model captures what your business cares about. The Third-Party 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 Third-Party Model that derives from it.

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

How it works

Each Third-Party 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["Third-Party Model\n(Klaviyo profile)"]
  G -->|map| DM2["Third-Party Model\n(Warehouse order)"]
  G -->|map| DM3["Third-Party 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 Third-Party 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 Third-Party 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 Third-Party 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 Third-Party Model — the Golden Model stays exactly the same.

Related concepts

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

Golden Model Fan-out Routing