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 Third-Party 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["Third-Party Model A"] G --> D2["Third-Party 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.
Third-Party Model
The shape your destination expects. One Golden Model can fan out to many third-party 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 Third-Party 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 Third-Party Model.