# The site has no API. Your program becomes one.

Describe the flow once as a program with inputs. From then on it is one HTTP call: inputs in, typed JSON out, with versions, aliases and webhooks, as if the site had shipped the API itself.

## The problem

Partners and old portals rarely offer an API. Wrapping a site in a script works until the next redesign, and then the integration that depends on it breaks without warning.

## A program with inputs

Declare the inputs the flow needs. Kaabist validates them on every call, with types, defaults and limits.

```
{ "kaab": "1",
  "name": "plan-lookup",
  "inputs": { "account": "string" },
  "steps": [ … ] }
```

## One call, typed JSON back

Create a job with the program's name and the inputs. With Prefer: wait the response holds up to 30 seconds and returns the finished job with its data.

```
curl https://api.kaab.ist/v1/jobs \
  -H "Authorization: Bearer $KAAB_API_KEY" \
  -H "Prefer: wait=30" \
  -d '{"program": "plan-lookup", "inputs": {"account": "A-1042"}}'
```

## Versions and aliases

Every change is a new version with a diff. Point callers at an alias such as production, and move it when a new version is ready; rolling back is moving it back.

## Faster after the first run

When the page loads its data from a JSON endpoint, a browser run finds it and later calls read it directly on the HTTP tier.

## Questions

### What if a call takes longer than 30 seconds?

You get the job back while it runs; wait for it with GET /jobs/{id}, or receive job.succeeded on your webhook.