How to save what your website sends into a database

• A PostgreSQL database on the public internet, with a table for the enquiries — say enquiries with name, email, message and received_at. Workflows cannot reach private networks.
• A PostgreSQL connection with a user and password of its own. Give that user permission to insert into this table and nothing more. Connect a PostgreSQL database
• Your website's server able to call an address when an enquiry comes in, with a JSON body (the enquiry as structured data).

The Webhook trigger and PostgreSQL work on every plan, Free included.

1. In Bizomate, choose New workflow, then Webhook — under Developer in Browse all triggers. A webhook is an address other software can call to start the workflow. Leave Method on POST. Under Respond, choose Using a Respond to Webhook step, so the website waits for the row's ID number.

   Copy the Production URL and give it to your website's server. Anyone with the address can start the workflow. So keep it where the server keeps its other secrets — never in the page itself, where a visitor could read it. Starting a workflow from a webhook

2. Save the enquiry. Add PostgreSQL · Query and choose your connection. In Query:

   insert into enquiries (name, email, message, received_at)
   values (@name, @email, @message, now())
   returning id
   

   Under Parameters, select Add a field for each @name: @name with {{ trigger.body.name }}, @email with {{ trigger.body.email }} and @message with {{ trigger.body.message }}.

   Values always go to the database as parameters, never pasted into the SQL. So an enquiry that contains SQL is stored as text and nothing more. Query a PostgreSQL database

3. Answer the website. Add Respond to Webhook, under Logic in the step picker. Leave Status code at 200, keep Raw JSON, and in The JSON to send write:

   { "saved": true, "id": "{{ $json.rows.0.id }}" }
   

   The website gets that answer while the run carries on. It waits 30 seconds at most, so anything slow belongs after this step, not before it. Answer a webhook caller with Respond to Webhook

4. Publish. The address stays the same every time you publish, so the website is set up once. Publish a workflow

The Webhook to SQL template installs a Webhook trigger and a Microsoft SQL · Query step as a draft. Microsoft SQL ◇ (paid plans) builds and tests on Free and publishes on a paid plan; for PostgreSQL on any plan, build it as above.

A test run on its own has an empty body. To build against a real request, use the trigger's Test URL, not the Production URL. Select Listen for a test event. Then, within two minutes, send a request to the Test URL from your website's staging server, or a tool such as curl. Use a body like this:

{ "name": "Northwind Logistics", "email": "orders@northwind.example", "message": "Quote for 40 deliveries a week" }

A test run starts with exactly what was sent. The row is really written, and your tool shows the answer the website will get. Test calls count as test runs, not against your monthly runs. Send a test event to a webhook

If it does not work. The usual causes:

• The caller gets 404 (not found). On the Test URL, you were not listening, or the two minutes ran out. On the Production URL, the workflow is not published or is switched off.
• The database refused. Read the reason in the run — a missing table, a column spelt differently, a user without permission to insert.
• The caller gets 500 (server error). The run ended before it reached Respond to Webhook, usually because the query failed first. The run says which step and why.

Each call is one run. A website that sends 300 enquiries a month uses 300 runs. One address takes up to 120 calls a minute, and up to 256 KB a call. What counts as a run