Ollastack: forms, mailboxes and email testing — built for your AI agents.

#The setup: form backends were built for browsers, then agents started showing up

Every team that has shipped a public website in the past decade has eventually bought a form backend. The category exists because building the form-handling pipeline yourself — receive the POST, validate the body, send the notification email, store the row, surface the geolocation, gate the spam, integrate with whatever downstream tool your team uses — is a surprising amount of engineering work that almost nobody wants to do in-house. Vendors emerged to solve it: Formspree, Getform, Basin, Web3Forms, Formcarry. They are all genuinely well-built products. They were also all designed for the same caller: a human filling out a form in a browser.

The defences a form backend ships make sense for that caller. CAPTCHA, honeypot, IP-based rate limits, anomaly detection on submission patterns, "this looks like a bot" heuristics. The defences are calibrated to a particular shape of attack — a script firing thousands of submissions per minute from a rotating IP pool — and they catch that attack reasonably well. The cost is that they also catch legitimate non-browser callers, because legitimate non-browser callers look very similar to scripted attacks if all the backend has to go on is "did the request come from a regular browser."

In 2026, legitimate non-browser callers are no longer the edge case. Every product team is shipping at least one workload where an AI agent — Claude Desktop, Cursor, an in-house automation, a customer-facing agent in someone else's product — needs to submit to a form on behalf of a user or in its own right. The use cases are routine: an agent qualifying inbound leads through your contact form, an agent registering itself for a service trial, an agent applying for a job on a candidate's behalf, an internal agent submitting an expense report. The volume is small individually and meaningful collectively. The existing form backends mostly do not see this traffic; what they see is "an anomalous submission" and they reject it.

The agent operators who actually run this traffic have a corresponding pain. The submissions get dropped. The submissions that do go through land in the customer's inbox flagged as spam. The customer's manual triage burden goes up because every legitimate agent submission has to be confirmed and rescued from the spam folder. The agent operator either rebuilds the form integration each time the receiving vendor changes its detection rules, or gives up and uses a different submission path that the receiver explicitly trusts.

Ollastack exists because the founders watched their own internal agent workloads run into this wall, then watched the broader market of agent operators run into the same wall, and decided to ship the form backend the agent-era needs from the ground up. The bet was simple: treat agents as first-class trusted callers when they are authorised, and treat anonymous traffic with the same browser-defences the category already ships. No compromises in either direction.

#What Ollastack actually is, in one paragraph and then in detail

Ollastack is a cloud-operated backend that runs as a managed SaaS service. The capability surface is three things behind one OpenAPI spec: form endpoints that accept submissions with GEO auto-stamping and agent-aware authentication; real mailboxes your agents own and operate over the API (send, receive, reply, read OTPs); and disposable test inboxes for CI workflows that need to verify signup-and-OTP flows end-to-end. There is nothing to install on the customer side; the platform runs on Ollasoftware's own infrastructure and the customer interacts with it through a Bearer-authed REST API, a dashboard, and SDKs for the common languages.

The form endpoint surface is the most-used of the three and the one that customers usually adopt first. Each form has its own endpoint slug. Submissions POST to that slug as either JSON or form-urlencoded, get validated against the form's schema, get GEO-stamped with country / city / region / lat-long / timezone server-side, and produce one row per submission plus one notification email to the form's configured recipient list. The schema and the recipient list and the spam filter and the integration fan-out are all configurable per form, and every configuration change is recorded in the form's audit log.

The mailbox surface gives the customer real, full-fidelity email addresses that an agent can own and operate. The agent picks an identity (`[email protected]`, for example), the platform provisions the mailbox, and the agent can send from it, receive into it, reply within it, and read OTPs delivered to it — all over the API. Inbound is spam-filtered so the mailbox stays clean. Outbound goes through the platform's deliverability infrastructure with the customer's verified sender domain. The mailbox is the primitive that lets an autonomous workflow do email-shaped things without needing a separate ESP integration.

