Form Builder APIs, and When You Do Not Need One

What a form API usually solves

Developers often ask for an API because they need one of three things. They may need to build forms from code. They may need to read submissions in another application. They may need to start a workflow after a visitor submits a form.

An HTTP API addresses each need through a remote contract. Your application authenticates, makes a request, handles pagination, and deals with network failures. That is a sensible boundary when the form service and the consumer are separate systems.

Webhooks solve a narrower problem. The form service sends an HTTP request after an event. Your endpoint verifies the request and decides what to do. A webhook does not help when your code needs to search historic submissions on demand.

Direct access changes the boundary. The form engine, data, and workflow code share one Laravel application. The application can use its normal database access, authorization rules, queues, and event listeners. FilaForms includes 25+ field types, while forms are still built visually in the Filament panel.

The table above compares those access patterns. It does not make hosted APIs obsolete. It shows why an in-app form engine removes an HTTP hop for the application that owns the data.

Read submissions and react in the same process

FilaForms stores the submission values on FormSubmission::$data. You can query that model like other application data. You can also listen for FormSubmitted and dispatch the work your application needs.

The following listener queries recent submissions and records a submission event. Save it as app/Listeners/RecordFilaFormsSubmission.php. Laravel can discover the listener when event discovery is enabled.

<?php

namespace App\Listeners;

use FilaForms\Core\Events\FormSubmitted;
use FilaForms\Core\Models\FormSubmission;
use Illuminate\Support\Facades\Log;

final class RecordFilaFormsSubmission
{
    public function handle(FormSubmitted $event): void
    {
        $recentSubmissions = FormSubmission::query()
            ->orderByDesc('created_at')
            ->limit(25)
            ->get();

        Log::info('FilaForms submission received.', [
            'form_id' => $event->form->getKey(),
            'submission_id' => $event->submission->getKey(),
            'submission_data' => $event->submission->data,
            'recent_submission_count' => $recentSubmissions->count(),
        ]);
    }
}

This pattern keeps reading and reacting close to the transaction that owns the data. You can replace the log entry with a queued job, a notification, or a domain action. Keep slow work off the request path when a submission needs expensive processing.

Direct access also gives your application a clear data model. You decide which submissions a user may see. You can join them with your own records. You can retain data under the same database policies as the rest of the application. A Laravel form builder for Filament keeps that work within the application instead of behind a remote service boundary.

The trade-off of direct access

FilaForms does not ship a public REST API for third-party clients. That is a real limitation when the consuming system is not the Laravel application itself. You still need to expose your own endpoint if an external service needs submissions or needs to trigger application work.

That endpoint can be small and specific. Return only the fields an integration needs. Use your existing authentication strategy. Apply authorization before exposing submission data. Add a queue-backed export if the consumer needs large historical datasets.

FilaForms also requires an existing Laravel and Filament application. It is not a hosted service. It is the wrong tool for a non-technical team that needs a shareable form link in five minutes. A hosted API can be the better choice for that team or for a mobile client that must manage forms remotely.

Choose a hosted HTTP API when independent systems need a stable remote contract. Choose webhooks when another system only needs event notifications. Choose direct in-app access when Laravel already owns the form engine and submission data. Review the available FilaForms features when you need conditional logic, multi-step forms, notifications, and a submission dashboard in that application.

Treat the integration boundary as a product decision. An API gives other systems a contract. In-process access gives one Laravel application fewer moving parts. The right choice follows where the form data lives and which system needs to act on it.