DEV Community: Mathias Ahlgren

How to Replace a Google Form With a Real HTML Form on Your Site

Mathias Ahlgren — Wed, 29 Jul 2026 06:56:00 +0000

Most guides about Google Forms and your website answer a question you did not ask.

Search for how to replace a Google Form with your own HTML and you get three kinds of answer. Embed the iframe but style the container. Use a service that hides Google's branding. Or the clever one: build your own HTML form and point it at Google's endpoint, so responses still land in your existing spreadsheet.

All three keep Google Forms in the loop. If that is what you want, they work, and I will show you the third one because it is genuinely useful when you need it.

But if you actually want the Google Form gone, replaced by markup you own, here is how that works and what it costs you.

One-line summary: Google Forms does one thing your static site can't, accept a POST; swap that for a form endpoint and you get your markup back, at the cost of owning spam and losing free-unlimited.

Why the iframe is the problem

The embed is an iframe. That means:

You cannot restyle it. Your fonts and colours stop at the border.
It does not resize with its content, so a long form becomes a scroll area inside your page.
It looks like Google on your site, because it is.
You inherit its accessibility behaviour and can do nothing about it.

None of that matters for an internal survey or a sports club sign-up sheet. It matters a lot on a business site, where a Google-branded iframe reads as a stopgap someone never got round to replacing.

The clever workaround, and where it breaks

You can POST your own HTML form straight at a Google Form's response endpoint. Open your form, inspect the page, dig the field IDs out of the markup, and build a form whose input names match:

<form action="https://docs.google.com/forms/d/e/YOUR_FORM_ID/formResponse" method="POST">
  <input name="entry.1234567890" type="email" required>
  <textarea name="entry.9876543210" required></textarea>
  <button type="submit">Send</button>
</form>

Responses land in the same spreadsheet. No new service. For a throwaway internal page, this is fine.

The guides that recommend it tend to stop there, so here is the rest.

The field names are opaque and fragile. entry.1234567890 means nothing to the next person reading your template, and it is tied to a form you now have to keep alive in someone's Google Drive.

You cannot read the response. Google does not send CORS headers for this endpoint, so a fetch either fails or you send it with mode: "no-cors" and get an opaque response back. You cannot tell success from failure. Submitting the form natively navigates the user to a Google-branded confirmation page you do not control.

There is no server-side validation you own. Whatever Google's form does with a malformed submission is what happens.

Nothing tells you when it breaks. If the form is deleted, renamed, or its fields change, your site keeps posting into the void and you find out when someone asks why you never replied.

It is a workaround. Treat it as one.

Replacing it properly

A real HTML form needs somewhere to POST. That is the only thing Google Forms was actually providing that a static site cannot do alone.

The markup is ordinary:

<form action="https://api.formpaste.com/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
  <input type="email" name="email" placeholder="Your email" required>
  <textarea name="message" placeholder="Your message" required></textarea>
  <button type="submit">Send</button>
</form>

That is a real form. Your CSS applies. Your validation applies. The field names are the field names. Submissions arrive by email.

I work on Formpaste, which is what that endpoint is, so weigh the recommendation accordingly. Formspree, Web3Forms and Basin do the same job and the rest of this post applies to all of them. What matters is the shape: your markup, someone else's endpoint.

Sending people somewhere after submit

By default the browser posts and shows a response. If you want your own thank-you page, add a redirect field:

<input type="hidden" name="redirect" value="https://yoursite.com/thanks">

Worth knowing that any endpoint accepting a redirect target has to validate it, otherwise it is an open redirect that spammers will find and use to launder links through your domain. Formpaste checks it against the form's allowlisted domains and rejects anything else. If you are evaluating another service, that is a fair thing to ask about.

Keeping the spreadsheet

This is usually the real objection. The Google Form was feeding a Sheet, and something downstream reads that Sheet.

You have two options. Export the existing responses to CSV and keep them as an archive, which costs nothing and takes a minute. Or keep new submissions syncing into a Sheet automatically, which most form backends offer as a paid integration. On Formpaste it is a Pro feature, not a free one, and I would rather say that here than have you find out at the paywall. It appends a timestamped row per submission and adds a column when a new field shows up rather than silently dropping the value.

If the spreadsheet is load-bearing for you, price that in before you migrate.

Spam, which Google was quietly handling

Google Forms is not much of a spam target because the endpoint is obscure and reCAPTCHA is one toggle away. A public form endpoint on your own domain is a different proposition. Once you move, you own this problem.

The usual answer is a CAPTCHA. It works, and it makes every real visitor solve a puzzle to talk to you, which on a contact form is a strange trade.

The alternative is scoring submissions on signals the visitor never sees: a honeypot field bots fill and humans do not, how fast the form was completed, submission rate from one source, disposable-email domains. Anything borderline goes to a review folder instead of being deleted, so a false positive is recoverable rather than a silently lost message.

Whatever you pick, decide it deliberately. A brand-new public endpoint with no spam handling gets found.

When to keep Google Forms

Genuinely, sometimes:

Non-technical people need to edit the form. Google Forms has a UI for that. A hand-written HTML form means editing markup and deploying.
You need quizzes, branching, or conditional logic. That is a survey tool's job. Rebuilding it in raw HTML is work you do not want.
It is a one-off. An event RSVP that runs for three weeks does not need a migration.
Budget is zero and volume is high. Google Forms is free and effectively unlimited. Hosted form backends have free tiers with monthly caps. Formpaste's free plan is 250 submissions a month across 3 forms; others differ. If you are collecting thousands of responses and do not care how it looks, Google wins on price.

Rebuild when the form is a permanent part of a site you control the design of, and the people maintaining it are comfortable in a code editor. That is the whole rule.

The migration, start to finish

Export the existing responses from the linked Sheet. Keep the file.
Write the HTML form. Same fields, real names, your markup.
Point it at an endpoint and confirm a test submission arrives.
Style it. This is the part you could not do before.
Add a redirect to your own thank-you page.
Decide on spam handling before you make it public, not after.
Replace the iframe. Leave the old Google Form in place, closed to responses, until you are sure.
If anything downstream read that Sheet, either point it at the archive or set up a sync.

Step 7 is the one people skip. Keep the old form until you have seen real submissions arrive through the new one.

If you are still deciding whether to rebuild at all, I wrote about that trade-off separately: Putting a Google Form on Your Own Website (And When to Rebuild It Instead).

How to Add a Contact Form to a Static HTML Site (Without a Backend)

Mathias Ahlgren — Sun, 26 Jul 2026 12:01:02 +0000

Static sites are fantastic: fast, cheap to host, secure, and dead simple to deploy. Then a client says "can visitors email us from the site?" and suddenly you're staring at the one thing a static site can't do on its own: receive a form submission.

The good news is you don't need a backend or server to do this. By the end of this guide you'll have a fully working, accessible, spam-resistant contact form you can drop into plain HTML, React, Next.js, Vue, Astro, or Svelte, with complete copy-paste code, not placeholders.

Let's start by being honest about your options.

Full disclosure

I work with Formpaste, one of the form-backend services covered below, so I'll use it in the hands-on examples. I've kept the comparison section genuinely even-handed. The techniques here work with any provider, and I'll tell you where each one fits.

The options for handling forms without a backend

There are really four common approaches, and they're not equal.

1. mailto: links. Zero setup. <a href="mailto:you@example.com"> opens the visitor's email client. But it's a rough experience: it depends on a configured desktop mail app, publishes your address for scrapers to harvest, and collects nothing structured. Fine for a personal landing page, not for a real contact form.

2. Google Forms embed. Free and no code, but the iframe looks nothing like your site, works against your design and performance, and the UX is clearly "this is a Google Form." Fine for a hobby project, weak for anything that needs to look professional.

3. Host-native form handling. Netlify Forms and a few other hosts offer built-in form capture. Genuinely nice, if you're on that host. The moment you move to GitHub Pages, Cloudflare Pages, or your own S3 bucket, it's gone. You're locked in.

4. A form-backend API. You point your <form> at an endpoint; the service receives submissions, filters spam, and emails you (or fires a webhook). Host-agnostic, works with any framework, and keeps your markup 100% yours. This is the approach that works everywhere, so it's what we'll build.

Step 1: The HTML form (accessible by default)

Here's a complete, accessible form. Note the real <label> elements and the for/id pairing, which is the part most tutorials skip.

<form
  action="https://api.formpaste.com/submit"
  method="POST"
  id="contact-form"
>
  <!-- Your access key from the dashboard -->
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY_HERE" />

  <div>
    <label for="name">Name</label>
    <input type="text" id="name" name="name" autocomplete="name" required />
  </div>

  <div>
    <label for="email">Email</label>
    <input type="email" id="email" name="email" autocomplete="email" required />
  </div>

  <div>
    <label for="message">Message</label>
    <textarea id="message" name="message" rows="5" required></textarea>
  </div>

  <button type="submit">Send message</button>
</form>

That's a working form already. With no JavaScript at all, a submission POSTs to the endpoint and lands in your inbox. Progressive enhancement done right: it works before a single line of JS runs.

By default the endpoint answers with JSON. Without JavaScript on the page the browser will simply display that JSON response, which is not the experience you want, so see Step 4 for how to send the visitor to a thank-you page instead.

Step 2: Enhance it with JavaScript (proper loading and error states)

The plain form causes a full page navigation. To keep users on the page with inline feedback, enhance it. Notice this actually selects the form by its id, handles the network failure case, and gives real status feedback, which are the details that separate a working form from a demo.

<form action="https://api.formpaste.com/submit" method="POST" id="contact-form">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY_HERE" />
  <input type="text" id="name" name="name" required />
  <input type="email" id="email" name="email" required />
  <textarea id="message" name="message" required></textarea>
  <button type="submit">Send message</button>
  <p id="form-status" role="status" aria-live="polite"></p>