The test-inbox surface handles the CI workflows that verify signup-and-OTP flows. Disposable inboxes at `*@test.ollastack.com` accept any inbound mail, expose a `wait` endpoint that long-polls for the next message, and parse OTP codes out of the body so the CI test can assert against the actual delivered token rather than guessing. Unfiltered by design — a CI test wants to see every message, including the ones a production mailbox would filter as spam.

Underneath all three surfaces is one token system, one audit log, one billing meter, and one OpenAPI 3.1 specification at `/api/openapi.json` — CORS-open so an agent connecting to the platform can read its own contract without the customer copy-pasting a doc page into the agent's tool registry.

#Agent-first authentication and the trust model

The architectural decision that distinguishes the platform most clearly is the agent-first token model. Two kinds of caller are recognised: human callers (browsers, unauthenticated form fills, the public submit-without-a-token path) and agent callers (anything that arrives with a valid Bearer token). The platform applies different defences to each.

For human callers, the standard browser-form defences apply: honeypot fields, CAPTCHA when configured, IP-based rate limits, allowed-origin checks for browser submits, anomaly detection on submission patterns. These are the same defences the established form backends ship, calibrated for the same kind of attack. Anonymous spam submissions fail the gauntlet; legitimate browser submissions pass through.

For agent callers, the contract is different. The customer signs in, mints an agent-typed token in the dashboard, gives it a clear label (`Claude Desktop`, `Cursor`, `internal-script`, `intern-form-proxy`), and hands it to the agent. From the platform's perspective, requests arriving with that token are trusted — they skip the spam-detection layer designed for anonymous traffic — and from the customer's perspective, every call the agent makes lands in the inbox tagged with the agent's label and recorded in the audit log. The customer can revoke the token from the dashboard in one click if the agent misbehaves; the audit log lets the customer see exactly what the agent did before the revocation.

The contract scales naturally. One human, many agents. Each agent has its own scoped token; each token has its own audit trail; each submission is attributable to a specific agent rather than to "the account." For teams running multiple agent workloads — Claude Desktop for ad-hoc work, an internal script for nightly automation, a customer-facing agent in another product that submits on the customer's behalf — this attribution is the difference between "we had a spike of unexpected submissions, which agent was that" and "we had a spike, here is the agent that fired it, here is its label, here is its owner, here is its history."

The agent-first model is enforced at the platform level, not by convention. The CreateForm and the submission endpoints both honour the agent-typed token cleanly. The dashboard's inbox view stamps agent submissions visibly. The audit log records the calling identity unambiguously on every mutation. Account registration is protected by a human-verification challenge, so an autonomous agent cannot self-onboard, open an account, or start a subscription — the account is always a human's, the agent operates within an account a human owns. The clarity of this ownership model is one of the small structural reasons the platform plays well in production deployments where the legal team has opinions.

#GEO auto-stamping: every submission, every row, no client-side code

Every form submission that lands on the platform is automatically enriched with the submitter's country, city, region, latitude, longitude, and timezone — derived server-side from Cloudflare visitor headers, with no client-side geo libraries required, no IP-lookup integration to wire, and no privacy-policy overhead the customer would have to add for the equivalent client-side capture.

For a sales team, this is the line item that transforms inbound leads from "another row in the spreadsheet" to "another row in the spreadsheet with the country and the city already attached." Routing rules become trivial — leads from India to the India desk, leads from the EU to the EU desk, leads from the US to the US desk. Personalisation becomes trivial — the AE responding has the city in front of them before the conversation starts. Lead-prioritisation scoring becomes trivial — leads from cities and countries the team converts well in get scored higher automatically.

For a recruiting team, the same enrichment turns inbound applications into a structured pipeline by geography. The team doesn't need to add a "where are you based" field to the form; the platform already knows. For a customer-support team, the timezone stamp answers the "when should we respond, and from which region's on-call rotation" question without any extra work. For a content-marketing team running A/B tests, the GEO data gives the analytics view the dimension it needs to disentangle geographic effects from creative effects.

