Server logic - Pawabase

The database covers reading and writing records. Sometimes a button in your app needs to do more than that: charge a card, generate a report, send an email, create three related records at once, or call a partner’s API with a secret you cannot put in a browser. That work belongs on the server, and server logic is how your app asks for it. You write the logic once, in one of two forms, and your app calls it by name:

Form	What it is	Call it with	Best for
Flow	A visual automation of steps and branches, built in the dashboard	`pawabase.flows.run("name", input)`	Multi-step processes you want to read and change without redeploying
Route	A custom URL under your API that runs a flow	`pawabase.routes.post("orders/42/pay", body)`	Giving a feature a clean, REST-style address

Both run as the person who called them. If a user is signed in, their identity is attached to the call, and the access rule on the flow or route decides whether they may run it. You never pass a user id in the request and trust it.

Get started

import { createClient } from "@pawabase/client";

const pawabase = createClient({ url: "https://api.example.com", apiKey: "pb_pk_…" });
await pawabase.auth.signInWithPassword({ email, password });

// 1. A flow: runs the automation and returns its response
const welcome = await pawabase.flows.run("send-welcome", { name: "Ada" });

// 2. A route: a custom URL with a method and a path
const paid = await pawabase.routes.post("orders/42/pay", { method: "card" });

from pawabase import Pawabase

pb = Pawabase("https://api.example.com", "pb_pk_…")
pb.auth.sign_in_with_password(email=email, password=password)

welcome = pb.flows.invoke("send-welcome", name="Ada")

paid = pb.routes.post("orders/42/pay", method="card")

Each call returns what the logic returned, already parsed. If it fails, you get one of the standard errors.

How a call travels

Your app calls the method. The client adds your API key and the signed-in user’s token.
Pawabase checks the access rule on that flow or route against the caller.
If allowed, your logic runs on the server. It can use secrets, other services and the database, with whatever authority you gave it.
The result comes back to your app.

Because step 2 happens on the server, hiding a button is never your only protection. The rule is.

Which form should I use?

Choose a flow when it is a sequence of steps that other people on your team should be able to see and change, or when it uses built-in building blocks such as sending mail, publishing to a channel, emitting an event or calling another service.
Choose a route when you want the address to look like part of your API (POST /orders/42/pay) and when the same logic should be reachable from outside your app too, by anything that can make an HTTP request.

A route runs a flow, so you usually build the flow first and give it an address when it needs one.

What this section covers

Flows

Run an automation and use its response.

Routes

Call custom URLs with GET, POST, PUT, PATCH and DELETE.

Patterns

Checkout, long jobs, retries, timeouts, uploads and testing.

​Get started

​How a call travels

​Which form should I use?

​What this section covers