Slashbin Concepts
Every Slashbin pipeline is the same four things in a row: a Source sends a raw webhook, you reshape it into a Golden Model, you map that into a Destination Model per destination, and Fan-out Routing delivers it to one or many destinations. Learn these four nouns and the rest of the product is just configuration.
graph LR S["Source (Shopify, Stripe, custom)"] --> G["Golden Model"] G --> D1["Destination Model A"] G --> D2["Destination Model B"] D1 --> O1["Destination A"] D2 --> O2["Destination B"] G -.->|fan-out| D1 G -.->|fan-out| D2 style G fill:#a855f7,color:#fff style D1 fill:#7c3aed,color:#fff style D2 fill:#7c3aed,color:#fff
Start here
Golden Model
The canonical schema you keep. Defined once, validated on every webhook, owned by you — not the vendor.
Destination Model
The shape your destination expects. One Golden Model can fan out to many destination models with field mapping.
Fan-out Routing
One inbound webhook, many destinations. Independent filters, retries, and dead-letter handling per destination.
Why a hub-and-spoke pipeline?
Most webhook pain comes from coupling: your downstream code knows about the vendor's payload shape. When the vendor changes a field name or adds a hundred more fields, your code breaks. Slashbin breaks that coupling in two places:
- At the Source boundary — the Golden Model is the only shape your business owns. The vendor can change anything else; your Golden Model is the contract.
- At each destination — each Destination Model is the shape that destination expects. The Golden Model never leaks vendor noise into your CRM, your warehouse, or your analytics.
Once you have those two boundaries, Fan-out Routing is straightforward: one webhook in, N destinations out, each with its own mapping and its own retry behavior.
Where to next?
- New to Slashbin? Start with Getting Started — a 15-minute walkthrough.
- Building your first integration? Try the Shopify recipe.
- Looking for the field-mapping deep dive? Read Destination Model.