The enrichment runs on every submission whether the submitter is a human in a browser or an agent calling the API. For agent submissions specifically, the timezone and city are also useful as a sanity check — an agent operating on behalf of a customer in Bengaluru should be submitting from a network path that resolves to a plausible geography; an agent submitting from an unexpected geography is one signal among several that the agent may have been compromised. The audit log captures the GEO stamp on every row so the customer can run these sanity checks across the corpus rather than per-submission.

#Real mailboxes your agents own — send, receive, reply, read OTPs

The mailbox surface is the second pillar of the platform and the one that most distinguishes it from the established form-backend category. The classical form backend stops at "we received the submission; here is the notification email; goodbye." The platform extends past that into a full bidirectional mail surface that an agent can operate over the API.

Mailbox creation is one POST. The customer (or the agent, with a properly-scoped token) sends a `POST /api/mailboxes` with a chosen handle (`support`, `sales`, `careers`, `noreply-bot`), and the platform provisions a real mailbox at `@` (when the customer has verified a sender domain — `[email protected]` is the canonical example from inside the Ollasoftware portfolio). The mailbox can send (`POST /api/mailboxes/{id}/send`), receive (inbound is spam-filtered, exposed via `GET /api/mailboxes/{id}/messages`), reply (`POST /api/mailboxes/{id}/messages/{messageId}/reply`), and wait for the next inbound (`GET /api/mailboxes/{id}/wait?timeout=55` — long-polls for up to 55 seconds, returns the next message when it arrives).

The OTP-reading capability is the one that turns the mailbox into a workflow primitive rather than just an email gateway. An agent that needs to complete a signup flow at a third-party service can mint a mailbox, point the third-party signup at the mailbox's address, wait on the platform's `wait` endpoint, read the OTP out of `codes[0]` in the returned message, and submit it back to the third-party service — all without a human in the loop. The same primitive runs in CI tests against the customer's own product, against external services for automation flows, and against the kind of inbox-as-authenticator workflows that turn out to be surprisingly common in production agent workloads.

For autonomous customer-support workflows, the mailbox is the substrate for the canonical agent-as-CS pattern. The agent owns a `[email protected]` mailbox, polls for inbound, classifies and replies to routine queries, and escalates anything outside its competence to a human handler. The replies go out from the same identity the customer initially wrote to, so the conversation thread stays coherent. The audit log records every send, every receive, every reply, with attribution to the specific agent token that performed the action.

The webhook surface is the asynchronous counterpart. The customer registers a webhook URL, the platform fires HMAC-SHA256-signed events for inbound mail, send completion, delivery status changes, and ingest failures, and the agent responds when the event arrives rather than polling. The webhook contract is the same shape as the rest of the platform — idempotency-key headers, replay protection, retry with exponential backoff on customer-side failure.

“ An agent that needs to complete a signup flow at a third-party service can mint a mailbox, point the third-party signup at the mailbox's address, wait on the platform's wait endpoint, read the OTP, and submit it back — all without a human in the loop.

#Test inboxes for CI: signup-and-OTP flows that actually verify the email

The third capability is the one most teams discover after they have already standardised on the platform for forms or mailboxes. Disposable test inboxes at `@test.ollastack.com` accept any inbound mail without any of the spam-filtering that production mailboxes apply, expose the same `wait` and `messages` endpoints, and let CI tests assert against real delivered email rather than against mock fixtures.

The use case is canonical for any product that has a signup-and-verify flow. The CI test mints a test inbox, fires the signup form with the inbox's address, waits for the verification email, reads the OTP or the magic-link token out of the body, completes the verification, and asserts that the resulting account is in the correct state. The whole flow runs end-to-end against the actual mail-delivery infrastructure rather than against a mock that pretends to deliver. Bugs in the delivery path, the template, or the parser get caught at CI time rather than at "a customer reports their verification email never arrived" time.

