How do I use LingCode Cloud in my own app?

A LingCode Cloud backend is a private Postgres database (plus auth, storage, realtime, and vector search) that you reach over HTTPS. You don't open a database connection or run SQL from the browser — you talk to a small data gateway through the official client SDK, which is shaped like Supabase or Firebase so the calls feel familiar. Everything below is that SDK.

What you'll learn

• The two values you need (and why the anon key is safe to ship to the browser)
• How to load the SDK and create a client outside /try
• The core calls: data, auth, storage, realtime, vector
• The one constraint to design around — it's table-CRUD, not raw SQL

The two values you need

Every backend has exactly two things a client needs:

• The data URL — e.g. https://lingcode.dev/api/cloud/be/<your-backend-id>. This is the gateway for this backend.
• The anon key — a public token that identifies the backend and grants the anonymous role. It is meant to ship in your client bundle. It can't read or write anything a signed-out visitor shouldn't, because access is enforced by row-level security on the server, not by hiding the key.

Find both at lingcode.dev/backends — open your backend, and copy the connection details from Settings (the same pair you'd paste into another MCP client). In a framework, store them as public config — for Next.js, NEXT_PUBLIC_LINGCODE_BACKEND_URL and NEXT_PUBLIC_LINGCODE_BACKEND_ANON_KEY; for a bundler, whatever your import.meta.env / process.env convention is. They're public, so they belong in client config, not in a server-only secret.

Load the SDK and create a client

The SDK is a single zero-dependency file served from the CDN. The plain-HTML version:

<script src="https://lingcode.dev/sdk/lingcode-v1.js"></script>
<script>
  const lingcode = LingCode.createClient(
    'https://lingcode.dev/api/cloud/be/<your-backend-id>',
    '<your-anon-key>'
  );
</script>

In a module/bundler app, load the same file and call LingCode.createClient(url, key) with your env values. (Inside /try and the Mac preview you skip this entirely — the client is already there as window.lingcode, pre-wired to that project's backend. Never re-create it or hardcode keys there.)

Wait for the client to settle once on load before reading auth state — it finalizes any sign-in redirect first:

await lingcode.ready;
const user = lingcode.auth.getUser(); // { id, email } | null

Read and write data

Every call returns { data, error } — check error before using data. Filters chain before the verb:

// read
const { data, error } = await lingcode
  .from('todos')
  .eq('done', false)
  .order('created_at', { ascending: false })
  .limit(50)
  .select();

// write
await lingcode.from('todos').insert({ title: 'Buy milk' });
await lingcode.from('todos').eq('id', 1).update({ done: true });  // filter REQUIRED
await lingcode.from('todos').eq('id', 1).delete();                // filter REQUIRED

Filter operators: .eq .neq .gt .gte .lt .lte .like .ilike .in(col,[…]) .is(col,null), and .match({a:1,b:2}) for several equals at once. Multiple filters AND together. update and delete refuse to run without a filter, so you can't wipe a table by accident.

Auth, storage, realtime, vector

• Auth — lingcode.auth.signUp({email,password}) / signIn(...); passwordless sendMagicLink({email}) (the SDK auto-finalizes the returned link); email codes sendOtp + verifyOtp; social getProviders() then signInWithOAuth('google'). The SDK stores the session and attaches it to later calls, so subsequent .from() reads run as the signed-in user and RLS keys off their id.
• Storage — await lingcode.storage.from('public').upload('avatars/me.png', file) → data.url; getPublicUrl(path); download(path).
• Realtime — const off = lingcode.from('todos').subscribe(({type,row}) => { /* INSERT|UPDATE|DELETE */ }); call off() on teardown. Events are RLS-filtered, so a signed-in user only receives their own rows. Use it instead of polling.
• Vector — store an embedding column and rank by similarity with lingcode.vector.search({ table, column, embedding, limit, metric:'cosine' }) for semantic search / RAG.

The one thing to know: it's table-CRUD, not raw SQL

This is the constraint that surprises people coming from a SQL client or PostgREST, and it's the difference between code that works the first time and code that 400s. The runtime data API operates on one table at a time. So:

• No JOINs. Fetch each table separately and join in your code (or denormalize the schema so you don't need to). Want a todo with its author? Read the todos, collect the user_ids, read those users, stitch them together client-side.
• No upserts / ON CONFLICT. Insert, and if you get a duplicate-key error, fetch the row and update it instead.
• Pages of 200. .select() returns at most 200 rows — page with .limit() / .offset(), and compute counts and sums in your code.

Anything genuinely relational or heavy — a multi-table report, an index, a constraint, a generated column, seed data — belongs in the schema, not in a runtime call. Create a VIEW (then select() from it like a table), add the index, or run the migration from the console's SQL tab or the apply_migration tool. The gateway stays a thin, safe CRUD layer on purpose; the full power of Postgres lives one level down, in your migrations.

What's next