Skip to main content

Posting Data

Kvery isn't read-only. A query can write to your database — insert, update or delete rows — and accept input through form variables. This turns a query into a small write endpoint or an editable grid.

Write queries​

Any data-modifying statement works, with values supplied as $-prefixed form variables:

INSERT INTO leads (name, email, source)
VALUES ('$name', '$email', '$source');
UPDATE tickets
SET status = '$status'
WHERE id = '$id';

Each $-prefixed variable becomes a form field (or an API parameter) that Kvery fills from the request when the query runs. Apostrophes in the values are escaped, so put text in quotes (see Form variables).

HTTP method matters for the API​

When a query is published as an API, Kvery routes requests by HTTP method according to the SQL the query contains:

  • Read statements (SELECT, EXEC, and WITH … SELECT) are served on GET requests.
  • Write statements (INSERT, UPDATE, DELETE, REPLACE, ALTER, CREATE) are served on POST / PUT / PATCH / DELETE requests.

So a query containing an INSERT becomes a write endpoint that callers reach with a POST, while a SELECT query is a read endpoint reached with GET.

Editable tables from results​

Combine a write query with the ::operations column modifier on a results table to attach row-level actions (such as edit or delete) to each row. The modifier exposes the controls; the write query performs the change.

Controlling the response​

Pair write queries with directives to return a clean result:

INSERT INTO leads (email) VALUES ('$email');
ON ERROR RETURN 'That email could not be saved'
SET HTTPCODE '201'

Tips​

  • Validate critical inputs in SQL (constraints, WHERE guards) — don't rely on the form alone.
  • Use webhooks (ON SUCCESS POST) to notify other systems after a successful write.
  • For bulk writes via the API, see Batch requests.