Pipes is one of those features people use for a week and never go back. Once you can call any REST API from inside the builder — and map the response into a real component — most "we need a custom integration for that" conversations go away.
What a Pipe actually is
A Pipe is a configured REST endpoint with named inputs and a mapped response. You build it once in the Pipes section — base URL, auth header, query/body params, the path to the data in the response — and then it shows up everywhere in the builder as a data source. Components can render it. Workflows can call it.
The three shapes Pipes solves for
- Read-only display — fetch and render external data (e.g., a Stripe customer's recent charges on their portal page).
- Two-way sync — write data to an external system from a workflow (e.g., create a HubSpot deal when a Tadabase project moves to Won).
- Lookups — call an enrichment API mid-form (e.g., autofill an address from a postcode).
Auth, the honest way
Static API keys go in the Pipe configuration. OAuth flows belong outside the builder — use a small middleware (a Vibe project or any Node host) to do the OAuth dance and expose a clean API to Tadabase. This keeps secrets out of your app config and refresh-token logic out of the Pipe.
Plan for the API to be slow
External APIs are slow. Two patterns help:
- Cache the result — store the fetched data on a Tadabase record and refresh on a schedule, not on every page load.
- Render incrementally — load the Tadabase-native components first, then the Pipe-backed components below, so a slow API does not block the whole page.
When to graduate to a real backend
Pipes are great for one API at a time. If you find yourself chaining four together to compute one value, write that logic in a small server (a Vibe project is the path of least resistance) and expose it as a single Pipe-friendly endpoint. Keep the builder talking to one clean endpoint, not five raw ones.