The same primitive applies to the password-reset flow, the two-factor enrolment flow, the email-change-confirmation flow, the invoice-attachment delivery flow, and the various transactional emails the average product fires at users over its lifecycle. Each of these is a flow most teams cover with a mock that pretends to deliver because the alternative — running real email through a real provider — was historically painful to wire up in CI. The platform's test inbox makes the alternative cheap; the CI test owns its inbox, the platform handles the delivery, the assertion fires against the real message.

Unfiltered by design is the deliberate choice. A production mailbox filters spam because the user doesn't want to see spam; a CI test wants to see everything, including the spam-classified messages, so the test can validate behaviour against the full inbound surface. The test inboxes default to unfiltered, retain messages for a configurable window, and expose a bulk-delete primitive so the CI test can clear the inbox between runs.

#One endpoint, five ways to call it: the developer experience

A submission to a form endpoint can come from any of five common callers, and the platform treats all five identically as long as the request is shaped reasonably. The docs ship this multi-tab pattern verbatim so the customer can see the contract from whichever caller they happen to be wiring.

Agent (Bearer-authed). One cURL line with the agent token in the Authorization header. The submission lands in the inbox tagged with the agent's label, every call is recorded in the audit log, the geography is auto-attached. This is the canonical call for an automation that owns its own token and operates on its own behalf or on a user's behalf.

cURL (anonymous). The same endpoint without a Bearer token. The platform applies the standard anonymous-caller defences (honeypot if configured, CAPTCHA if configured, IP-based rate limit, allowed-origin check if configured) and accepts the submission if it passes. This is the canonical call for the team that wants to test the form from the command line without minting a token, or for a public web form whose customer happens to be using cURL.

fetch (JavaScript in a browser). One `await fetch()` with a JSON body. The platform handles the CORS preflight cleanly when the allowed-origins list includes the calling page. This is the canonical call for a custom React component or a vanilla-JS form that wants to handle the submission asynchronously without a full page redirect.

