Install the LopeBase Adapter

Mount the LopeBase Adapter at /api/lopebase to share your own app's users and numbers, watch the services it depends on, and keep it updated.

Updated 4 min read Open Properties

Every other connection reads a tool around your product. The LopeBase Adapter is the one piece that reads your own app: its users, its own dashboard numbers, and the services it depends on. It is a small handler you add at /api/lopebase, published as @lopebase/adapter, and it answers only with what you declare. LopeBase never touches your database directly.

Add it

  1. Copy the agent prompt

    On the property's page, the LopeBase Adapter card has a Copy agent prompt button. Paste it into your coding agent in that product's repo.

  2. Let your agent install it

    It adds @lopebase/adapter, declares the resources you want visible (users, subscriptions, whatever fits), and creates a signing secret. It runs on Cloudflare Workers, Node 18 and up, Vercel, Netlify, Deno, and Convex, with no dependencies.

  3. Deploy, then connect it

    After deploying, enter the adapter's URL (usually your site's address followed by /api/lopebase) and the signing secret on the property's page. LopeBase tests it before saving.

Running npx lopebase in the product's repo does all of this for you. See Set up from your terminal.

Watching the services it depends on

The adapter can also list what your app cannot work without: a database, a job queue, a second API, an email sender. Each one is a check your app runs with its own credentials and the cheapest authenticated call available, like a database's select 1, Stripe's balance.retrieve, a GET /app to GitHub with the app's own JWT, or an AI provider's GET /models, never a ping to the vendor's own status page or root address. Point the product's uptime check at /api/lopebase/health and the Uptime page shows every service on its own, with alerts that name the one that failed.

A service you mark critical: false shows as degraded, still answering 200, instead of reporting the whole product down when it fails, useful for something your app can run without for a while, like an AI provider.

For a second host your own app runs, like a worker or an internal API, httpCheck makes this easy: give it the URL and it is healthy whenever that host answers below 500, sending a User-Agent header some hosts require. It is only for hosts you own; a third-party vendor's address still needs a real credentialed call.

cachedCheck, for services with a rate limit

Wrapping a service check in cachedCheck keeps a successful result for 60 seconds and a failed one for only 10, so frequent uptime polls do not use up that service's API limit, while a service that comes back up still shows that within seconds rather than waiting out the full minute.

The health endpoint

GET /api/lopebase/health is the one unauthenticated path: it answers with each declared service's name and whether it is up, never an error message or anything from your data. It answers 503 when a critical service is down, and 200 with status: "degraded" when only non-critical ones are.

Keeping it updated

When a newer version of the adapter is out, LopeBase shows it in your notifications, and the LopeBase Adapter card on Connections carries a small icon for the same reason. Open that card to see which properties are behind, what the newer version adds, and copy buttons for the update command and a prompt for your coding agent. Run npx lopebase update in the product's folder: it finds the adapter, shows what changed since your version, and hands the upgrade to your coding agent, which asks before each change.

Where to go next

If something goes wrong

Something else? Contact us.

Connecting the adapter fails the test

Check that the URL ends in /api/lopebase and that the deployment is live, and that the signing secret pasted in matches the one your agent generated. The adapter is tested before anything is saved, so nothing half-connects.

A service shows as down but I know it is fine

Check what the service's check actually calls: it should use your app's own credentials for a cheap authenticated call, not a vendor's root address or status page, which can fail or rate-limit for reasons that have nothing to do with your integration.

One flaky service keeps marking the whole product down

Mark that service critical: false in the adapter's config, so its failure shows as degraded instead of reporting the product itself as down.

Uptime checks are using up my API's rate limit

Wrap that service's check in cachedCheck, which keeps a result for a short while instead of calling the API on every poll.