Embedding Upliftr

Upliftr isn't only a product you use directly — it's an engine another platform can embed to give its own customers autonomous testing and, uniquely, root cause across the UI → server boundary: a failing user action resolved to the actual backend error via trace_id.

If you run a platform where customers ship web apps — a PaaS / app host, an internal developer platform, a DevOps suite — you can offer "test my app and tell me why it broke" without building any of it. You call one endpoint (or one tool); Upliftr does the rest, under your brand.

One core, three surfaces

Everything below wraps the same engine (generate → run → root-cause). Pick the surface that fits how you integrate:

Surface	For	Entry point
REST API	server-to-server / any language	POST /api/v1/analyze
MCP tool	agentic platforms (call it as a tool)	upliftr_root_cause over stdio or HTTP
Python SDK	import-and-go in Python	Upliftr(url, token).analyze(app)

All three return the same thing: root-caused bugs — each failing case with its backend cause, suspected fix, confidence, and trace_id.

The one call

curl -X POST https://YOUR-UPLIFTR/api/v1/analyze \
  -H "Authorization: Bearer tw_..." \
  -H "Content-Type: application/json" \
  -d '{ "app_url": "https://staging.customer-app.com" }'

Upliftr generates a suite for the app, runs it in a real browser, correlates any failure to the customer's server logs, and returns:

{
  "run_id": "run_...",
  "status": "done",
  "summary": { "passed": 5, "failed": 1, "broken": 0 },
  "cases": [
    {
      "title": "Checkout — pay with card",
      "status": "failed",
      "why": "500 on submit",
      "root_cause": {
        "category": "backend_exception",
        "suspected_cause": "NullPointerException computing tax for DE",
        "suggested_fix": "guard the null tax tier in PricingService",
        "confidence": 0.82,
        "trace_id": "4bf92f35...",
        "evidence": ["[ERROR] NPE at PricingService.tax(...)"]
      }
    }
  ],
  "issues": [ /* filed to the configured tracker */ ]
}

What makes it embeddable

• Multi-tenant by API token. Mint one tw_… token per customer org; every call is hard-isolated to that org. See Authentication.
• Bring-your-own everything, per request. A customer's Anthropic key and log backend can be passed inline (anthropic_key, log_backend) or set once per org — so you never centralize customer secrets.
• White-label. One env var rebrands every surface — filed tickets, reports, emails, API metadata — so it's your product, not "Upliftr".
• Self-hostable. Run the engine on your own infra (see Self-hosting); customer app pages and logs never leave your environment.

The differentiator to lead with

Other testing tools stop at the browser ("element not found"). Upliftr crosses into the app's running backend: it captures the failing request's trace_id, queries the customer's own logs (Loki / Datadog / Elasticsearch / …), and an LLM names the server-side cause and a fix. That "not a red X — the actual backend error" moment is the thing your customers can't get anywhere else. It works out of the box once the app emits a trace header — and if it doesn't, a drop-in snippet adds one.

Next

• The /analyze API contract — full request/response.
• Python SDK — import-and-go.
• White-labeling — make it yours.
• MCP tool — for agentic platforms.