Form builder API

One form contract, from browser to backend.

Render native fields with a publishable key. Read published schemas and responses, export data, and manage settings or webhooks from your server with a scoped workspace key.

responses.ts
const response = await fetch(
  "https://fillo.so/api/v1/manage/forms/product-feedback/responses",
  {
    headers: {
      Authorization: `Bearer ${process.env.FILLO_API_KEY}`,
    },
  },
);

const { data, nextCursor } = await response.json();

Key boundary

Publishable in the browser. Secret on the server.

pk_ publishable key
Resolve and submit a published form.
fsk_ workspace key
Read forms and responses from a trusted backend.

Define and publish

Keep structure in the editor or in a typed defineForm schema, then stage changes before they reach respondents.

  • Versioned form definitions
  • Server-side schema validation
  • Human review before publish

Render and submit

The browser gets only the public capability it needs. Your route, components, account context, and after-submit behavior stay in your app.

  • React and DOM SDKs
  • Native controls, no iframe
  • Signed respondent context

Read and hand off

Use scoped server credentials to list responses, export data, or connect downstream systems without exposing management authority.

  • Keyset pagination
  • CSV exports
  • Signed webhook delivery

Form builder API questions

Can I create and update forms through the API?

Use the CLI or MCP tools to create, stage, and publish form schemas from a trusted environment. The management API reads published forms and responses and manages settings and webhooks. Browser renderers use a publishable key and cannot perform secret management operations.

Can an fsk_ API key go in a React app?

No. Workspace secret keys are server-only and the management routes are not CORS-open. Use a pk_ publishable key with the React or DOM renderer in the browser.

Does the API replace the form SDK?

No. The API manages forms and responses. The React and DOM SDKs render and submit native controls inside the product.

When is a submission endpoint enough?

Use a plain endpoint when you already own the form, validation, uploads, schema changes, and response workflow. Fillo is useful when those pieces should share one maintained contract.

Build one real form and follow it to the first response.

Start with the schema and route you need. Review the generated form before it goes live, then test the exact path a respondent will use.

Build an API-backed form