</form>

<script>
  const form = document.getElementById("contact-form");
  const statusEl = document.getElementById("form-status");
  const button = form.querySelector('button[type="submit"]');

  form.addEventListener("submit", async (e) => {
    e.preventDefault();
    button.disabled = true;
    statusEl.textContent = "Sending…";

    try {
      const response = await fetch(form.action, {
        method: "POST",
        body: new FormData(form),
      });

      if (response.ok) {
        statusEl.textContent = "Thanks! Your message was sent.";
        form.reset();
      } else {
        // The API returns { success: false, code, message } on failure.
        const data = await response.json().catch(() => null);
        statusEl.textContent = data?.message ?? "Something went wrong. Please try again.";
      }
    } catch (error) {
      statusEl.textContent = "Network error. Please try again.";
    } finally {
      button.disabled = false;
    }
  });
</script>

The aria-live="polite" region means screen readers announce the status change, which is a free accessibility win.

A successful response is JSON shaped like this:

{ "success": true, "message": "Submission received.", "id": "..." }

Errors use the same envelope with a machine-readable code, so you can branch on data.code if you want distinct messages for rate_limited versus domain_not_allowed.

Step 3: Framework examples (complete, not placeholders)

React

import { useState } from "react";

export default function ContactForm() {
  const [status, setStatus] = useState("idle"); // idle | sending | success | error

  async function handleSubmit(e) {
    e.preventDefault();
    // Capture the form node now: after the first await, `currentTarget` is null.
    const form = e.currentTarget;
    setStatus("sending");

    try {
      const response = await fetch("https://api.formpaste.com/submit", {
        method: "POST",
        body: new FormData(form),
      });
      setStatus(response.ok ? "success" : "error");
      if (response.ok) form.reset();
    } catch {
      setStatus("error");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY_HERE" />

      <label htmlFor="name">Name</label>
      <input id="name" type="text" name="name" required />

      <label htmlFor="email">Email</label>
      <input id="email" type="email" name="email" required />

      <label htmlFor="message">Message</label>
      <textarea id="message" name="message" required />

      <button type="submit" disabled={status === "sending"}>
        {status === "sending" ? "Sending…" : "Send message"}
      </button>

      {status === "success" && <p role="status">Thanks! Your message was sent.</p>}
      {status === "error" && <p role="status">Something went wrong. Try again.</p>}
    </form>
  );
}

Next.js (App Router)

With the App Router, keep the form as a client component so you can manage submit state. You don't need a route handler at all, since the form posts directly to the API.

Worth saying plainly: the access key sits in client-side code and is visible to anyone who views source. That's by design for this kind of endpoint. The key identifies which form a submission belongs to; it isn't a secret credential, and it can't be used to read your submissions. Your protection against someone reusing it elsewhere is the domain allowlist, covered below.

"use client";

import { useState } from "react";

export default function ContactForm() {
  const [status, setStatus] = useState("idle");

  async function handleSubmit(e) {
    e.preventDefault();
    const form = e.currentTarget; // capture before awaiting
    setStatus("sending");

    try {
      const res = await fetch("https://api.formpaste.com/submit", {
        method: "POST",
        body: new FormData(form),
      });
      setStatus(res.ok ? "success" : "error");
      if (res.ok) form.reset();
    } catch {
      setStatus("error");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY_HERE" />
      <input type="text" name="name" placeholder="Name" required />
      <input type="email" name="email" placeholder="Email" required />
      <textarea name="message" placeholder="Message" required />
      <button type="submit" disabled={status === "sending"}>
        {status === "sending" ? "Sending…" : "Send message"}
      </button>
      {status === "success" && <p role="status">Message sent!</p>}
      {status === "error" && <p role="status">Please try again.</p>}
    </form>
  );
}

Vue 3

This one posts JSON instead of FormData, just to show the endpoint accepts both. Because the values come from v-model state, the access key goes in the JSON body and there's no hidden input.

<template>
  <form @submit.prevent="submitForm">
    <label for="name">Name</label>
    <input id="name" v-model="form.name" type="text" name="name" required />

    <label for="email">Email</label>
    <input id="email" v-model="form.email" type="email" name="email" required />

    <label for="message">Message</label>
    <textarea id="message" v-model="form.message" name="message" required />

    <button type="submit" :disabled="status === 'sending'">
      {{ status === "sending" ? "Sending…" : "Send message" }}
    </button>

    <p v-if="status === 'success'" role="status">Thanks! Message sent.</p>
    <p v-if="status === 'error'" role="status">Something went wrong.</p>
  </form>
</template>

<script setup>
import { reactive, ref } from "vue";

const ACCESS_KEY = "YOUR_ACCESS_KEY_HERE";
const form = reactive({ name: "", email: "", message: "" });
const status = ref("idle");

async function submitForm() {
  status.value = "sending";
  try {
    const res = await fetch("https://api.formpaste.com/submit", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ ...form, access_key: ACCESS_KEY }),
    });
    status.value = res.ok ? "success" : "error";
    if (res.ok) Object.assign(form, { name: "", email: "", message: "" });
  } catch {
    status.value = "error";
  }
}
</script>

Astro

Astro ships zero JS by default, so the plain HTML form works as-is in a .astro file.

---
// src/components/ContactForm.astro
const ACCESS_KEY = "YOUR_ACCESS_KEY_HERE";
---

<form action="https://api.formpaste.com/submit" method="POST" id="contact-form">
  <input type="hidden" name="access_key" value={ACCESS_KEY} />
  <input type="hidden" name="redirect" value="/thank-you" />

  <label for="name">Name</label>
  <input id="name" type="text" name="name" required />

  <label for="email">Email</label>
  <input id="email" type="email" name="email" required />

  <label for="message">Message</label>
  <textarea id="message" name="message" required></textarea>

  <button type="submit">Send message</button>
</form>

Because there's no JavaScript here, the redirect field matters: without it the browser would land on the raw JSON response. If you'd rather have inline feedback, drop the redirect field and add a client script:

<script>
  const form = document.getElementById("contact-form");

  form.addEventListener("submit", async (e) => {
    e.preventDefault();
    const res = await fetch(form.action, {
      method: "POST",
      body: new FormData(form),
    });
    form.insertAdjacentHTML(
      "beforeend",
      res.ok ? "<p role='status'>Message sent!</p>" : "<p role='status'>Please try again.</p>",
    );
    if (res.ok) form.reset();
  });
</script>

Svelte

<script>
  let status = "idle";

  async function handleSubmit(event) {
    const form = event.currentTarget; // capture before awaiting
    status = "sending";
    try {
      const res = await fetch("https://api.formpaste.com/submit", {
        method: "POST",
        body: new FormData(form),
      });
      status = res.ok ? "success" : "error";
      if (res.ok) form.reset();
    } catch {
      status = "error";
    }
  }
</script>

