Embedded analytics
Give your customers their own analytics.
Embedded analytics, in practice, means your product surfaces data your customers care about — usage, spend, account activity — scoped to them, inside their own view. Fastero gives you three ways to build that: a REST API for saved queries, hosted Streamlit apps with authentication, and scheduled PDF/email reports. No embed SDK, no iframe theming, no drag-and-drop builder to maintain.
Three ways to embed
Pick the surface that matches how your customers want the data.
These are not mutually exclusive. A common pattern is an API endpoint for your product's main UI, a Streamlit app for power users who want to explore, and a scheduled report for everyone else who just wants the number in their inbox.
Expose saved queries as REST endpoints
Save a query once, publish it as a versioned REST endpoint, and call it from your own frontend. You own the UI entirely — Fastero just returns JSON. Endpoints support query parameters, pagination, and the same auth model as everything else: a scoped JWT per caller.
- GET/POST endpoints backed by saved SQL or Python queries
- Parameterized filters (date range, customer_id, status) passed at call time
- Response caching with configurable TTL for high-traffic endpoints
Hosted, authenticated, interactive dashboards
When your customers need to filter, drill down, or explore — not just read a number — publish a Streamlit app instead of an API. Fastero hosts it, handles auth at the app boundary, and lets you generate shareable links scoped to a specific customer or workspace.
- Auth-gated URLs — no anonymous access unless you explicitly allow it
- Matplotlib and Plotly charts render natively as embeddable components
- Share a link or drop the app in an iframe inside your own product shell
Automated PDF and email delivery
Not every customer wants to log into a dashboard. Attach a delivery schedule to any saved query or app and Fastero renders it to PDF and emails it on a cron — daily usage summaries, weekly account reports, monthly billing recaps.
- Cron-based scheduling with per-recipient customer scoping
- PDF rendering of charts and tables, not a raw data dump
- Delivery logs so you can see what was sent and when
How row-level security works
Parameterized queries and JWT claims. No data leakage between customers.
The same saved query serves every customer. What changes per request is a bound parameter — never a string the caller controls.
Parameterized queries, not string concatenation
Every saved query that powers an API endpoint or app is parameterized — filters like customer_id are bound values, not interpolated strings. There is no path for one customer’s API call to accidentally return another customer’s rows through a malformed filter.
JWT claims carry the scope
When you generate an access token for an end user, you set claims on it — customer_id, org_id, role. Fastero reads those claims at request time and binds them into the query’s parameters automatically. The caller cannot override the claim from the request itself.
Enforced server-side, not in the client
Row-level filtering happens when the query executes against your warehouse, not in a client-side filter that a curious user could bypass with dev tools. The unfiltered result set never leaves the server.
Short-lived, revocable tokens
End-user JWTs are short-lived and can be revoked per customer or per token. If a customer’s access needs to be cut off — churn, security incident — revoke the token and every embedded endpoint and app URL tied to it stops resolving.
Example
Saved query: SELECT * FROM invoices WHERE customer_id = :customer_id AND status = :status. A token issued for Customer A carries the claim customer_id: "cust_a1b2". Fastero binds that claim into :customer_id before execution. The request cannot pass a different value for that parameter — the claim wins every time.
Honest scope
When Fastero fits vs when it doesn't.
If "embedded analytics" in your spec means a white-labeled, drag-and-drop dashboard builder your customers configure themselves, Fastero is not that product. It is for dev teams who want to expose data via API or a lightweight hosted app without building or licensing a chart-builder UI.
Fastero fits when...
- Your dev team wants to expose data via API and build the UI themselves
- A lightweight, authenticated app (Streamlit) covers the interactivity your customers need
- Automated PDF/email delivery is an acceptable (or preferred) format for some customers
- Row-level security by customer_id or org_id is enough tenant isolation for your model
- You want this shipped in days, not a multi-month embed integration
Fastero is not for you when...
- End users need to drag-and-drop build their own dashboards — that is Luzmo or Sisense territory
- You need a fully white-labeled, no-code chart builder your customers configure themselves
- Your tenancy model requires deep UI-level theming per customer beyond colors and logos
- You need an embed SDK with a component library for a custom frontend framework
- Analytics is the entire product, not a feature inside a larger one
FAQ
Frequently asked questions.
What does "embedded analytics" mean with Fastero specifically?
It means exposing data from your Fastero-connected warehouse to your own customers, scoped to each one, through one of three surfaces: a REST API you call from your own frontend, a hosted Streamlit app with authenticated URLs, or a scheduled PDF/email report. There is no chart-builder SDK to embed — you either consume the API yourself or use the hosted app as-is.
Is there a drag-and-drop dashboard builder my customers can use?
No. Fastero does not have a white-labeled, no-code dashboard builder for end users. If that is the requirement — customers configuring their own charts inside your product — look at Luzmo, Sisense, or Qrvey instead. Fastero is for dev teams who want to expose data programmatically or via a lightweight hosted app, not build a visual editor.
How does row-level security actually prevent one customer from seeing another’s data?
The saved query behind an API endpoint or app is parameterized with a filter like customer_id = :customer_id. When you issue a JWT for an end user, you set customer_id as a claim on that token. Fastero reads the claim server-side and binds it into the query parameter automatically — the caller has no way to pass a different customer_id and get someone else’s rows, because the filter value never comes from the request itself.
Can I use my own authentication system instead of Fastero’s JWTs?
Yes. The JWT approach is designed to sit downstream of whatever auth you already run. Your backend authenticates the user however it normally does, then mints a scoped Fastero token with the right claims (customer_id, org_id, role) before handing back the API URL or app link. Fastero trusts the claims on the token, not a separate login flow.
What happens if I need heavier customization later — can I migrate off Fastero?
Because the API returns plain JSON and the underlying logic is a saved SQL or Python query, there is no proprietary embed format to unwind. If you outgrow the hosted Streamlit app and need a fully custom frontend, you keep calling the same REST endpoints and just build your own UI on top — the API layer does not require a rip-and-replace.
Related pages
Embedded analytics API solution
Publish APIs from saved queries with access controls and webhooks
Best embedded analytics platforms
Honest comparison across Metabase, Luzmo, Sisense, GoodData, and more
Metabase vs Luzmo for embedded analytics
Open-source iframe embedding vs purpose-built white-label embed
API and webhooks
HMAC-signed webhooks, IP allowlists, and the REST API underneath
Hosted apps
Deploy Streamlit apps with auth, scheduling, and custom branding
NL2SQL
The saved queries behind every embedded API endpoint start here
Ship customer-facing analytics without an embed SDK.
Publish a query as an API, host an authenticated Streamlit app, or schedule a PDF report — all with row-level security by default. Free to start, no credit card required.