HTML form (server-rendered submission). A standard `

#Integrations and the OpenAPI surface

The platform connects directly to Gmail, Google Sheets, Notion, Slack, HubSpot, Mailchimp, and a small set of other first-party-supported destinations, plus 1,000+ more via the standard automation platforms — Zapier, Make, n8n, Activepieces. Every submission can fan out to any combination of these destinations through the integration surface, configured per-form, with the same audit-log discipline that applies to the rest of the platform.

For the integrations the customer needs but the platform does not natively support, the webhook surface is the escape hatch. The customer points a webhook at any HTTP endpoint, the platform fires HMAC-SHA256-signed events on every submission, and the receiver handles the routing. Webhook deliveries are retried with exponential backoff on customer-side failure, idempotency-key headers prevent double-processing, and the webhook delivery log records every attempt with the receiver's response code so the customer can debug failed deliveries without polling.

The OpenAPI 3.1 specification is the canonical contract for any caller that wants to integrate at depth. The spec is published at `/api/openapi.json`, served with CORS open so an agent can fetch it directly, and kept in lockstep with the API itself. The OpenAPI surface is what makes the MCP-like integration patterns possible — an agent can read the spec, generate tool definitions for its own runtime, and operate the platform without any custom integration code. The SDKs the platform ships are themselves auto-generated from the same spec, which is one of the reasons the SDKs stay in sync with the API without separate engineering investment.

For teams that prefer the more conventional integration pattern, the platform ships SDKs for TypeScript / JavaScript, Python, and PHP, with the corresponding ecosystem hooks (React, Vue, Next.js, Astro for the JS side). The SDKs handle the auth header, the GEO stamp, the multi-value field handling, the streaming responses for long-running operations, and the conventional ergonomics each language expects.

#Two-minute onboarding and the canonical setup

The published onboarding ritual takes about two minutes. Step one: sign up at the dashboard, click Create form, name it. The endpoint URL is yours immediately — no review queue, no approval gate, no waiting for a vendor SDR to schedule a setup call.

Step two: mint an agent token. Dashboard → Settings → API tokens → New agent token. Give it a label so you remember what it is for. Copy the credential immediately because the platform shows it once. Hand it to the agent that needs to operate the form.

Step three: the agent POSTs. One Bearer-authed POST against the endpoint URL and the submission lands in the inbox tagged with the agent's label, with every call written to the audit log, with the geography auto-attached. The agent operator can see the submission in the dashboard within seconds; the customer can see the notification email in their inbox within tens of seconds (depending on the configured delivery path).

For teams that want more sophisticated setup — schema configuration with custom field types, recipient lists with multiple notification addresses, allowed-origin lockdown, CAPTCHA enrolment, autoresponder configuration, Razorpay payment-block wiring — the same dashboard exposes every setting, and the API exposes every setting as a corresponding endpoint. The pattern the team encourages is: start with the two-minute happy path, iterate the configuration as the use case matures, never feel obligated to configure everything before shipping the first integration.

#How Ollastack compares to the established form backends

The form-backend category has a clear set of incumbents and it is worth being direct about how the platform sits against each.

Formspree is the closest peer for the classical use case (a small team that wants a form backend without engineering the pipeline themselves). Formspree is genuinely well-built within its scope, has a long track record, and is the right answer for the team that needs nothing more than the form-handling surface. Ollastack extends past Formspree on three axes: the agent-first authentication and trust model, the mailbox surface that goes beyond notification to full bidirectional mail, and the test-inbox surface for CI. For the team that needs any of those three, Ollastack is the better fit; for the team that genuinely needs only the form-backend slice, Formspree is reasonable.

Getform, Basin, Web3Forms, Formcarry are the broader mid-tier of form-backend vendors. They all do the basic surface competently and stop there. The platform's extension over each of them is the same as over Formspree — agent-first auth, mailboxes, test inboxes, GEO auto-stamping — plus the OpenAPI-first developer experience that distinguishes a product an agent can drive itself from a product that requires the customer to write a custom integration.

For the mailbox surface, the closest peers are Mailgun, Postmark, SendGrid (the established transactional email senders) plus the inbox-side products like Mailtrap and Mailpit. The platform sits in the middle — the customer gets the sending capability that the transactional ESPs ship plus the receiving and replying capability that the inbox-side products ship, in one product with one bill. For teams that need only one half of the surface, the specialist products may have more depth on that half; for teams that need both sides, the platform is the consolidated alternative.

For the test-inbox surface, the closest peers are Mailtrap, Mailpit, MailHog, and the various CI-focused tools that solve the "verify the OTP in a test" problem. The platform's extension is that the test inboxes share the same OpenAPI surface and the same token system as the form-backend and mailbox surfaces, so the test inbox is a primitive within the platform rather than a separate vendor relationship.

Across all of these, the question is rarely "is the platform cheapest for the specific slice I am buying." It is "for the workload I am actually building — which may today involve forms but will eventually involve mailboxes, may today involve mailboxes but will eventually involve test inboxes, may today involve human-only callers but will eventually involve agents — is the platform that handles all of those today a better fit than a stitched-together stack of single-purpose vendors." For most product teams in the small-to-mid-market range, the answer is yes.

#The team and the origin story

Ollastack is built and operated by Ollasoftware, the AI software development company headquartered in Bengaluru that has shipped more than forty AI brands in production over the last four years. The platform was previously known as form4dev and was operated as a developer-friendly form backend in roughly the shape Formspree occupies — a competent form-backend with thoughtful developer ergonomics but recognisably within the established category.

The rebrand to Ollastack happened as the agent-first positioning became the canonical story for the platform. The same backend infrastructure runs underneath; the URL, the docs, the marketing, and the conceptual centre of gravity all shifted to reflect the reality that agent traffic had become the primary growth segment of the platform's usage. The legacy login.form4dev.com hostname still alias-redirects to login.ollastack.com so existing customer integrations continue to work without breakage. The endpoint slugs, the token formats, and the API contract are unchanged.

The team behind the rebrand is the same team that ships Ollastack today — the Ollasoftware engineering group that operates the broader portfolio's backend infrastructure. The platform shares its operational substrate (async-Rust services, Postgres for the relational store, ClickHouse for the analytics-shaped queries, Caddy for the edge) with OllaDNS, 24observe, and Qcrawl. The shared substrate is the reason the team can ship the breadth of the platform with a small headcount; the architectural patterns and the operational tooling carry across the four products.

The parent group, Networkers Home, is the cybersecurity and networking training institute that has placed more than forty-five thousand alumni across eight hundred hiring partners since 2007. The institutional context matters here specifically because the trust primitives the platform ships — audit logs, scope-typed tokens, attribution discipline, deliverability-grade outbound mail — are exactly the disciplines that the institute has been teaching its alumni for two decades. The product's posture toward verification, attribution, and replay-safe operations is anchored on that disciplinary heritage.

#What is on the roadmap

The team publishes the roadmap and the changelog at the docs site and updates them as work ships. The visible near-term threads are concrete: expanded SDK coverage (Go and Rust are next after the current TypeScript, Python, PHP set), deeper integration with the agent runtimes (LangGraph, Mastra, AG2 native integrations so the platform appears as a tool category in those frameworks rather than as a custom integration), an expanded webhook event catalogue covering the asynchronous operations teams currently have to poll for, and a Slack-side rich-card integration so submission notifications can be triaged and replied to from within Slack without context-switching.

Underneath those visible features is steady investment in the OpenAPI surface. The spec is the canonical contract; every new endpoint ships with its spec entry, every existing endpoint's contract is regression-tested against the spec, and the spec's "x-required-scopes" metadata is the source of truth for the scope-check that the auth layer enforces. The roadmap is to continue extending the metadata surface so agents reading the spec can make smarter decisions about which scope to request, which retry behaviour to apply, and how to recover from specific error shapes.

On the mailbox side, the roadmap focuses on the long-form mail surface: thread-aware reply handling so an agent can reply within a thread rather than firing a new conversation each time, multi-attachment ingest with content-type-aware extraction, and a structured "this message contains an OTP, here are the candidates with confidence scores" surface that goes beyond the current `codes[]` extraction. The principle is to keep extending the mailbox primitive in ways that map to real production workflows rather than to general-purpose feature surface.

Pricing during the current phase is the published per-form, per-mailbox, and per-test-inbox model, with the same "every feature on every plan" principle that the rest of the Ollasoftware portfolio observes. The team has signalled that the unit economics will stay competitive and that the free-tier capability surface is unlikely to shrink. The principle remains consistent: a platform whose pricing only goes up loses customers as fast as it adds them.

#How to start

If you ship a product that has a form on it, or that needs an agent to operate email-shaped workflows, or that has a CI test suite that currently mocks the email-verify path because real-email-in-CI was historically painful, the right next move takes about ten minutes. Sign up at ollastack.com, create your first form, copy the endpoint URL into your site's ``, and verify that the submission lands in your inbox with the GEO stamp attached.

For agent workloads specifically, the second step is to mint an agent-typed token, hand it to the agent runtime you operate (Claude Desktop via MCP, Cursor via its API mode, the OpenAI Assistants surface, or a custom Bearer-authed call), and verify that the agent's submission lands in the inbox tagged with the agent's label rather than dropped at the spam-detection layer. The five-snippet docs page makes this verification trivial; pick the tab for the runtime you operate, copy the snippet, run it.

For mailbox workflows, the third step is to mint a mailbox for the workflow that needs it (the canonical first deployment is `noreply-@` for the workflow that sends transactional mail), wire the relevant inbound webhook for the workflow that needs to receive, and verify that round-trip mail works end-to-end. The OpenAPI spec, the docs, and the SDKs cover the full surface; most teams have a working integration within a half-day of starting.

If you would like the team to walk you through a specific deployment — high-volume agent traffic, regulated-vertical compliance requirements, a custom integration the platform does not natively support — the Ollasoftware contact page reaches the engineers who built the platform directly.