<form on:submit|preventDefault={handleSubmit}>
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY_HERE" />
  <input type="text" name="name" placeholder="Name" required />
  <input type="email" name="email" placeholder="Email" required />
  <textarea name="message" placeholder="Message" required></textarea>
  <button type="submit" disabled={status === "sending"}>
    {status === "sending" ? "Sending…" : "Send message"}
  </button>
  {#if status === "success"}<p role="status">Message sent!</p>{/if}
  {#if status === "error"}<p role="status">Please try again.</p>{/if}
</form>

Step 4: Redirect vs. AJAX, pick your success flow

There are two ways to confirm a submission, and the choice is made by the request itself, not by a header.

JSON (the default). Post the form and you get { success, message, id } back with a 200. That's what every JavaScript example above relies on: intercept the submit, fetch, show an inline message, never leave the page.

Redirect. Add a redirect field to the form and a successful submission answers with a 303 See Other to that URL, so the browser lands on your thank-you page. This is the no-JS path.

<input type="hidden" name="redirect" value="/thank-you" />

Two rules worth knowing, because both fail closed:

A relative URL like /thank-you always works.
An absolute URL like https://example.com/thank-you only works if that domain is on your form's allowlist. With an empty allowlist, absolute redirects are rejected outright. This is deliberate: it stops a stolen key from bouncing your visitors to a phishing page.

An invalid redirect returns 400 invalid_redirect and nothing is stored, so you'll notice immediately rather than silently losing submissions.

Use redirect for maximum simplicity and resilience; use JSON for a smoother single-page feel.

Stopping spam without CAPTCHA

CAPTCHA puzzles annoy real users and hurt conversions. You can stop most bot spam with three quiet techniques, no puzzles required.

Honeypot field: a hidden input real users never fill in, but bots do. Hide it from humans and screen readers, then reject any submission where it's filled. The field name has to match whatever your provider looks for. Formpaste uses botcheck:

<!-- Bots fill this; humans never see it -->
<input
  type="text"
  name="botcheck"
  style="position:absolute; left:-9999px;"
  tabindex="-1"
  autocomplete="off"
  aria-hidden="true"
/>

If you invent your own field name, the server has no idea it's a honeypot and will just store it as an ordinary form field. Check your provider's docs for the exact name; this is a quiet failure that only shows up later as spam in your inbox.

Timing check: legitimate users take a few seconds to fill a form; bots submit in milliseconds. Record when the form loads and flag submissions that arrive suspiciously fast. Formpaste reads this from a _ts field holding the page-load timestamp:

<input type="hidden" name="_ts" id="form-ts" />
<script>
  document.getElementById("form-ts").value = Date.now();
</script>

Rate limiting: cap submissions per IP per minute so a bot can't hammer your endpoint. This one genuinely requires the server side.

Implementing all three yourself means running server logic, which defeats the "no backend" goal. This is where a form-backend API earns its keep: good ones run honeypot, timing, rate-limit, disposable-email, and duplicate checks for you, then hold anything suspicious in a quarantine you can review rather than silently dropping real messages.

Common errors (and how to fix them)

"My form submits but I get no email." Check your spam folder, confirm you verified your sender email, and make sure the access_key value is correct and not still the placeholder.

"I get a 403 domain_not_allowed." Your form has a domain allowlist and the request came from a domain that isn't on it. Add the domain in the dashboard. Note this is a normal JSON error response, not a CORS error.

"CORS error in the console." This is a different problem from the one above, and it's worth separating them. A form endpoint that's meant for static sites should send permissive CORS headers, so a genuine CORS failure usually means the request never reached the API at all: a typo'd endpoint URL, a network/DNS failure, or an adblocker. Check the Network tab to see whether a response came back at all. Also worth knowing: CORS is a browser policy, not a security boundary. It doesn't protect your key, and the domain allowlist is what actually restricts who can submit.

"Nothing happens on submit." If you're using the JS version, confirm your getElementById/selector actually matches the form, and that you called e.preventDefault().

"It works locally but not in production." Almost always the domain allowlist. Add your production domain.

"e.currentTarget is null." Classic async footgun: currentTarget is cleared once the handler returns, so reading it after an await blows up. Capture it into a variable first, as the examples above do.

Choosing a service

A quick, honest lay of the land:

Formspree is mature and popular, with a generous ecosystem. A safe default, though the free tier is limited. Web3Forms is genuinely no-signup and access-key based, great for quick throwaway forms. Formpaste (what I used here) leans into paste-a-component simplicity, CAPTCHA-free spam filtering with a quarantine you control, and, unusually, an MCP server so an AI coding agent can wire the form up for you. Netlify Forms is excellent but only if you're already hosting on Netlify.

Any of them work with every code sample above. Swap the endpoint and key, and check each provider's docs for its own field names, since honeypot and redirect conventions differ between services.

Wrapping up

Adding a contact form to a static site no longer means standing up a server. You've now got a complete, accessible, progressively-enhanced form, working versions for five frameworks, a CAPTCHA-free spam strategy, and a fix-list for the usual gotchas.

Start with the plain HTML form, enhance with JavaScript when you want inline feedback, and let a form-backend API handle delivery and spam so you can get back to building.

What do you use for forms on static sites? Drop your approach in the comments 👇

How to Install Postiz on a Local Windows Machine with Only Docker Desktop

Mathias Ahlgren — Tue, 21 Jul 2026 08:04:12 +0000

Postiz is the hugely popular open-source social media scheduler, a self-hosted alternative to Buffer or Hootsuite with over 33,000 GitHub stars. This guide walks through installing it on Windows with Docker Desktop.

If you are like me, and found that the official Postiz documentation is too vague, then this step by step is for you.

⚡ Read this first: the local-hosting caveat

One thing to know before you start:

Postiz only publishes posts while your machine is running.

Scheduling is handled by a background worker inside the Docker stack. If you schedule a post for 9:00 AM Tuesday and your PC is asleep, shut down, or Docker isn't running, the post does not go out. It fires late, when the stack next starts.

Windows sleep settings are the usual culprit. A machine that suspends
overnight will miss anything scheduled overnight, so check your power plan if posts land hours late.

That makes a local install great for:

Trying Postiz before committing to a server
Drafting and organising content
Development and testing

...and a poor fit for reliably hitting a posting schedule. If you need posts to land on time, put it on a VPS or use the hosted version. Everything below applies to a server too - only the "keep the machine on" problem goes away.

If scheduling is a dealbreaker then you can either pay for Postiz, or host it on a VPS. A cheap VPS is enough; I've written up which hosts are actually worth it here.

What you need

Windows 10 or 11
Docker Desktop - https://docker.com/products/docker-desktop
Git (for Git Bash) - https://git-scm.com/download/win
~15 GB free disk space. The stack pulls about 9.5 GB of images, plus room for volumes and overhead. (Measured on one install - image sizes drift, so treat it as a ballpark.)
8 GB RAM minimum; the stack idles around 3–4 GB. Note that Docker Desktop's WSL2 backend has its own memory ceiling on top of that, so 8 GB total leaves very little headroom. 16 GB is a lot more comfortable.

Times below assume a reasonably fast connection. The image pull dominates.

Step 1 - Install and start Docker Desktop

Install it, then launch it and wait for the whale icon in the system tray to stop animating. The Docker engine runs in a Linux VM that takes 30–60 seconds to boot. Every docker command fails until it's up.

Turn on Settings → General → Start Docker Desktop when you log in.
Postiz can't publish anything if Docker isn't running, so on a local install this is doing real work for you.

Verify in Git Bash:

docker --version

Any version number means the CLI is reachable and the engine is up. If you get
bash: docker: command not found, see Pitfall 1.

Step 2 - Get the compose file

Pick wherever you keep projects. In Git Bash, your Windows user folder is
~, so this puts it in C:\Users\<you>\projects\postiz:

mkdir -p ~/projects && cd ~/projects
git clone https://github.com/gitroomhq/postiz-docker-compose postiz
cd postiz

This is just the Docker Compose configuration - the application itself
arrives as prebuilt images.

The folder name matters a little: Compose prefixes its volumes and networks with it. Clone into postiz and you get postiz_postgres-volume; clone into my-postiz and it's my-postiz_postgres-volume. Commands below assume postiz.

Step 3 - Set a real JWT secret

docker-compose.yaml ships with a placeholder:

JWT_SECRET: 'random string that is unique to every install - just type random characters here!'

That string signs your login tokens, and it's identical in every copy of the repo. Generate your own:

openssl rand -base64 32

Paste the result in place of the placeholder. Do this before first launch - changing it later invalidates existing sessions.

Two other settings worth knowing, both near the top of the file:

Setting	Default	Meaning
`DISABLE_REGISTRATION`	`'false'`	Signup is open. Needed for your first account - close it afterwards (Step 6).
`MAIN_URL`	`http://localhost:4007`	Change only if you're not on localhost.

Step 4 - Start it

docker compose up -d

The first run pulls roughly 9.5 GB across 8 images - expect 5–15 minutes.
Subsequent starts take well under a minute.

-d runs it detached, in the background.

Step 5 - Wait for it to actually be ready

docker compose ps

You want all services showing (healthy):

postiz                   Up (healthy)
postiz-postgres          Up (healthy)
postiz-redis             Up (healthy)
temporal                 Up (healthy)
temporal-postgresql      Up (healthy)
temporal-elasticsearch   Up (healthy)
temporal-ui              Up (healthy)
temporal-admin-tools     Up

Services start in dependency order - Elasticsearch, then Temporal, then
Postiz - and Postiz runs database migrations on first boot. Seeing
(health: starting) for two or three minutes is normal.

Then open:

http://localhost:4007

Use http://, not https://. Nothing here terminates TLS, so the https
URL simply fails.

Step 6 - Close registration

Once your account exists, stop anyone else from creating one. In
docker-compose.yaml:

DISABLE_REGISTRATION: 'true'

Apply it:

docker compose up -d

That recreates only the changed container. Your account and data live in
named volumes and are untouched - you stay logged in.

Step 7 - Keep secrets out of version control

Optional, but worth doing if you'll ever commit this config or copy it to a server.

Docker Compose automatically reads a .env file sitting next to
docker-compose.yaml. Move the secrets there:

.env

JWT_SECRET=your-generated-secret
POSTGRES_USER=postiz-user
POSTGRES_PASSWORD=postiz-password
POSTGRES_DB=postiz-db-local

docker-compose.yaml

JWT_SECRET: ${JWT_SECRET:?set JWT_SECRET in .env}
DATABASE_URL: 'postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postiz-postgres:5432/${POSTGRES_DB}'

.gitignore

.env

The :? syntax makes Compose fail with a clear message if the variable is
missing, rather than silently starting with an empty secret.

Check the substitution before restarting:

docker compose config | grep JWT_SECRET

If .env is set up correctly, this prints the resolved value. If the variable is missing, docker compose config exits with an error rather than printing anything - the grep never runs. Either outcome tells you what you
need:

error while interpolating services.postiz.environment.JWT_SECRET:
required variable JWT_SECRET is missing a value: set JWT_SECRET in .env

Back .env up somewhere outside the repo. It's git-ignored by design,
which also means it isn't backed up. Lose the JWT_SECRET and every session breaks.

Step 8 - Connect social channels

Postiz reads platform credentials from the container's environment, not from anything in the web UI. There's no dashboard field for these - you set them in config and restart.

Using the .env pattern from Step 7, take X as the example:

.env

X_API_KEY=your-key-here
X_API_SECRET=your-secret-here

docker-compose.yaml

X_API_KEY: ${X_API_KEY:-}
X_API_SECRET: ${X_API_SECRET:-}

The :- default keeps blank values valid, so platforms you haven't set up
stay unavailable instead of breaking startup.

Then docker compose up -d and connect the channel in the UI.

The full list of supported platforms

These are the variable names the compose file ships with. Wire up only the
ones you need - the pattern is identical for each: add the variables to
.env, switch the compose file to ${VAR:-}, restart.

Platform	Variables
X (Twitter)	`X_API_KEY`, `X_API_SECRET`
Facebook	`FACEBOOK_APP_ID`, `FACEBOOK_APP_SECRET`
Instagram / Threads	`THREADS_APP_ID`, `THREADS_APP_SECRET`
LinkedIn	`LINKEDIN_CLIENT_ID`, `LINKEDIN_CLIENT_SECRET`
TikTok	`TIKTOK_CLIENT_ID`, `TIKTOK_CLIENT_SECRET`
YouTube	`YOUTUBE_CLIENT_ID`, `YOUTUBE_CLIENT_SECRET`
Pinterest	`PINTEREST_CLIENT_ID`, `PINTEREST_CLIENT_SECRET`
Reddit	`REDDIT_CLIENT_ID`, `REDDIT_CLIENT_SECRET`
Mastodon	`MASTODON_CLIENT_ID`, `MASTODON_CLIENT_SECRET`, `MASTODON_URL`
Discord	`DISCORD_CLIENT_ID`, `DISCORD_CLIENT_SECRET`, `DISCORD_BOT_TOKEN_ID`
Slack	`SLACK_ID`, `SLACK_SECRET`, `SLACK_SIGNING_SECRET`
Dribbble	`DRIBBBLE_CLIENT_ID`, `DRIBBBLE_CLIENT_SECRET`
GitHub	`GITHUB_CLIENT_ID`, `GITHUB_CLIENT_SECRET`
Beehiiv	`BEEHIIVE_API_KEY`, `BEEHIIVE_PUBLICATION_ID`

MASTODON_URL defaults to https://mastodon.social - change it if you're on a different instance. Note BEEHIIVE_* is spelled with the extra "E" in the compose file; copy it exactly.

Postiz supports more platforms than this in its UI. If one you want isn't
listed, check the
configuration reference for its variable names and add them the same way.

Each platform needs an app registered on its developer portal, and each needs a callback URL whitelisted - typically http://localhost:4007/integrations/social/<platform>. Check
docker compose logs postiz for the exact URL Postiz expects if a connection fails.

Start with an easy one

Platforms differ enormously in how much work they take, and it's worth knowing before you sink an afternoon into the wrong one:

Easy - Mastodon, Discord, Reddit, GitHub. Credentials issued immediately, no review.
Moderate - LinkedIn (needs a company page), Pinterest, Slack.
Hard - Facebook, Instagram/Threads, TikTok, YouTube. App review, sandbox restrictions, or business verification.
Paid - X requires a paid API tier for write access. The free tier is read-only, so posting won't work.

If you just want to prove the pipeline works end to end, Mastodon takes about two minutes: Preferences → Development → New application in any Mastodon instance.

These requirements change frequently - treat the grouping above as a starting point and check the current terms on each portal.

Everyday commands

docker compose ps             # status
docker compose logs -f postiz # follow logs, Ctrl+C to quit
docker compose stop           # stop, keeps all data
docker compose up -d          # start
docker compose restart postiz # restart just the app

Data lives in Docker named volumes and survives stop, up -d, restart,
and down.

docker compose down -v deletes the volumes - that erases your account,
posts, and uploads. It's the one command to be careful with.

Troubleshooting and common pitfalls

Pitfall 1: `bash: docker: command not found`

Docker Desktop is installed, but your shell can't find it.

First, check Docker Desktop is actually running. No amount of PATH fixing helps if the engine is down.

If it is running, check whether the CLI is on your PATH:

echo "$PATH" | tr ':' '\n' | grep -i docker

No output means the directory is missing. Find the binary:

ls "/c/Program Files/Docker/Docker/resources/bin/docker.exe"
ls "$LOCALAPPDATA/Programs/DockerDesktop/resources/bin/docker.exe"

Recent Docker Desktop versions may install per-user to
%LOCALAPPDATA%\Programs\DockerDesktop rather than C:\Program Files\Docker. Guides that assume Program Files won't match.

Add whichever path exists to ~/.bashrc. $HOME keeps your username out of it and stays in Unix-style path format, which is what PATH wants:

echo 'export PATH="$PATH:$HOME/AppData/Local/Programs/DockerDesktop/resources/bin"' >> ~/.bashrc
source ~/.bashrc

(If yours is the Program Files install, use
/c/Program Files/Docker/Docker/resources/bin instead.)

Avoid $LOCALAPPDATA here. It expands to a Windows-style path with
backslashes and a drive letter (C:\Users\you\AppData\Local), and a C: in a colon-separated PATH is asking for trouble. $HOME is already
/c/Users/you in Git Bash.

A subtlety worth knowing: even when the directory is correctly registered in your Windows PATH, terminals inherit their environment from explorer.exe, which may hold a stale copy from before the install. Opening a new terminal doesn't always help - a reboot does. Editing ~/.bashrc sidesteps the whole problem.

Note that your project's location on disk is irrelevant here. PATH is a list of absolute directories; where you run the command from doesn't matter.

Pitfall 2: `502 Bad Gateway` when logging in or registering

The page loads, but submitting the form returns nginx's 502.

This means the frontend is fine and the backend is dead.

The postiz container isn't one process - it runs several behind a single
nginx instance:

Process	Port	Role
nginx	5000	front door; routes everything
frontend (Next.js)	4200	the UI you see
backend (NestJS)	3000	the API - `/api/*` proxies here
workers / cron	-	publishing and scheduled jobs

nginx serves the UI happily whether or not the backend is alive. So the page renders, then every API call - login, registration - returns 502.

Check whether the backend is listening:

docker exec postiz ss -tln | grep 3000

If ss isn't in the image, use Node, which is always present:

docker exec postiz node -e "require('net').connect(3000,'127.0.0.1').on('connect',()=>{console.log('backend UP');process.exit(0)}).on('error',()=>{console.log('backend DOWN');process.exit(1)})"

A LISTEN line (or backend UP) → backend is fine; look elsewhere.
No output (or backend DOWN) → backend is down. Find out why:

docker compose logs postiz | grep -i "backend failed" -A 5

Pitfall 3: "All services healthy" but the app is broken

This is the trap that makes Pitfall 2 confusing.

docker compose ps can report every service (healthy) while Postiz is
fundamentally broken. Look at what the compose file's health check actually tests - it fetches http://localhost:5000/, which is nginx. And nginx stays perfectly healthy serving the frontend even when the backend behind it has crashed.

So on this stack, (healthy) means "the web server is up," not "the
application works." When something misbehaves, the port 3000 check above is a far better signal than the status column.

Pitfall 4: Don't remove services to save RAM

The stack runs 8 containers and the Temporal portion looks like overkill for a personal install. Resist trimming it.

temporal-elasticsearch in particular looks optional and is not.
Elasticsearch is genuinely optional for Temporal in general - it powers
"advanced visibility," and Temporal falls back to PostgreSQL without it. But Postiz registers custom Temporal search attributes at startup, and the PostgreSQL visibility store caps Text-type attributes at three. Postiz needs more.

Remove Elasticsearch and the backend dies during initialisation with:

Unable to create search attributes: cannot have more than 3 search attribute of type Text.

...which surfaces to you as a 502 on login, with every service reporting
healthy. The compose file ships these services for a reason.

If you already removed it, restore the original Elasticsearch service, then wipe Temporal's state so it re-initialises consistently:

docker compose down
docker volume rm postiz_temporal-postgres-data
docker compose up -d

That removes Temporal's database only. Your Postiz account and posts live in postiz_postgres-volume and are unaffected.

Check your volume names first - Compose prefixes them with the directory name, so they're postiz_* only if you cloned into a folder called postiz:

docker volume ls | grep temporal

Pitfall 5: `/api/copilot/chat` timeouts in the logs

Harmless. That's the AI assistant feature failing because OPENAI_API_KEY is empty. Ignore it unless you want AI-generated post content, in which case supply a key.

Should you self-host locally at all?

Postiz is the best self-hosted Buffer alternative out there. Local hosting it is a genuinely good way to evaluate Postiz, learn the stack, and draft content without paying for anything. BUT, it is not a good way to hit a posting schedule.

If scheduling reliability matters, the same compose file runs on a small VPS - you'd change MAIN_URL, FRONTEND_URL, and NEXT_PUBLIC_BACKEND_URL to your domain and put a reverse proxy with TLS in front. Everything else transfers unchanged.

A cheap VPS is enough; I've written up which hosts are actually worth signing up for separately, along with the renewal-pricing traps to avoid.

Australian Exchange Rates: A Free Currency Converter API for Developers

Mathias Ahlgren — Tue, 14 Jul 2026 07:44:38 +0000

If you build software for Australian businesses, exchange rates are rarely “just another data point.”

They affect invoice calculations, cross-border e-commerce, tax reporting, accounting workflows, financial reconciliation, and audit trails. For many use cases, you need a reliable source of official Australian exchange rate data, not a scraped webpage or an undocumented feed that could change without warning.

Exchange Rates API provides developer-friendly access to official Reserve Bank of Australia (RBA) exchange rates through simple REST endpoints, historical data, currency conversion, and webhook notifications.

This article explains how to retrieve Australian exchange rates, convert currencies, and avoid inefficient REST polling by using webhooks to be notified when the day’s rates are ready.

Why official RBA exchange-rate data matters

The RBA publishes daily exchange-rate data that is useful for Australian businesses dealing with international currencies. However, accessing that source data directly can be inconvenient because it is published as RSS/XML feeds, and Excel files.

That creates avoidable engineering work:

Scraping HTML is fragile.
Parsing XML and RDF namespaces is cumbersome.
Spreadsheet-based workflows are difficult to automate.
Handling historical data consistently takes time.
Monitoring for the day’s newly published rates adds more complexity.

Exchange Rates API turns that data into clean JSON endpoints built for applications.

The service provides:

Official RBA-sourced currency exchange data
AUD as the base currency
Daily updated rates
Historical data from 2018 onwards
More than 30,000 historical data points
A free starting tier with 300 one-time trial requests and no credit card required
REST API endpoints plus webhooks for eligible plans

Exchange Rates API sources data from the Reserve Bank of Australia, but it is not affiliated with or endorsed by the RBA.

Get your first Australian exchange rate

After getting an API key from the Exchange Rates API dashboard, request the latest rates with the /latest endpoint.

curl https://api.exchangeratesapi.com.au/latest \
  -H "Authorization: Bearer your_api_key_here"

A successful response looks like this:

{
  "success": true,
  "timestamp": 1725080400,
  "base": "AUD",
  "date": "2025-08-31",
  "rates": {
    "USD": 0.643512,
    "EUR": 0.562934,
    "GBP": 0.487421,
    "JPY": 96.8321,
    "NZD": 1.0942,
    "TWI": 60.5
  }
}

If the response contains:

{
  "USD": 0.643512
}

Then 1 AUD equals 0.643512 USD.

Use the API in JavaScript

Here is a minimal JavaScript example using fetch.

const response = await fetch("https://api.exchangeratesapi.com.au/latest", {
  headers: {
    Authorization: `Bearer ${process.env.EXCHANGE_RATES_API_KEY}`
  }
});

if (!response.ok) {
  throw new Error(`Exchange Rates API error: ${response.status}`);
}

const data = await response.json();

console.log(`Rate date: ${data.date}`);
console.log(`1 AUD = ${data.rates.USD} USD`);
console.log(`1 AUD = ${data.rates.EUR} EUR`);

In production, keep your API key in an environment variable or secret manager. Do not put it in browser-side code.

Convert AUD to another currency

A simple conversion is multiplication when the rate is quoted relative to AUD.

For example, to convert an Australian invoice total into USD:

const audAmount = 250;
const usdRate = data.rates.USD;

const usdAmount = audAmount * usdRate;

console.log(`A$${audAmount} = US$${usdAmount.toFixed(2)}`);

If 1 AUD equals 0.643512 USD, then A$250 equals approximately US$160.88.

Depending on your product and reporting obligations, decide explicitly how and when to round monetary values. It is also good practice to retain the original rate, source date, converted amount, and rounding rule alongside every transaction.

That makes later reconciliation and audit work much easier.

Supported currencies

Exchange Rates API supports the currencies published by the RBA, including major currencies and key Asia-Pacific trading currencies:

USD, US dollar
EUR, euro
GBP, British pound sterling
JPY, Japanese yen
CHF, Swiss franc
CAD, Canadian dollar
CNY, Chinese renminbi
KRW, South Korean won
SGD, Singapore dollar
NZD, New Zealand dollar
HKD, Hong Kong dollar
INR, Indian rupee
THB, Thai baht
MYR, Malaysian ringgit
IDR, Indonesian rupiah
VND, Vietnamese dong
PHP, Philippine peso

You can retrieve the latest exchange rates, request historical rates, look up rates for a particular currency, or use the currency conversion endpoint.

The problem with polling for daily rates

A common integration pattern is polling: repeatedly requesting /latest until the day’s rate arrives.

For example:

setInterval(async () => {
  const response = await fetch(
    "https://api.exchangeratesapi.com.au/latest",
    {
      headers: {
        Authorization: `Bearer ${process.env.EXCHANGE_RATES_API_KEY}`
      }
    }
  );

  const data = await response.json();

  if (data.date === new Date().toISOString().slice(0, 10)) {
    console.log("Today's rates are available.");
  }
}, 15 * 60 * 1000);

This works, but it is not ideal.

The RBA targets publication around 4:00 PM Australian Eastern Time on business days. In practice, publication can drift, often landing between 4:00 PM and 5:00 PM, and sometimes later. Rates are not published on weekends or NSW public holidays.

That uncertainty encourages frequent polling. If you poll every 15 minutes over a typical business day, your application can make dozens of requests simply to discover whether a new daily data set exists.

Polling creates several issues:

Wasted API requests: Most calls return data you already have.
Higher quota usage: Repeated calls consume your request allowance.
Delayed processing: Your application only notices a new rate at the next scheduled interval.
More operational complexity: You need schedules, holiday handling, retries, and time-zone logic.
Extra infrastructure work: Background workers and cron jobs run even when no new rates have been published.

For a workflow based on a single daily event, there is a better approach: webhooks.

Use webhooks to get notified instead

A webhook reverses the flow of control.

Instead of your application repeatedly asking, “Are today’s rates ready yet?”, Exchange Rates API notifies your application when it detects that the RBA has published new rates.

You register an HTTPS endpoint, and the API sends a signed HTTP POST request to that URL. This normally happens within ten minutes of publication.

With polling, the flow looks like this:

Your app asks the API whether rates are ready.
The API returns the currently available data.
Your app waits for a scheduled interval.
Your app asks again.
This repeats until the latest daily rates are available.

With a webhook, the flow is simpler:

The RBA publishes new daily rates.
Exchange Rates API detects the new data.
Exchange Rates API sends your application a signed HTTP POST request.
Your application receives and processes the rates immediately.

Webhooks are available on Professional plans and above. REST endpoints remain available, so webhooks are an addition to REST, not a replacement.

A strong implementation uses both:

Webhooks for prompt, event-driven rate updates.
REST endpoints for historical queries, backfills, reconciliation, manual refreshes, and recovery workflows.

What a rate-published webhook looks like

When new rates are available, Exchange Rates API sends JSON to your registered endpoint.

The request includes headers such as:

Content-Type: application/json
X-ExchangeRates-Event: rates.published
X-ExchangeRates-Signature: sha256=<hmac>
X-ExchangeRates-Delivery: <unique-delivery-uuid>
User-Agent: ExchangeRatesAPI-Webhook/1.0

Example webhook payload:

{
  "event": "rates.published",
  "date": "2026-06-23",
  "base": "AUD",
  "rates": {
    "USD": 0.7004,
    "JPY": 113.25
  },
  "delivery_id": "0b9d8f60-a5c3-e1d9-b2f4-a6c83f9c4e2a",
  "timestamp": 1782086400
}

Depending on your subscription configuration, the rates object contains every supported currency or only the currencies you selected.

Once received, your system can immediately:

Store the day’s official rates in a database.
Recalculate customer-facing prices.
Create accounting conversion records.
Update internal dashboards.
Trigger import or export settlement workflows.
Notify finance teams that rates are ready.
Start an end-of-day reconciliation process.

Your endpoint should return any 2xx response to acknowledge that it received the delivery.

Verify webhook signatures, always

Never trust an incoming webhook simply because it reaches your endpoint.

Every Exchange Rates API webhook includes an X-ExchangeRates-Signature header. The signature is an HMAC-SHA256 calculated using the raw request body and your subscription signing secret.

The important detail is that you must verify the exact raw bytes received.

Do not parse the JSON and then serialize it again before calculating the signature. Whitespace or key-order changes can produce a different signature, causing verification to fail.

Here is an Express example that preserves the raw request body:

import express from "express";
import crypto from "node:crypto";

const app = express();

app.post(
  "/webhooks/exchange-rates",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const signature = req.get("X-ExchangeRates-Signature");
    const signingSecret = process.env.EXCHANGE_RATES_WEBHOOK_SECRET;

    const expectedSignature =
      "sha256=" +
      crypto
        .createHmac("sha256", signingSecret)
        .update(req.body)
        .digest("hex");

    const received = Buffer.from(signature || "");
    const expected = Buffer.from(expectedSignature);

    const isValid =
      received.length === expected.length &&
      crypto.timingSafeEqual(received, expected);

    if (!isValid) {
      return res.status(401).json({
        error: "Invalid webhook signature"
      });
    }

    const event = JSON.parse(req.body.toString("utf8"));

    if (event.event === "rates.published") {
      console.log(`Received rates for ${event.date}`);
      console.log(`1 AUD = ${event.rates.USD} USD`);

      // Save rates, enqueue downstream work, or trigger a business workflow.
    }

    return res.status(200).json({ received: true });
  }
);

app.listen(3000, () => {
  console.log("Webhook receiver listening on port 3000");
});

Use a constant-time comparison function, such as Node.js crypto.timingSafeEqual, when comparing signatures.

Design your webhook receiver for production

A webhook endpoint should be secure, fast, and idempotent.

Return a `2xx` response quickly

Your receiver should acknowledge a delivery promptly. If processing is slow, such as recalculating prices across a large catalogue, add the work to a queue and process it asynchronously.

await queue.add("process-exchange-rates", event);

return res.status(202).json({
  queued: true
});

Deduplicate deliveries

Webhooks can be retried if your endpoint does not return a 2xx response. Store and check the delivery_id before processing so a duplicate delivery does not create duplicate records or trigger a workflow twice.

const alreadyProcessed = await deliveries.exists(event.delivery_id);

if (alreadyProcessed) {
  return res.status(200).json({
    received: true,
    duplicate: true
  });
}

await deliveries.save(event.delivery_id);

Store the rate date

The webhook payload includes a date field. Store that date with the exchange-rate data rather than assuming it is the same as your server’s current date.

This matters for:

Historical reporting
Financial audits
Time-zone differences
Delayed deliveries
Reconciliation after downtime

Expect retries

If your endpoint does not return a 2xx response, Exchange Rates API retries the delivery with backoff.

Deliveries that never succeed are dropped after the retry budget is exhausted. If a subscription fails on seven consecutive publications, it is automatically deactivated.

Monitor your webhook receiver and alert on failures. If a subscription becomes inactive, fix the endpoint and re-create the subscription once it is healthy.

Keep a REST fallback

Webhooks are ideal for immediate notification, but a resilient application should still have a recovery path.

For example, an overnight reconciliation job can call /latest or a date-specific endpoint and confirm that the expected daily rate record exists.

This helps protect your workflow against:

Downtime in your own infrastructure
Missed deliveries
Incorrect endpoint configuration
Temporary networking failures
Operational mistakes

Test before waiting for the next rate publication

You should not need to wait until the next business day to validate your webhook endpoint.

Exchange Rates API provides a test endpoint that sends a signed rates.test delivery. The payload is signed exactly like a production webhook, which makes it useful for verifying that:

Your public endpoint is reachable.
You retain and verify the raw request body.
Your signing secret is correct.
Your endpoint returns a 2xx response.
Your event-processing pipeline works.
Your logs and alerts are configured correctly.

Treat test events as non-production data and do not apply them to live financial records.

A practical architecture for AUD exchange-rate workflows

A typical Australian accounting or e-commerce workflow might look like this:

Register a webhook endpoint.
Verify the HMAC signature using the raw request body.
Deduplicate deliveries using delivery_id.
Persist the official AUD base rates and supplied date.
Queue downstream calculations, notifications, or reporting tasks.
Return a fast 2xx response.
Run a periodic REST reconciliation job as a safety net.
Use historical REST endpoints for reports, corrections, and backfills.

This approach gives you timely daily updates without repeatedly calling an endpoint all afternoon.

Start building

If your application needs official Australian exchange-rate data, Exchange Rates API provides a practical route from RBA-published rates to usable application data.

Start with the REST API for current rates, historical data, and currency conversion. When your workflow depends on knowing precisely when daily rates are available, use webhooks and let the update come to you.

One API endpoint, 18 registries: verifying Australian businesses without the SOAP and CSV mess

Mathias Ahlgren — Tue, 07 Jul 2026 01:59:26 +0000

Anyone who has tried to verify an Australian business programmatically knows the pain. There isn't one government source you can call - there are at least half a dozen, each with its own format, its own quirks, and in most cases, no API at all.

Three registries, three different problems

The Australian Business Register (ABR) exposes ABN and GST status through a SOAP/XML web service - usable, but dated, and awkward to integrate into a modern REST stack. ASIC, which holds the actual company registrations, doesn't offer an API at all; it publishes a weekly CSV dump of several million rows. ACNC, the charities regulator, is the same story: no API, just a periodic file export. If your product needs sanctions or AML screening on top of that, you're now also pulling from DFAT's consolidated list and ASIC's banned and disqualified registers separately.

For a compliance, onboarding, or billing workflow that just wants to answer "is this a real, active Australian business, and should I be worried about it," that means building and maintaining several ingestion pipelines before you've written a single line of your actual product.

What AUO does differently

AUO is a REST API (plus an MCP server and webhook layer) built as an Australian business data API that collapses this into one call. Send an ABN, ACN, or company name to a single resolve endpoint, and you get back a canonical record joined from eighteen free government sources, ABR, ASIC, ACNC, ORIC, GLEIF, DFAT and others, instead of a pile of registry-specific responses you have to reconcile yourself.

Getting a key takes under a minute: sign up, generate a key from the dashboard, and you're given a test-prefixed key that returns synthetic sandbox data and a live-prefixed key that hits the real registers, both through the same code path. A first call looks like this:

curl https://api.auo.com.au/v1/resolve \
-H "Authorization: Bearer auo_sk_your_key_here" \
-H "Content-Type: application/json" \
-d '{"abn": "51824753556"}'

The response comes back as a list of candidates rather than a single flat object, each with a match confidence and a canonical block where every field, entity name, ABN, ACN, status, GST registration, is tagged with the register it came from and, where available, an as_of timestamp. A screening block on the same response reports DFAT sanctions and ASIC banned-organisation status as no_match or a flagged hit, and a top-level disclaimer spells out that the record excludes directors, shareholders, and beneficial ownership, because that data simply isn't in Australia's free public registers. A name ABR doesn't recognise returns a normal 200 with an empty candidate list rather than an error, so "not found" and "broken" stay distinguishable.

A few other design choices stand out: conflicts between sources are surfaced rather than silently merged; screening results are always "possible match" or "no match," never "cleared," since a clean result against public data isn't a legal clearance; and bankruptcy-related signals are shown as "petition filed" rather than implying an adjudicated status. There's also a monitoring layer - subscribe to an entity and get a signed webhook when something changes, such as a deregistration or a new sanctions hit, instead of polling on a schedule.

Who it's for

The obvious users are AML/CTF and KYB teams who need to verify and screen a business before opening an account or moving money, and fintechs doing onboarding checks. But the same single call is useful anywhere a business identity needs confirming: e-commerce checkouts validating an ABN for tax treatment, real estate and legal practices running due diligence ahead of the Tranche 2 reforms taking effect from 1 July 2026, or a CRM team wanting to de-duplicate and enrich account records against a source of truth.

Getting started

AUO offers a free sandbox with no card required, returning realistic sample data in the same shapes as the live API, so you can build an integration before paying for anything. Paid tiers start at $49/month for 5,000 calls and 250 watched entities, scaling up to 250,000 calls and 15,000 watched entities on the top tier, with overages treated as a soft cap rather than a hard block.

If you're tired of stitching SOAP calls, CSV parsers, and sanctions lists together yourself, it's worth pointing your next lookup at AUO instead of the registries directly.

I Built a Local Directory Site with Astro, Airtable, and Cloudflare - Here is the Architecture

Mathias Ahlgren — Thu, 18 Jun 2026 23:51:26 +0000

I've built a few local directory sites lately - the "best X in town" kind of thing - and I kept reaching for the same stack: Astro for the frontend, Airtable as the CMS, Cloudflare to host it. After the third one I realised the architecture was the interesting part, not any individual site. So this is a writeup of how the pieces fit together, the decisions that actually mattered, and the two or three gotchas that cost me an afternoon each.

If you're building anything that's mostly structured, read-heavy content - a directory, a catalogue, a "links" site, a small marketplace - this pattern is worth stealing.

Why this stack for a directory

A directory is a particular shape of website. It's a pile of structured records (each listing has a name, a category, some photos, hours, a location) that changes a few times a week, not a few times a second. Visitors read far more than they write.

That shape matters, because it tells you what you don't need. You don't need a PHP runtime and a database doing a query on every single page view to show a list of restaurants that barely changes. That's the WordPress model, and for this job it's mostly overhead - plus a plugin ecosystem you have to keep patched.

What you actually need is three things:

A friendly way to manage the data (ideally one a non-technical client can use).
A build step that turns that data into fast, static HTML.
Somewhere cheap and fast to serve it from.

Airtable, Astro, and Cloudflare map onto those three jobs almost one-to-one. Let's go through each.

The data layer: Airtable as a build-time CMS

The instinct when you hear "CMS" is to reach for something with an admin panel - WordPress, Strapi, a headless SaaS. But for a directory, Airtable is hard to beat, and the reason is purely about the editing experience.

Your content is a table. Listings are rows. Categories are linked records. "Feature this on the homepage" is a checkbox. "Hide this" is unchecking another. That's an interface a client or a virtual assistant can use on day one without you building anything. You get a real relational-ish data model (linked records between listings and categories) and a spreadsheet UI, for free.

The key architectural decision: read Airtable at build time, not at request time. A loader script runs during the build, pulls every table over the Airtable API, and hands the data to Astro to render into static pages. There's no live API call when a visitor hits the site - the content is already baked into HTML.

  Airtable base                 build step                 static output
┌───────────────┐        ┌────────────────────┐        ┌──────────────────┐
│ Items         │        │ loaders/airtable   │        │ HTML in dist/     │
│ Categories    │  ───►  │ • fetch all tables │  ───►  │ • /listings       │
│ Areas         │        │ • links → slugs    │        │ • /place/<slug>   │
│ + images      │        │ • download images  │        │ • /category/<slug>│
└───────────────┘        └────────────────────┘        └──────────────────┘

The consequence you have to design around: a content change only appears after a rebuild. In dev you restart the server; in production you trigger a deploy. That sounds like a limitation, and for some apps it would be - but for a directory that updates a few times a week, it's a perfectly fine trade for never running a database. (More on automating that rebuild later.)

The image gotcha that bites everyone

Here's the one that cost me time, and it's worth the price of the whole article: Airtable's attachment URLs expire. If you fetch a record and hot-link the image URL it gives you, your photos will silently 404 a while later.

So the loader can't reference Airtable's URLs directly. Instead, at build time it downloads every image and self-hosts the local copy. The build pulls the bytes down, drops them in a public folder, and the rendered HTML points at your own domain. Photos become stable and fast, with the side effect that adding a photo (like any content change) needs a rebuild to show up.

If you take one thing from this section: any "use Airtable as a CMS" tutorial that hot-links attachment URLs is quietly broken. Download them.

The frontend: Astro, and designing for reuse

Astro is the obvious fit here because directories are content-first and Astro ships zero JavaScript by default - you only opt into client-side JS where you actually need interactivity (a filter drawer, a map). For a page that's fundamentally "a styled list of records," that means very fast pages out of the box.

But the more interesting decision was structural. After the first build I didn't want to rewrite components every time I started a new directory in a different niche. So I wrote the whole thing in generic primitives and pushed every niche-specific word into one config file.

Nothing in the components or routes says "restaurant." The code talks about:

an Item (the thing you list)
Taxonomies (the ways you categorise it)
an optional Tier (a price level)

What those mean lives entirely in config:

item: {
  singular: 'Place to Eat',
  plural: 'Places to Eat',
  slugBase: 'place',          // detail pages live at /place/<slug>
},
taxonomies: [
  { key: 'cuisine', label: 'Cuisine', plural: 'Cuisines', slugBase: 'cuisine' },
  { key: 'area',    label: 'Area',    plural: 'Areas',     slugBase: 'area' },
  { key: 'tag',     label: 'Tag',     plural: 'Tags',      slugBase: 'tags' },
],

The trick that makes re-skinning safe: keys vs labels

This is the part I'm most pleased with, and it generalises to any config-driven system. Each taxonomy has both a key and a label:

The key (cuisine, area, tag) is a stable internal identifier. The loader and components are wired to it. You never change it once you have content and URLs depending on it.
The label, plural, and slugBase are human-facing. They're what shows in the UI and the URLs. You rename these freely.

So the taxonomy the code calls cuisine can display as "Specialty" and live at /specialty/..., while every component still references the stable cuisine key under the hood. To turn a restaurant directory into a hairdresser one, you change labels - Cuisine → Specialty, Tags → Services, Place → Salon - and rename the matching Airtable tables. No component touched, no route rewritten.

That's the difference between a codebase you reuse and one you fork-and-gut every time. The vertical becomes data, not code.

Dynamic routes from the data

Astro's file-based routing does the heavy lifting. Two dynamic route files cover most of the site:

src/pages/
  [itemBase]/[slug].astro   → a listing's detail page  (/place/the-old-spence)
  [taxonomy]/[slug].astro   → a category browse page    (/cuisine/italian)

Each uses getStaticPaths() to enumerate every listing and every category from the build-time data and emit a static page per record. Combined with the config above, the slugBase values decide the URL shapes - so when you relabel place to salon, the routes follow automatically.

The hosting: Cloudflare, and the "mostly static" hybrid

Here's a nuance people miss: a directory is almost fully static, but not quite. The listing pages, category pages, map, and blog are static HTML. But you usually want a few forms - "submit a business," contact, newsletter - and a form needs something server-side to receive the POST.

The clean answer on Cloudflare is a hybrid. The vast majority of the site is static assets served from the edge. The handful of form endpoints run as server functions (in Astro you mark just those routes with export const prerender = false). So you get static performance everywhere that matters, and a tiny bit of compute exactly where you need it - no more.

Static (edge):  /  /listings  /place/*  /cuisine/*  /map  /blog/*
Server (Worker): /api/submit  /api/contact  /api/subscribe

This keeps hosting costs at rounding-error levels - most of the traffic never touches compute - while still letting the public interact with the site.

Spam protection without CAPTCHA

Those public form endpoints are the one attack surface, so they're worth hardening. I really didn't want to slap a CAPTCHA on real users, so I went with a layered guard that's invisible to humans, cheapest checks first:

Honeypot - a hidden field real users never see. Bots fill every field; if it's populated, the endpoint fakes success and saves nothing.
Timing - a hidden timestamp stamped on page load. Submissions that arrive implausibly fast (bots) or suspiciously stale (replayed pages) are dropped.
Origin check - posts must come from your own domain.
User-Agent check - blocks lazy scripted clients that don't look like a browser.
Per-IP rate limit - using Cloudflare's rate-limiting binding, each IP gets a cap (e.g. 3 per minute per form).

The design detail I like: the bot-shaped rejections (1–4) return a fake success, so a bot gets no signal about what tripped it. Only the rate limit and genuine validation errors show a real message. For most directories this is plenty; you can always add Cloudflare Turnstile on top if you're a bigger target.

Keeping a static site fresh

The obvious objection to "rebuild to publish" is: isn't that annoying? It doesn't have to be. Two patterns solve it:

Build hook + Airtable automation. Create a deploy hook, then add an Airtable automation: "when a record is created or updated → call this webhook." Now editing a listing triggers a rebuild on its own. Edit in the spreadsheet, the site updates a minute later.
Scheduled rebuild. A Cloudflare Cron Trigger (or any CI) that rebuilds hourly/daily.

For a low-edit directory, honestly, deploying by hand when you change something is fine too. But the automation path means "static" never means "manual."

The trade-offs, honestly

No stack is free of them, and pretending otherwise is how you end up with angry comments.

It's a developer's setup. Initial setup and deploy are command-line work - clone, configure, deploy. Day-to-day content editing is all in Airtable and needs no code, but you have to be comfortable getting it running. If you'll never open a terminal, a hosted directory builder is a better fit even at the cost of monthly fees.
Content is build-time. Covered above - great for directories, wrong for anything needing per-request freshness (live inventory, user accounts, real-time anything).
Airtable's free tier has limits. Fine for hundreds of listings; if you're modelling tens of thousands of rows with heavy API traffic, reassess.

For the directory shape specifically, those trade-offs land on the right side of the line for me every time.

Wrapping up

The pattern in one breath: Airtable as a build-time CMS, Astro turning that data into static pages via generic Item/Taxonomy primitives, Cloudflare serving it from the edge with a few server-side form endpoints for the interactive bits. Fast, cheap, owned outright, and - if you do the key/label separation - re-skinnable to any niche without rewriting components.

If you want to build this from scratch, everything above is the blueprint; none of it is secret sauce. If you'd rather not wire up the Airtable loader, the image-download step, the spam guard, and the dynamic routing yourself, I packaged this exact stack as a commercial Astro directory template called LocalFinds - Astro 6, Tailwind v4, Airtable, Cloudflare, with the one-config re-skinning baked in. There's a live demo linked there if you just want to poke at the end result and see whether the architecture feels right before building your own.

Either way - build it or buy it - the stack itself is the takeaway. For read-heavy structured-content sites, this combination is genuinely hard to beat.

Happy building!

How to Set Up a Headless WordPress Site with Astro

Mathias Ahlgren — Thu, 27 Jun 2024 07:26:14 +0000

Here, I'm diving into the exciting world of headless WordPress and Astro. If you're looking to combine the content management power of WordPress with the blazing-fast performance of a static site generator, you're in for a treat. Let's get started!

Introduction

So, what's all this fuss about headless WordPress and Astro? Well, imagine taking WordPress's fantastic content management capabilities and pairing them with a modern, lightning-fast front end. That's exactly what we're doing here!

Headless WordPress means we're using WordPress solely as a backend, handling all our content creation and management. Meanwhile, Astro steps in as our front-end superhero, delivering that content to users with incredible speed and flexibility.

Why bother with this setup? Simple: you get the best of both worlds. Content editors can stick with the familiar WordPress interface, while developers can build a blazing-fast, SEO-friendly frontend using modern tools and frameworks. It's a win-win!

Before we dive in, I've got a hot tip for you: check out AstroWP - headless WordPress starter kit. It's an awesome resource that can jumpstart your headless WordPress project with Astro. While we'll be building our site from scratch in this tutorial, AstroWP is definitely worth exploring if you want to hit the ground running on future projects.

Prerequisites

Before we jump in, let's make sure you've got everything you need:

A WordPress installation (don't worry, we'll cover this)
Basic knowledge of JavaScript and React (we'll be using some React components)
Node.js and npm installed on your machine
Familiarity with the command line (nothing too scary, I promise!)

Got all that? Great! Let's dive in.

Setting Up WordPress

First things first, let's get WordPress up and running:

If you haven't already, install WordPress on your favorite web host. There are tons of great guides out there if you need help with this step.
Once WordPress is installed, log into your admin panel and head to the Plugins section. You need to install a crucial plugin called WPGraphQL. This nifty tool exposes your WordPress data through a GraphQL API, which we'll use to fetch content for our Astro site.
Search for "WPGraphQL" in the plugin directory, install it, and activate it. Easy peasy!
Now, let's create some sample content. Add a few blog posts and pages so we have something to work with. Don't stress about making it perfect – we're just testing things out.

Alright, our WordPress setup is good to go. Time to switch gears and set up Astro!

Setting Up Astro

Now for the fun part – let's get Astro up and running:

Open up your terminal and navigate to where you want your project to live.
Run the following command to create a new Astro project:

   npm create astro@latest

Follow the prompts to set up your project. When asked which template to use, choose the "Empty" (minimal) option from the list.
Once the installation is complete, cd into your new project directory and run:

   npm install

This will install all of the needed dependencies.

   npm run dev

This starts the development server and gives you a local preview of your site.

Open up your browser and navigate to http://localhost:4321. You should see a blank Astro site. Not very exciting yet, but we're about to change that!

Heads up (Astro 6+): If you picked the minimal template and npm run dev throws a ! integrations: Required config error, just add an empty integrations: [] array to your astro.config.mjs. We'll be adding the React integration there in a moment anyway, so this resolves itself in the next section.

Take a moment to explore the project structure. You'll see a src folder with pages and components subdirectories. This is where we'll be spending most of our time.

Connecting Astro to WordPress

Now that we have both WordPress and Astro set up, it's time to introduce them to each other:

First, let's add the React integration. Astro ships with an astro add command that installs the integration, pulls in its peer dependencies, and wires up your config in one step. Run the following and accept the prompts:

   npx astro add react

This automatically updates your astro.config.mjs so it looks something like this:

   import { defineConfig } from 'astro/config';
   import react from "@astrojs/react";

   export default defineConfig({
     integrations: [react()]
   });

If you ever see a Cannot find package 'react' warning when starting Astro, install the peer dependencies manually with npm install react react-dom @types/react @types/react-dom.

Now, we need to set up our environment variables. Create a new file in your project root called .env and add the following:

   WP_URL=https://your-wordpress-site.com/graphql

Replace https://your-wordpress-site.com with your actual WordPress site URL.

Great job! We've now got the groundwork laid for our headless WordPress + Astro site. In the next section, we'll start fetching data from WordPress and displaying it in our Astro site. Exciting times ahead!

Fetching Data from WordPress

Alright, now we're getting to the good stuff. Let's fetch some data from WordPress and display it in our Astro site:

First, let's create a new file in the src/pages directory called index.astro. This will be our homepage.
Open up index.astro and add the following code:

   ---
   const response = await fetch(import.meta.env.WP_URL, {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
     body: JSON.stringify({
       query: `
         query HomePagePosts {
           posts(first: 5) {
             nodes {
               title
               excerpt
               slug
             }
           }
         }
       `
     })
   });

   const json = await response.json();
   const posts = json.data.posts.nodes;
   ---

   <html lang="en">
     <head>
       <meta charset="utf-8" />
       <meta name="viewport" content="width=device-width" />
       <title>My Headless WordPress Site</title>
     </head>
     <body>
       <h1>Welcome to My Blog</h1>
       <ul>
         {posts.map((post) => (
           <li>
             <h2>{post.title}</h2>
             <p set:html={post.excerpt}></p>
             <a href={`/posts/${post.slug}`}>Read more</a>
           </li>
         ))}
       </ul>
     </body>
   </html>

This code does a few things:

It sends a GraphQL query to our WordPress site to fetch the latest 5 posts.
It then takes that data and renders it in a simple HTML structure.

Save the file and check out your Astro dev server. You should now see your WordPress posts displayed on the page!

Pretty cool, right? We're now pulling data from WordPress and displaying it in our Astro site. But we can do even better. In the next section, we'll set up dynamic routing to create individual pages for each of our blog posts.

Creating Dynamic Routes

Now that we've got our posts showing up on the homepage, let's create individual pages for each post:

Create a new file in src/pages called posts/[slug].astro. The square brackets in the filename tell Astro that this is a dynamic route.
Open [slug].astro and add the following code:

   ---
   export async function getStaticPaths() {
     const response = await fetch(import.meta.env.WP_URL, {
       method: 'POST',
       headers: { 'Content-Type': 'application/json' },
       body: JSON.stringify({
         query: `
           query AllPosts {
             posts {
               nodes {
                 slug
               }
             }
           }
         `
       })
     });

     const json = await response.json();
     const posts = json.data.posts.nodes;

     return posts.map((post) => {
       return {
         params: { slug: post.slug },
         props: { slug: post.slug },
       };
     });
   }

   const { slug } = Astro.props;

   const response = await fetch(import.meta.env.WP_URL, {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
     body: JSON.stringify({
       query: `
         query SinglePost($slug: ID!) {
           post(id: $slug, idType: SLUG) {
             title
             content
           }
         }
       `,
       variables: {
         slug: slug,
       }
     })
   });

   const json = await response.json();
   const post = json.data.post;
   ---

   <html lang="en">
     <head>
       <meta charset="utf-8" />
       <meta name="viewport" content="width=device-width" />
       <title>{post.title}</title>
     </head>
     <body>
       <h1>{post.title}</h1>
       <div set:html={post.content}></div>
       <a href="/">Back to Home</a>
     </body>
   </html>

This code does a few important things:

The getStaticPaths function fetches all post slugs from WordPress and tells Astro to create a page for each one.
We then fetch the specific post data for each page and render it.

Now, if you click on the "Read more" links on your homepage, you should be taken to individual post pages!

Awesome work! We've now got a fully functional headless WordPress site built with Astro. Of course, there's always room for improvement. In the next sections, we'll look at styling our site and optimizing its performance.

Styling Your Astro Site

Now that we've got our content displaying correctly, let's make it look a bit nicer:

Astro supports several styling options out of the box. For this tutorial, we'll use Astro's built-in CSS support.
Create a new file in src/styles called global.css.
Add some basic styles to global.css:

   body {
     font-family: Arial, sans-serif;
     line-height: 1.6;
     color: #333;
     max-width: 800px;
     margin: 0 auto;
     padding: 20px;
   }

   h1, h2 {
     color: #2c3e50;
   }

   a {
     color: #3498db;
     text-decoration: none;
   }

   a:hover {
     text-decoration: underline;
   }

Now, let's import this CSS file in our pages. In both index.astro and posts/[slug].astro, add this line in the <head> section:

   <link rel="stylesheet" href="/styles/global.css" />

Refresh your browser, and you should see a much nicer-looking site!

Remember, this is just a starting point. Feel free to expand on these styles and make the site your own!

Optimizing Performance

One of Astro's big selling points is its focus on performance. Let's take advantage of some of Astro's features to make our site even faster:

Astro uses partial hydration, which means it only sends JavaScript to the browser when it's needed. This is great for performance, but we haven't actually used any client-side JavaScript yet. If you need interactivity, you can use Astro's client directives like client:load or client:idle on your components.
For image optimization, Astro has a built-in Image component. Let's use it for our post thumbnails. First, install the sharp package:

   npm install sharp

Before we can render a thumbnail, we need to actually fetch the featured image data. Update the GraphQL query in your index.astro to include the featuredImage field:

   query HomePagePosts {
     posts(first: 5) {
       nodes {
         title
         excerpt
         slug
         featuredImage {
           node {
             sourceUrl
           }
         }
       }
     }
   }

Then, in your index.astro file, import the Image component and use it for your post thumbnails:

   ---
   import { Image } from 'astro:assets';
   // ... rest of your frontmatter code
   ---

   <!-- In your HTML, inside the posts.map() loop -->
   {post.featuredImage && (
     <Image
       src={post.featuredImage.node.sourceUrl}
       width={300}
       height={200}
       alt={post.title}
       inferSize
     />
   )}

Note: Remote images from WordPress need their domain authorized in astro.config.mjs under the image.domains (or image.remotePatterns) setting before Astro will optimize them.

Astro also automatically optimizes your CSS and HTML. It removes unused CSS and minifies your HTML in production builds.

Deployment

We're in the home stretch! Let's get your site deployed:

First, build your site with:

   npm run build

This will create a dist folder with your production-ready site.
You can deploy this folder to any static hosting service. Netlify, Vercel, and Cloudflare Pages are popular options that work great with Astro.
If you're using Netlify, you can simply drag and drop your dist folder onto their site to deploy.
For automated deployments, you can set up a GitHub repository for your project and connect it to your hosting service. Then, every time you push to your main branch, your site will automatically rebuild and deploy.

Summary

And there you have it! We've successfully set up a headless WordPress blog with Astro. We've covered everything from initial setup to deployment, touching on data fetching, routing, styling, and performance optimization along the way.

Remember, this is just the beginning. There's so much more you can do with this setup. You could add custom post types, implement search functionality, or even turn your site into a full-fledged e-commerce platform.

I hope this tutorial has been helpful and has sparked some ideas for your own projects. Happy coding!

Troubleshooting Common Issues

Before we wrap up, let's quickly address some common issues you might run into:

CORS errors: If you're getting CORS errors when trying to fetch data from WordPress, you may need to install a CORS plugin in WordPress or configure your server to allow cross-origin requests.
GraphQL errors: Double-check your query syntax if you're getting GraphQL errors. The WPGraphQL plugin provides a GraphiQL interface in the WordPress admin panel where you can test your queries.
Astro build problems: If you're having issues building your Astro site, make sure all your dependencies are up to date. You can also try clearing your .astro cache folder.

Remember, the Astro and WordPress communities are very helpful. If you run into any issues you can't solve, don't hesitate to reach out for help!

P.S. if you haven't already, you definitely need to check out EmDash, a CMS built on Astro and Cloudflare.

This article has been updated from its original version. Changes include: clarifying the "Empty" (minimal) Astro template name, switching React setup to the recommended npx astro add react command, adding a fix for the Astro 6 integrations: Required error, and correcting the featured-image example to fetch the featuredImage field it relied on.

DEV Community: Mathias Ahlgren

How to Replace a Google Form With a Real HTML Form on Your Site

Why the iframe is the problem

The clever workaround, and where it breaks

Replacing it properly

Sending people somewhere after submit

Keeping the spreadsheet

Spam, which Google was quietly handling

When to keep Google Forms

The migration, start to finish

How to Add a Contact Form to a Static HTML Site (Without a Backend)

Full disclosure

The options for handling forms without a backend

Step 1: The HTML form (accessible by default)

Step 2: Enhance it with JavaScript (proper loading and error states)

Step 3: Framework examples (complete, not placeholders)

React

Next.js (App Router)

Vue 3

Astro

Svelte

Step 4: Redirect vs. AJAX, pick your success flow

Stopping spam without CAPTCHA

Common errors (and how to fix them)

Choosing a service

Wrapping up

How to Install Postiz on a Local Windows Machine with Only Docker Desktop

⚡ Read this first: the local-hosting caveat

What you need

Step 1 - Install and start Docker Desktop

Step 2 - Get the compose file

Step 3 - Set a real JWT secret

Step 4 - Start it

Step 5 - Wait for it to actually be ready

Step 6 - Close registration

Step 7 - Keep secrets out of version control

Step 8 - Connect social channels

The full list of supported platforms

Start with an easy one

Everyday commands

Troubleshooting and common pitfalls

Pitfall 1: bash: docker: command not found

Pitfall 2: 502 Bad Gateway when logging in or registering

Pitfall 3: "All services healthy" but the app is broken

Pitfall 4: Don't remove services to save RAM

Pitfall 5: /api/copilot/chat timeouts in the logs

Should you self-host locally at all?

Australian Exchange Rates: A Free Currency Converter API for Developers

Why official RBA exchange-rate data matters

Get your first Australian exchange rate

Use the API in JavaScript

Convert AUD to another currency

Supported currencies

The problem with polling for daily rates

Use webhooks to get notified instead

What a rate-published webhook looks like

Verify webhook signatures, always

Design your webhook receiver for production

Return a 2xx response quickly

Deduplicate deliveries

Store the rate date

Expect retries

Keep a REST fallback

Test before waiting for the next rate publication

A practical architecture for AUD exchange-rate workflows

Start building

One API endpoint, 18 registries: verifying Australian businesses without the SOAP and CSV mess

I Built a Local Directory Site with Astro, Airtable, and Cloudflare - Here is the Architecture

Why this stack for a directory

The data layer: Airtable as a build-time CMS

The image gotcha that bites everyone

The frontend: Astro, and designing for reuse

The trick that makes re-skinning safe: keys vs labels

Dynamic routes from the data

The hosting: Cloudflare, and the "mostly static" hybrid

Spam protection without CAPTCHA

Keeping a static site fresh

The trade-offs, honestly

Wrapping up

How to Set Up a Headless WordPress Site with Astro

Pitfall 1: `bash: docker: command not found`

Pitfall 2: `502 Bad Gateway` when logging in or registering

Pitfall 5: `/api/copilot/chat` timeouts in the logs

Return a `2xx` response quickly