JetFormBuilder Formless Actions Endpoints - WordPress Plugin

How to Configure JetFormBuilder Formless Actions Endpoints for Buttons, REST Routes, and Actions Without Visible Forms

JetFormBuilder Formless Actions Endpoints is designed for situations where a conventional form is unnecessary, but JetFormBuilder still needs to perform an action: change a post's status, send data to another website, update a user, save a form record, or trigger a sequence of post-submit actions with a single button click. This guide goes beyond the plugin's marketing description to walk through the practical setup: preparing the underlying form, connecting it to an endpoint, passing data through a button, restricting access, and verifying that the action actually worked.

This guide is intended for WordPress site owners and developers who already understand what JetFormBuilder does but want to take it further. Instead of presenting visitors with a collection of form fields, you can trigger a predefined action from a listing, user dashboard, moderation page, or external application. The add-on is especially useful when the form serves as a behind-the-scenes container for actions, while users see only a straightforward button labeled "Publish," "Unpublish," "Delete," "Submit for Review," or "Update Profile."

We'll walk through the entire setup: what to check before installation, how to create the underlying form, how to choose a route type, how to prepare the JSON request, how to add a button in Elementor, Gutenberg, or Bricks, and how to test the outcome on both the frontend and in the WordPress admin dashboard. We'll also cover security in detail, because an endpoint that modifies posts or user accounts should never be publicly accessible without a deliberate reason.

Where Formless Actions Endpoints Makes a Difference

A traditional form starts with fields that visitors fill out manually. Formless Actions Endpoints takes a different approach: you configure the fields and post-submit actions in JetFormBuilder, but the page itself may contain nothing more than a button. Alternatively, an external application can send a REST request. This makes the add-on particularly useful for operational workflows where the required action is already known and needs to happen quickly, rather than for something as simple as contacting a manager.

One of the clearest examples is moderating posts from the frontend. A user submits a post through a form, which assigns it the "Pending Review" status. An administrator or editor then sees the post in a listing and clicks "Approve." There is no visible form behind the button, but there is a JetFormBuilder form containing a hidden post_id field and an Insert/Update Post action that changes the post to the desired status. A similar form can handle removal, with Move to Trash selected as the target status in its post-submit action.

Another useful application is allowing one website to serve as the backend for another website or application. The product's official page explicitly describes sending form submissions between websites through the REST API. This doesn't turn WordPress into a comprehensive API platform for every possible project, but it provides a practical connection: an external client sends data in a predefined structure, the endpoint triggers the selected form, and JetFormBuilder executes its actions.

A third use case involves action buttons in user dashboards or catalogs. A button can update a post's status, modify user information, trigger a webhook, save a form record, add an entry to a related content type, or execute another sequence supported by JetFormBuilder and its installed add-ons. There is an important distinction here: Formless Actions Endpoints does not create new business functionality on its own. It provides the route and triggering mechanism; the form's post-submit actions do the actual work.

When This Add-On Is a Good Fit

Formless Actions Endpoints is worth considering if you already run a dynamic WordPress website where users create or modify content through forms, and moderators, authors, managers, or external services need to trigger predefined actions quickly. Suitable projects include property directories, classified ad websites, author dashboards, application management systems, clinics with patient records, publication submission platforms, internal portals, content approval systems, and marketplaces featuring user-submitted products.

• You need a single button instead of a form. Users shouldn't have to reenter information when the required ID or status is already available from the current post's context.
• You want to reuse existing JetFormBuilder actions. For example, you might need to save a form record, update a post, send an email, trigger a webhook, or connect an action to another plugin in the Crocoblock ecosystem.
• You need to receive data from an external source. A REST route can accept a prepared request as long as the data structure matches what the form expects.
• You need to track incoming requests. The Log Requests toggle helps you confirm that an endpoint was called, even when the final outcome still needs additional verification.

When Another Approach Makes More Sense

Formless Actions Endpoints shouldn't be the default choice for every interactive feature. If users still need to complete several fields, a regular JetFormBuilder form will generally be easier to understand and safer to use. If your project requires a complex external integration with custom HTTP methods, headers, request signatures, and error handling, a dedicated webhook tool or a small custom REST endpoint may be more practical. For high-impact operations, such as deleting users, bulk-updating orders, processing financial transactions, or changing user roles, plan your permissions, logging, rollback procedures, and testing environment before building the interface.

The key question to ask: can you describe the operation as "take data that's already available, pass it to a preconfigured form, and execute its post-submit actions"? If so, Formless Actions Endpoints is a good fit. If the operation requires complex authorization, a multi-step interface, or arbitrary server-side functionality, the add-on alone may not be enough.

How It Works: The Underlying Form, Route, and Post-Submit Actions

To configure JetFormBuilder Formless Actions Endpoints correctly, it helps to understand its three layers. The first is a regular JetFormBuilder form. Visitors may never see it, but it still contains the fields, hidden values, presets, validation rules, and post-submit actions. The second is the endpoint, which connects a route to the selected form and determines how that route can be called. The third is the page element or external client that sends data to the endpoint.

This three-layer setup also explains why many problems occur at the connections between components rather than within any single component. The form expects a post_id field, but the sample request doesn't include it. A route exists, but the button points to a different endpoint. The Insert/Update Post action targets the wrong post type. Access permissions are broader than necessary. Logging is disabled, so you can't tell whether a request reached the endpoint. We'll approach the configuration in a way that lets you verify each layer independently.

The Underlying Form as a Behind-the-Scenes Container

In a conventional workflow, a form appears on a page, the user enters information, and then clicks Submit. With a formless action, the form may never be displayed, but it is still required. It defines the fields used to construct the endpoint's request structure and the post-submit actions that run when the endpoint is called. To update the current post, the form typically uses a Hidden Field named post_id with a preset that retrieves the current post's ID.

For a moderation button, the setup looks like this: create a form called "Approve Post Form," keep a Hidden Field, set its Field Name to post_id, and configure its default value to retrieve the current post ID through a preset. Next, add Insert/Update Post under Post Submit Actions, select the appropriate post type and post status, and map the field to Post ID (will update the post). The form doesn't need an attractive layout because users won't see it. What matters is configuring the field and action accurately.

The Endpoint as the Action's Entry Point

Routes are configured in the WordPress admin dashboard under JetFormBuilder - Endpoints. The official documentation describes a list of routes, filtering by the associated form, creation dates, and options to edit or delete endpoints. When creating a route, select RELATED FORM and then ACTION TYPE. Formless Actions Endpoints supports three confirmed options: WordPress AJAX, URL Query String, and Rest API Endpoint.

The REST option adds fields for the route namespace and route path. According to the documentation, these fields accept only lowercase Latin letters, numbers, and hyphens. It's a small restriction, but knowing about it can save considerable troubleshooting time. Spaces, underscores, Cyrillic characters, and uppercase letters can produce a route name that looks perfectly reasonable to a person but fails the add-on's internal validation rules.

The Sample Request as the Contract Between the Button and Form

Once the route is configured, the Data Fields section lets you inspect the field structure and copy a sample request. This JSON isn't merely an example for display purposes. It defines the contract: which fields the endpoint expects, what values those fields should contain, and how to supply them through a button, widget, or external request. The official tutorial demonstrates copying the sample request from the endpoint and pasting it into the Data for the request field of an Elementor or JetElements button.

If you modify the underlying form's fields after creating the route, don't keep using the old JSON. Return to the endpoint, open the sample request again, and update the button's request data. Otherwise, the button may submit a structure that no longer matches the form. For a simple action, this may appear as nothing happening. More complex operations could result in partially saved data or an error in the form record.

Preparation and the First Security Decisions

Before installing anything, describe the desired action in one technical sentence rather than starting with the button. For example: "An editor clicks a button in their dashboard, changing the current custom post type entry from pending to publish." That single sentence already identifies nearly everything needed for configuration: the user's role, button location, current post, post_id field, post type, initial status, target status, and expected outcome.

JetFormBuilder Formless Actions Endpoints is one of the JetFormBuilder Pro add-ons. The core JetFormBuilder plugin is available on WordPress.org and works with the block editor, while the add-on is installed through JetFormBuilder's add-ons section with access to the Pro package. This guide doesn't cover purchasing the product, entering a license key, or setting up a Crocoblock account. The practical instructions assume that JetFormBuilder and the required add-on are already available in your site's admin dashboard.

Minimum Environment Checklist

Make sure JetFormBuilder is working on your website, you have permission to create forms, and you know exactly what the post-submit action should accomplish. If the workflow involves a custom post type, confirm that the post type already exists, the intended statuses are applicable, and the relevant user role has permission to perform the operation. If you're using a JetEngine Listing, test the listing itself before adding a formless button. It should display the current post and make its ID available through the listing context.

• JetFormBuilder is active, and forms can be created and published in the admin dashboard.
• The Formless Actions Endpoints add-on is installed and active under JetFormBuilder - Addons.
• The required post-submit action is available in your JetFormBuilder installation and any relevant add-ons.
• If you're using the REST API, it hasn't been disabled site-wide by WordPress filters or a security plugin.
• If the endpoint modifies content, you've already decided who should be allowed to click the button or submit a request.
• You have a test post that can be used without putting production data at risk.

Access Permissions Matter More Than Button Design

The official add-on supports restricting actions to any registered user, users with a specified role, or users with a particular capability. For actions exposed on the frontend, this is a fundamental security control rather than an optional detail. WordPress documentation also makes an important distinction: a nonce does not replace authorization and should never be the sole access control. For operations that modify posts, users, or settings, it's safer to focus on capabilities rather than assuming that a hidden button provides protection.

Hiding a button in the interface does not make its endpoint inaccessible. If a route can be called directly, someone may be able to trigger it without ever seeing the page element. Therefore, enable access restrictions for routes that modify data and assign the least privileged role or capability necessary. If an action is intended only for editors, don't make it available to every registered user. If it must be called by an external application, plan the authentication method separately, and never place secrets in fields that could later appear in logs or HTML.

A practical rule: start with a restricted endpoint and test it using an account with the appropriate role. Only broaden access after you understand exactly what data the action changes and how to reverse the operation quickly.

What to Avoid in Your First Test

Don't start by deleting users, changing roles, updating products in bulk, or sending external requests from a production website. Your first test should be reversible. A better approach is to create a separate custom post type or a test entry among regular posts, configure a status change from Pending Review to Published, enable Save Form Record and Log Requests, and then inspect both the logs and the post list.

If the intended action deletes data, begin with an option that can be verified without permanent removal. For posts and custom post types, moving an item to the Trash is preferable to permanently deleting it during testing. For user information, modify a test field or status rather than an administrator role. For an external REST request, start with a sandbox website or test record, since errors in the JSON structure aren't always immediately obvious.

Installing the Add-On and Testing Your First Route

The official installation instructions use WordPress Dashboard - JetFormBuilder - Addons. Find the required add-on, click Install Addon, and then click Activate Addon. Once activated, an Endpoints section becomes available in the admin dashboard for creating routes. Card labels may differ between Crocoblock installations, so focus on the add-on's name and the availability of endpoint functionality rather than a particular button color or card position.

Your initial check should answer three questions: does WordPress recognize the add-on, can you create a route, and is the Submit JetFormBuilder Form option available in the button settings? If any of these is missing, don't proceed with a more complex setup. First, verify that the add-on and JetFormBuilder are active, check your admin permissions, and investigate possible conflicts with the admin cache or a security plugin.

Creating a Safe Test Route

Create a test form containing a single Hidden Field and the Save Form Record action. This is safer than immediately updating posts. Then open JetFormBuilder - Endpoints, click Add new route, select the test form, and choose the route type closest to your intended use case. For a button inside your website, start with WordPress AJAX or a route available in the button's settings. If you're building an external integration, test Rest API Endpoint.

Enable Log Requests during testing. This log doesn't replace form records, but it helps establish whether requests are reaching the endpoint. After a successful test, decide whether to keep logging enabled. Logging can be useful when launching active public routes, but on larger websites, logs should be reviewed and cleared periodically according to the site's maintenance policies.

Where to Check the Result of the First Request

If your form includes Save Form Record, go to JetFormBuilder - Form Records. According to the official documentation, each record provides information about form fields, submission status, the submitter, and completed actions. For an initial test, this is one of the most convenient indicators: a record with a successful status shows that the endpoint was called and the underlying form was processed. If no record appears, investigate the route, button, request structure, and access permissions.

For actions that modify WordPress posts, the next place to check is the relevant post type's list in the admin dashboard. If you changed a status, filter posts by status before and after clicking the button. If the action should update a meta field, open the post and inspect that specific field. Don't treat the "Form successfully submitted" notification as definitive proof. It indicates that the request completed successfully at the form level, but the actual business outcome must be verified where the change is supposed to occur.

Configuring the Hidden Form: Fields, Presets, and Post-Submit Actions

One of the most common mistakes in formless workflows is treating the underlying form as an empty technical placeholder. In reality, the form determines what data is available to the action and what counts as a successful submission. That's why configuration should start with the form rather than the route that will trigger it.

Let's use post moderation as an example. Our website has a custom post type called "Projects," or it uses regular posts. A user submits content, the post receives the Pending Review status, and an editor clicks "Publish" in their dashboard. We want that button to pass the current post's ID to JetFormBuilder, which then runs Insert/Update Post and changes the status to Published.

Adding a Hidden Field for the Current Post

Create a new form under JetFormBuilder - Add New. For a formless action, you can remove unnecessary visible fields and keep only a Hidden Field. Set its field name to something like post_id. Then configure a dynamic preset with Post as the source, Current post as the source of the ID, and Post ID as the property. The official instructions include a JSON-like preset value containing jet_preset, from, post_from, and current_field_prop. There is usually no reason to type this manually. Selecting the preset through the interface allows JetFormBuilder to generate the value for you.

This matters because the Insert/Update Post post-submit action needs to know which post to update. If post_id is empty, incorrect, or not mapped to Post ID (will update the post), the action may fail to update the current post. You might then assume the endpoint is broken when the real issue is the hidden field mapping.

Quick Hidden Field Check

Before creating the endpoint, publish the form and temporarily test it in a safe environment if possible. If the form isn't meant to be displayed directly, verify that the field exists in the form structure, its field name matches what the future sample request will use, and the preset doesn't reference an accidentally selected source. Whenever you change the field name, you'll also need to update the endpoint's sample request and the request data configured in the button.

Configuring the Post-Submit Action to Update a Post

Open the JetForm settings tab and find Post Submit Actions. Save Form Record is often included by default, and it's worth keeping during testing. Add Insert/Update Post. Select the post type you want to modify, followed by the desired post status. Choose Published to publish a post, Move to Trash to send it to the Trash, or Pending Review to return it for review, if that status fits your workflow.

Under FIELDS MAP, map post_id to Post ID (will update the post). This connects the incoming value to the intended update. Without this mapping, the action might treat the submission as a request to create a new post or have no way to identify the post that needs updating. Once configured, click Update in the action settings and publish the form.

When You Need Two Forms Instead of One

It's generally better to create separate forms and endpoints for distinct actions. The official approval workflow tutorial uses one form for approval and another for removal. Although the post-submit actions differ primarily in their target statuses, the outcomes are fundamentally different. Separate forms are easier to maintain: /wp-json/register/publishcard handles publishing, while /wp-json/form/deletecard handles moving a post to the Trash.

Can you handle everything with one form and conditional logic? Sometimes, yes, but doing so makes the sample request and troubleshooting more complicated. For important operations, one form per outcome is often easier to understand. Form records and logs then make it simpler to identify which route was called, which fields were submitted, and which action was executed.

Success and Error Messages

JetFormBuilder includes General Messages Settings for configuring notifications after submission. In the official tutorial, a successful action displays "Form successfully submitted." You can replace that message with something more meaningful to the editor. For example, a publishing button could display "Post submitted for publication," while a removal button could display "Post moved to Trash." This doesn't change the server-side behavior, but it helps users understand what happened.

Don't rely on the notification as your only verification. After configuring the action, check the actual object: the post status, form record, endpoint log, and button visibility on the page.

Route Namespaces, Action Types, and Request Structure

Once the form is ready, you can create the endpoint. The important decision isn't simply choosing between REST and AJAX; it's selecting a calling method that fits where the action originates. The same add-on can support a button within a WordPress page, a route called by an external client, or a URL containing parameters. However, these approaches differ in their security requirements and troubleshooting methods.

The official product page lists three action types: WordPress AJAX, URL Query String, and Rest API Endpoint. For most internal buttons built with Elementor, Gutenberg, or Bricks, it's convenient to use a route that can be selected through Submit JetFormBuilder Form. For transferring data between websites or working with headless applications, a REST endpoint is a more natural choice because the WordPress REST API is designed for exchanging JSON data with external clients.

How to Name Routes Without Creating Problems Later

A REST endpoint has two components: a namespace and a route. Together, they form a path such as /wp-json/register/publishcard or /wp-json/form/deletecard. Formless Actions Endpoints documentation restricts both fields to lowercase Latin letters, numbers, and hyphens. It's best to choose short, descriptive names that won't conflict with other routes, such as moderation and publish-post, profile and approve-card, or catalog and trash-item.

Don't include usernames, post IDs, email addresses, tokens, or other variable information in the route itself. The route should describe the action, while the data belongs in the request body or the structure defined by the sample request. This makes it easier to change values, log calls, and avoid exposing unnecessary information in URLs.

When to Choose WordPress AJAX

WordPress AJAX is appropriate when an action is triggered from your site's interface and doesn't need to be exposed as a public API for external clients. For example, a button in an author's dashboard could update the status of one of their posts while the website remains a conventional WordPress project. This approach makes it easier to work with the current user session and interface buttons. However, you still need to check roles and capabilities because AJAX requests can also be called directly.

If a button displays a success message after being clicked but the listing doesn't visibly change, the endpoint isn't necessarily malfunctioning. The database record may have been updated without JetEngine Listing or the page being rerendered. Check the admin dashboard. If the post status changed, the issue lies with refreshing the interface after AJAX, not with the post-submit action.

When to Choose REST API Endpoint

Rest API Endpoint is intended for forms triggered by an external client, another website, or a headless component of your project. The WordPress REST API works with JSON and supports standard WordPress authentication mechanisms, including cookies for requests originating within the website and application passwords for external requests. With Formless Actions Endpoints, the route acts as the entry point, while JetFormBuilder processes the form after receiving the data.

REST integrations require stricter access controls. The official Formless Actions Endpoints instructions recommend enabling Is Restricted when using a custom WP REST API endpoint to submit a form from one website to another. This is a sensible default: an externally accessible endpoint capable of modifying data should have access restrictions and a verifiable authentication method.

When to Use URL Query String

URL Query String can be useful for simple workflows where opening a URL with parameters triggers an action. However, this format requires particular caution. URLs may be stored in browser history, analytics platforms, server logs, messaging apps, or emails. Avoid passing sensitive data, secrets, personal information, or difficult-to-reverse commands through query strings. When reliable access control is important, REST or AJAX is generally safer and easier to manage.

Data Structure and Sample Request

The Data Structure section helps define fields, their types, default values, and sample values. The Sample Request section provides formatted data that you can copy into Elementor, Gutenberg, or Bricks. In practice, this is one of the endpoint's most valuable outputs because it shows exactly what the route expects to receive.

Don't modify a copied sample request without understanding its structure. If you need to replace a dynamic value with the current post ID, check how your page builder resolves dynamic tags. When using an Elementor or JetElements Button, configure Content - Submit JetFormBuilder Form: enable Enable form submission, select the route under Choose route, paste the JSON into Data for the request, and save the page.

Practical Example: Publish and Move to Trash Buttons in a Post Listing

Let's build a complete workflow that demonstrates what JetFormBuilder Formless Actions Endpoints is designed to do. Authors submit posts for review, and an editor sees a list of pending posts on a frontend moderation page. Two buttons let the editor change each post's status: one publishes it, and the other moves it to the Trash. The editor never sees a form, but each click triggers the corresponding JetFormBuilder form.

You can adapt this example for classified ads, property listings, applications, catalog entries, patient records, guest articles, or an internal document repository. We'll use a generic custom post type called "Projects," but the same approach works with regular posts and most custom post types, provided that Insert/Update Post supports the selected post type.

Goal and Preparation

We want a workflow whose outcome can be verified at every stage. A post is created with the Pending Review status and appears in an "Awaiting Review" listing. An editor clicks "Publish," the endpoint receives post_id, JetFormBuilder changes the status to Published, and the post disappears from the pending listing and appears among published posts. The removal button follows the same sequence but ends with Move to Trash.

• Create or select a custom post type where you can safely test status changes.
• Prepare several test posts with the Pending Review status.
• Build a listing that displays only pending posts and provides the current post's context.
• Confirm that users with the editor role have permission to modify these posts.
• Enable Save Form Record on both underlying forms so you can inspect test submissions.

Creating the Publishing Form

Create a form named "Publish Project Form." Keep a Hidden Field, set its field name to post_id, and configure a preset that retrieves the current post ID. Under Post Submit Actions, add Insert/Update Post. Select "Projects" as the post type, Published as the post status, and map post_id to Post ID (will update the post) under FIELDS MAP. Leave Save Form Record enabled during testing.

After publishing the form, go to JetFormBuilder - Endpoints and create a route. Under RELATED FORM, select "Publish Project Form." Choose the appropriate option under ACTION TYPE. For a REST example, you can use moderation as the namespace and publish-project as the route. Enable Is Restricted and select the editor role or an appropriate capability. Enable Log Requests while testing, then copy the sample request.

Creating the Move to Trash Form

Create a second form called "Trash Project Form," or duplicate the first one. Keep the same Hidden Field and preset. In the post-submit action, change only the target status to Move to Trash. Create a separate endpoint, for example, with moderation as the namespace and trash-project as the route. Enable access restrictions and logging for this endpoint during testing as well. Copy its own sample request.

Separate routes make troubleshooting easier. If an editor reports a problem later, you can quickly determine which endpoint ran. Publishing and removal operations won't be mixed together in logs and form records. You can also assign different permissions: editors might be allowed to publish posts, while moving them to the Trash could be reserved for administrators or users with a more specific capability.

Adding Buttons to the Listing Template

Open the listing template in Elementor, Gutenberg, or Bricks. Add a button to each pending post card. In Elementor and JetElements, the official instructions use the Submit JetFormBuilder Form section. Enable Enable form submission, select the appropriate route under Choose route, paste its sample request into Data for the request, and save the template. For the publishing button, select /wp-json/moderation/publish-project. For the Trash button, use /wp-json/moderation/trash-project.

If your builder supports dynamic tags in button request data, use them to supply the current post ID. If the sample request already contains a current post preset, verify that the current post within the listing actually refers to the card whose button the editor clicked. This is essential: a button in a repeating listing must submit the ID of its own card, not the ID of the page containing the listing.

Verifying the Result on the Website and in the Admin Dashboard

Open the pending posts listing while logged in with a role authorized to access the route. Click "Publish" on one test post. The expected visible outcome is a success message, followed by the post disappearing from the pending list or changing its displayed state after the page refreshes. Next, check Posts or the relevant custom post type in the admin dashboard: that specific post's status must now be Published. Finally, open JetFormBuilder - Form Records and confirm that a successful submission containing post_id was recorded.

Repeat the test with the Trash button on a different post. The expected outcome is that the post moves to the Trash, a form record is created, and the request log contains a call to the corresponding route. If the listing doesn't update visually, refresh the page and inspect the backend. If the backend data changed, the endpoint is working; the remaining task is to handle the interface refresh after AJAX or adjust the listing filters.

Managing Multiple Buttons on the Same Card

When a card contains two or three action buttons, route names and messages should clearly distinguish their purposes. Don't call both forms "Action Form" or name the route submit. That creates unnecessary confusion during future maintenance. Instead, use a consistent, descriptive naming pattern such as publish-project, trash-project, and send-back-project. Make the form names equally clear: "Publish Project Form" and "Trash Project Form." This makes form records, endpoints, and button settings much easier to understand together.

Security and Access Restrictions: Roles, Capabilities, Nonces, and Logs

An action button may look harmless, but it can trigger operations that modify WordPress data. Security for Formless Actions Endpoints therefore needs to be considered before the page goes live. The add-on's official page describes three restriction options: any registered user, a user with a specified role, or a user with a specified capability. On a production website, a specific capability is often the better choice when you know exactly which permission is required. A role may be too broad or may acquire additional permissions after a role management plugin is installed.

The WordPress REST API has its own authentication rules. Cookie authentication works for logged-in users within WordPress, manually constructed AJAX requests must include a nonce, and external requests can use application passwords or other authentication methods. WordPress documentation also explicitly warns that nonces are not a complete authorization mechanism. They help protect against CSRF but do not replace current_user_can() checks or equivalent capability-based access controls.

Choosing the Right Access Level

If an endpoint only saves a non-sensitive submission from a registered user, the "any registered user" option may be sufficient. If it publishes posts, changes statuses, or deletes content, choose the editor role or a specific capability. If an endpoint manages users, don't make it available to every author simply because its button is hidden in the template. Hiding interface elements improves usability; it does not enforce security.

Log Requests and Form Records Serve Different Purposes

Log Requests records attempts to call an endpoint. Save Form Record stores form submissions and their field data. During implementation, using both provides better visibility. If the request log shows an incoming call but no form record is created, the problem may involve validation, request structure, an action, or permissions. If a form record exists but the intended business outcome didn't occur, investigate the post-submit action and field mapping.

On a production website, keeping logging enabled should be a deliberate decision. Frequently called endpoints can generate large logs that increase maintenance overhead. However, logs provide a useful audit trail for routes that modify content or call external systems. A reasonable compromise is to enable logging during deployment and then keep it active only for critical routes or turn it on when troubleshooting.

Avoiding Unnecessary Data in Requests

Being able to copy a sample request doesn't mean you should submit every available field. If an action only requires post_id, don't add email addresses, phone numbers, private notes, or internal fields to the payload. The less data an endpoint accepts, the easier it is to assess its security. For external REST integrations, also check whether request bodies could be captured by third-party logs, analytics systems, proxies, or debugging tools.

Caching, Security Plugins, and the REST API

Caching and security plugins can affect AJAX and REST requests. This doesn't mean you need to disable them. However, when troubleshooting, check whether a route is being blocked because it looks like a "nonstandard endpoint," contains "suspicious JSON," generates "frequent requests," or lacks a nonce. WordPress support discussions include cases where antispam or security layers flag a formless endpoint as suspicious. When that happens, don't simply open the endpoint to everyone. Configure a narrowly scoped exception, verify the user's role, and keep logging enabled until the integration works reliably.

Using Formless Actions Endpoints with JetEngine, Elementor, Gutenberg, and Bricks

Formless Actions Endpoints is particularly useful alongside JetEngine Listing because the listing provides context for the current post, while the button triggers an action for that post. However, the add-on isn't limited to Elementor. The official product page mentions using sample requests in Elementor, Gutenberg, and Bricks. JetFormBuilder's core documentation also confirms that forms can be displayed through the Block Editor, Elementor, Bricks, and shortcodes in other page builders. For a formless button, the essential requirement is that the chosen interface can select a route and submit data through Data for the request.

Using JetEngine Listing to Identify the Current Post

Each card in a listing typically has access to its own post context. A Hidden Field configured with the current post ID can therefore receive the correct value when the button is embedded in the card template rather than placed at the page level without that context. Test this explicitly: click buttons on different posts and confirm that the selected post is the one being modified. If the same post changes every time, or nothing changes at all, the issue often lies in the dynamic tag context or a static value in the sample request.

For more complex listings, add a temporary way to verify the ID. You can display the post ID only to administrators or add an internal field to the card on a test page. Remove it after debugging. This is safer and more reliable than trying to infer from form records why the endpoint received the wrong ID.

Elementor and JetElements Button

The official instructions demonstrate configuring an Elementor or JetElements button. Under Content - Submit JetFormBuilder Form, enable Enable form submission, select the route under Choose route, and paste the sample request into Data for the request. After saving the page, the button becomes a trigger for a JetFormBuilder form submission rather than an ordinary link.

Avoid combining a standard button URL with a formless submission unless you understand how both behaviors interact. If a button navigates to another page while also calling an endpoint, the user may leave before the request completes or miss the confirmation message. For an action button, it's generally better to trigger the action directly and add navigation or page refresh behavior only after verifying that everything works.

Gutenberg and Bricks

The same principle applies in Gutenberg and Bricks: the button or element must be able to select a route and send request data. If your builder doesn't provide a convenient interface for Submit JetFormBuilder Form, use JetFormBuilder's officially supported form display methods and consider whether a compact visible form with a single action button would be simpler. A formless approach is valuable when it improves the user experience, not when it forces you to build a fragile custom solution.

When You Need an External REST Client

When another website or application sends data to WordPress, the route becomes an API contract. Document its namespace, route, required fields, accepted values, authentication method, and expected response. Never put secrets in Codex, the article's HTML, or publicly accessible fields. For internal team documentation, describing the structure without actual credentials is sufficient: identify the fields, provide example values, and specify where the real access configuration is stored.

{
  "post_id": 123,
  "moderation_note": "approved by editor"
}

This example illustrates only the data structure. An actual request must match the sample request generated by your endpoint and your website's authorization requirements. If JetFormBuilder expects a different field name or value type, don't make arbitrary changes to the example or the external client. Return to the form and its Data Structure settings.

REST Workflows and Data Transfers Between Websites

The official Formless Actions Endpoints product page specifically highlights managing form data through the REST API and sending submissions between different websites. This makes the add-on useful beyond buttons in listings. It can also support projects where WordPress acts as the central processing system while data arrives from another website, a static page, a mobile client, or an internal team tool. However, REST workflows require more careful planning than on-site buttons. External clients don't have access to a WordPress page's context, so every value required by the form must be explicitly included in the request.

A good REST contract starts with the same question as a button: what should happen after a successful call? If the goal is to create a post, the form needs fields for the title, content, and meta data, along with the Insert/Update Post post-submit action. If the goal is to update an existing post, it needs that post's ID and the appropriate field mapping. If the goal is to send data from WordPress to an external webhook, the endpoint receives the incoming request and the Call Webhook form action forwards the prepared information. Keep these responsibilities distinct: an incoming REST endpoint and an outgoing webhook handle data in opposite directions.

Design the Payload Before Building the Form

With a button inside WordPress, some data can come from the current listing card. An external REST client doesn't have that context. Start by defining the payload as a simple list: required fields, value types, examples, where each value comes from, and what should happen if a field is empty. Then create the fields in JetFormBuilder and configure Data Structure. This reduces the risk of the form expecting one structure, the endpoint showing another, and the external client sending something else entirely.

For example, a publication submission sent from another website might include external_id, title, author_email, summary, and source_url. But if the action only changes the status of an existing post, the payload should be much smaller. Avoid adding fields "just in case." They complicate validation, logs, and privacy management. An endpoint should accept only the minimum data required to perform its specific action.

Example of an Internal Payload Specification

This table doesn't necessarily belong in your website's public documentation. It's intended for the team connecting the external client to WordPress. For users, it's enough to explain the principle: the payload must match the form fields and the sample request generated by the endpoint.

Testing REST Calls Without Exposing Sensitive Data

For your first REST test, create a separate endpoint that runs only Save Form Record. Send a minimal JSON request and confirm that a form record appears. Then add one safe post-submit action, such as changing the status of a test post. Don't immediately combine email notifications, an external webhook, user updates, and Trash operations. If the sequence fails, you'll have difficulty identifying which action interrupted processing.

The external client should retain an example of the request and response without any secrets. This doesn't require a sophisticated logging system. During implementation, recording the test time, route, payload without sensitive information, response status, and form record ID is enough. If the endpoint stops working a week later, you'll have a reference point for comparison. Without it, troubleshooting becomes a process of guessing which setting changed.

Authentication and Restrictions for REST Workflows

The WordPress REST API supports several authentication methods, but the right one depends on where the client runs. Within WordPress, cookie authentication and nonces can fit naturally into the existing environment. External clients usually need a separate mechanism, such as application passwords or another authentication method approved for the website. The Is Restricted setting in Formless Actions Endpoints still matters because it controls who can execute an action after WordPress has identified the user.

Never store passwords, API keys, or actual secrets in a sample request, HTML button, user-facing form field, or visible help text. If an external client needs a secret, it belongs in a secure client configuration or server-side environment, not in data that visitors can inspect. If you can't provide that level of protection, it's better to postpone the REST integration and use an internal button for authenticated users.

Handling Incoming Request Errors

In a REST workflow, an error may occur before the request reaches JetFormBuilder, within the endpoint, or after a post-submit action. It's important to distinguish between these stages. If WordPress returns an authentication error, the form was never reached. If Log Requests shows an incoming call but no form record exists, compare the payload with Data Structure. If the form record indicates success but an external system received nothing from Call Webhook, the problem lies with the outgoing request. This separation is especially important when WordPress sits in a sequence such as "external website - endpoint - form action - another service."

Maintenance After Launch: Documentation, Permissions, and Upkeep

Once the button works, many teams consider the job finished. But a formless endpoint is essentially a small API within your website. It deserves the same documentation and maintenance as any feature that changes data. Otherwise, a few months later, nobody will remember which form publishes posts, which route removes cards, why logging is enabled, who can use the button, or which sample request is current.

Create a concise internal reference. It shouldn't contain secrets, passwords, or personal data. Include the form name, route, action type, accepted fields, post-submit actions, affected object, access permissions, where to verify the outcome, and how to disable the action. This reference helps not only developers but also site editors who may need to explain why a post disappeared from a listing after someone clicked a button.

Naming Forms and Routes

Names should be unambiguously descriptive, even if they aren't particularly creative. "Publish Project Form" is better than "Endpoint Form 1." The route moderation/publish-project is better than test/action. For pairs of related actions, use matching names such as publish-project and trash-project, or approve-card and remove-card. This makes Form Records and the endpoint list easier to understand without opening every configuration panel.

Don't rename a production route without a migration plan. Buttons and external clients may still reference the old URL. If a route must change, create the replacement first, update the button, verify the result, and only then disable the previous route. Coordinate the transition separately with external clients, since changing the route effectively changes their API integration.

Reviewing Access Permissions Periodically

Every few months, or whenever user roles change, review who can execute each endpoint. This is particularly important on sites using User Role Editor or similar tools. A role that originally had limited privileges may have gained new permissions. A capability selected for an endpoint may now be assigned more broadly. Test not only button visibility but also whether a user without the required permissions can call the route directly.

For critical actions, it's useful to maintain two test accounts: one with minimal permissions and another with editor permissions. The first should not be able to execute the endpoint. The second should be able to perform only the operations required by their responsibilities. If both tests pass, you've verified access controls at the route level rather than just in the interface.

Maintaining Request Logs and Form Records

Form Records and Log Requests are valuable when investigating incidents, but they shouldn't become an unlimited collection of old data. For active endpoints, decide in advance how long records should be retained, who reviews them, and how errors will be handled. If form records contain user information, follow your website's privacy policy. If endpoints receive frequent requests, periodically review log sizes and their effect on admin dashboard performance.

At the same time, don't disable all auditing simply to keep the database tidy. For actions that change statuses, delete posts, or call external services, temporary logging during launch can make support much easier. Once the workflow is stable, you can retain records for important forms and enable Log Requests only during troubleshooting or on higher-risk routes.

Testing After JetFormBuilder Updates

The core JetFormBuilder plugin continues to evolve, with changes including bug fixes, admin interface updates, accessibility improvements, server-side validation, and security enhancements. Forms generally continue working after updates, but formless endpoints deserve a quick smoke test: click a publishing button, check the resulting status in the backend, inspect the form record, and confirm that restricted access settings haven't changed. A short verification is much easier than investigating a broken workflow after a user reports it.

Minimum maintenance requirements: keep a route reference, a test post, a user without access, a user with access, and a short testing procedure. This keeps Formless Actions Endpoints manageable instead of allowing it to become a collection of forgotten background actions.

Verifying the Outcome: What Counts as a Successful Setup?

A successful Formless Actions Endpoints configuration involves more than seeing a green confirmation message after clicking a button. Verify the complete sequence: the button calls the correct route, the route accepts the request, the form receives the expected fields, the post-submit action makes the intended change, the post or user is actually updated, a form record is saved, and unauthorized roles cannot execute the operation. If any of these steps remains unverified, the setup isn't complete.

For larger websites, a checklist can help. Don't treat it as a box-ticking exercise: verify every item using a test post, then repeat the process with the actual content type under restricted access. Only after that should the button be made available to editors or managers.

Checklist Before Publishing the Page

• The form is published and contains every field expected by the endpoint.
• The hidden field has the correct name, such as post_id, and a valid preset for the current post.
• The selected post-submit action is the one intended to modify the target object.
• FIELDS MAP maps post_id to Post ID (will update the post).
• The route is connected to the correct form, and its action type matches how it will be called.
• The namespace and route path use only lowercase Latin letters, numbers, and hyphens.
• The sample request was copied after the most recent form modification.
• The button uses the intended route rather than another test endpoint.
• Is Restricted is enabled for every action that modifies data.
• Log Requests is enabled at least during the initial deployment.

Verification After Clicking the Button

Start by checking what the user sees: a success message, a card disappearing from a pending listing, a different button becoming visible, or a status change. Then open the admin dashboard and inspect the affected object directly. After that, review form records and the endpoint log. This sequence helps isolate the problem to the interface, route, form, action, or presentation of the updated data.

If the action triggers an external webhook or communicates with another website, add a check on the receiving side. For example, the external service should receive the JSON, while the WordPress form record should show that the action succeeded. If WordPress reports success but the external service receives nothing, the problem may involve the remote URL, authentication, headers, firewall, or availability of the external service rather than the endpoint itself.

How to Roll Back a Configuration Safely

If something goes wrong after deployment, don't immediately delete every form and route. A safer rollback is to temporarily disable the page button, restrict access to the route, change the action's target status to a safe test option, or disable the problematic post-submit action. Keep form records and logs until you've investigated the issue; otherwise, you may erase the evidence needed to understand what happened.

For critical routes, maintain a short internal note explaining which form connects to each route, what its action does, who has access, how to disable the button, where to find logs, and how to restore a post from the Trash or change its status manually. This is particularly useful when someone other than the original JetFormBuilder implementer is maintaining the site.

Useful Improvements Without Modifying the Plugin's Core

There's no need to invent complex code snippets for JetFormBuilder Formless Actions Endpoints without confirmation from the documentation or source code. A safer approach is to rely on the add-on's settings, WordPress capabilities, descriptive route names, form records, logs, and carefully scoped CSS and UX improvements around the buttons. The code below doesn't modify JetFormBuilder's core or alter the endpoint. It simply helps distinguish moderation action buttons if your theme doesn't make their purposes sufficiently clear.

CSS for a Group of Action Buttons

Add a class such as jfb-actions-panel to the container holding the buttons, and assign jfb-action-publish and jfb-action-trash to the individual buttons. You can add the CSS through your theme settings, a child theme, or a safe custom CSS tool. Before applying it, inspect the elements in your browser's developer tools because page builders may introduce additional nested elements.

.jfb-actions-panel {
  display: flex;
  flex-wrap: wrap;
  gap: 10px;
  align-items: center;
}

.jfb-actions-panel .jfb-action-publish,
.jfb-actions-panel .jfb-action-trash {
  min-height: 42px;
  padding: 10px 16px;
  border-radius: 6px;
  font-weight: 600;
}

.jfb-actions-panel .jfb-action-publish {
  background: #28a745;
  color: #fff;
}

.jfb-actions-panel .jfb-action-trash {
  background: #f2f4f7;
  color: #333;
  border: 1px solid #d0d7de;
}

Testing is straightforward: open the moderation page, make sure the action buttons are visually distinct from ordinary links, click a test button, and verify the result in the backend. To roll back the change, remove the CSS or the classes assigned to the container and buttons. This styling doesn't affect REST, AJAX, Form Records, or post-submit actions.

Adding Short Explanatory Text Near Risky Actions

If a button moves a post to the Trash or changes an important status, add a short explanation nearby in the template rather than a lengthy instruction. For example: "This action applies to the current item" or "This post will disappear from the review list after you click." Such messages reduce the risk of accidental clicks. If the action requires confirmation, first check whether your builder supports a built-in confirmation dialog or a safe modal workflow. Avoid adding complex JavaScript that intercepts every request on the website when a straightforward interface setting would solve the problem.

Troubleshooting Common Issues and Errors

What to Do When Formless Actions Endpoints Doesn't Work

The most effective way to troubleshoot formless actions is to work from the symptoms. The same apparent outcome, "nothing happened," can have several causes: the button never sent a request, the endpoint was blocked, the form received an incorrect payload, the post-submit action failed, or the post changed in the backend but the listing didn't refresh. Start with the interface and work inward: interface - route - form record - WordPress object - permissions.

The Button Works, but the Post Doesn't Change

Symptom: the user can see and click the button, but the post status remains unchanged in the admin dashboard. Possible causes include an incorrect post_id, an outdated sample request, incorrect mapping under FIELDS MAP, or an action configured for the wrong post type. First, open the form record and inspect the value received in post_id. Then check the Insert/Update Post settings and confirm that post_id is mapped to Post ID (will update the post).

Fix: correct the Hidden Field preset, regenerate the sample request after the latest form changes, paste the updated data into the button, and repeat the test with a single post. If the action targets a custom post type, verify that you selected that specific type rather than regular posts.

A Success Message Appears, but the Listing Still Shows the Old Status

Symptom: "Form successfully submitted" appears and the backend status changes, but the card remains in its original listing. This is often an interface refresh issue rather than an endpoint problem. The listing may have rendered before the request and may not have refreshed after the AJAX response. Manually reload the page. If the card disappears, the backend update worked.

Fix: configure the page's behavior after the action using your builder's features, display a clear confirmation message, or use the listing's built-in refresh mechanism if your installed plugins provide one. Don't start modifying the endpoint until you've established that the backend data isn't changing.

The REST Route Returns an Access Error

Symptom: an external client or button receives an access-denied response, and no form record is created. One possible cause is that Is Restricted is enabled, but the request comes from a user without the required role or capability. A REST request may also lack valid WordPress authentication. Cookie authentication operates within the context of a logged-in WordPress user, while external clients need a separate authorization method.

Fix: check which user role is making the request, which role or capability is configured in the endpoint, and whether a security plugin is blocking the REST API. If the endpoint must be accessible externally, don't disable access restrictions just to run a quick test on a production website. Create a test route with a safe action and configure authentication properly.

The Endpoint Rejects the Namespace or Path

Symptom: the route can't be saved or cannot later be called through the expected URL. The likely cause is an unsupported character. Formless Actions Endpoints documentation allows only lowercase Latin letters, numbers, and hyphens in namespaces and routes. Cyrillic characters, spaces, underscores, and uppercase letters aren't permitted.

Fix: rename the route using short values such as moderation and publish-post. After changing the route, select it again in the button settings and update the sample request if the builder stores a reference to the specific route.

A Security or Antispam Plugin Blocks the Formless Request

Symptom: the endpoint worked during initial testing but stopped working after you enabled a security plugin or stricter antispam settings. WordPress ecosystem support discussions describe situations where security layers treat formless action endpoints as suspicious submissions. This can be a false positive, particularly when a request is sent without a visible form.

Fix: inspect the security plugin's logs, route URL, user role, nonce, and request body. Create a narrowly scoped exception for the affected route only after verifying the restrictions configured in Formless Actions Endpoints. If the security plugin suggests disabling protection globally, look for a more targeted option first.

Form Records Is Empty, but Log Requests Shows Incoming Calls

Symptom: the endpoint logs incoming requests, but no form records appear. Possible causes include failed validation, a payload that doesn't match the form structure, an action stopping processing before the record is saved, or Save Form Record being disabled. First, check whether the record-saving action is still enabled. Then compare the endpoint's sample request with the data actually submitted by the button or external client.

Fix: temporarily simplify the form to one Hidden Field and Save Form Record. Repeat the test, then restore post-submit actions one at a time. This will help you determine whether the basic submission is failing or whether a specific action is causing the problem.

Video Tutorial: Setting Up a Frontend Approval Workflow

Crocoblock provides a dedicated video embedded in its official Formless Actions Endpoints tutorial. Rather than showing an isolated endpoint, the video walks through an entire frontend approval system: creating a custom post type, building the submission form, creating separate formless endpoints for approval and removal, configuring the listing template, and verifying the outcome. If you're building this type of workflow for the first time, it directly addresses how to configure Formless Actions Endpoints to publish and remove posts from the frontend.

Before watching, prepare a test post and decide which status you want to change. That will make it easier to apply the video's steps to your website: create an approval form, create a removal form, configure separate endpoints, add each sample request to its button, and verify the backend status after clicking.

When to Use JetFormBuilder Formless Actions Endpoints

JetFormBuilder Formless Actions Endpoints is a strong choice if your website already uses JetFormBuilder and you want to trigger its post-submit actions without displaying a full form on the page. It's particularly useful for moderation buttons, user dashboards, dynamic listings, approval workflows, simple REST routes, and operations where WordPress receives predefined data and updates a post, user, or related object.

Before deploying it to a production website, verify the underlying form, hidden fields, action mapping, route type, sample request, access restrictions, logs, and final outcome. If an action modifies data, start with a test post and the minimum necessary permissions. For external REST integrations, document the request structure and authentication method separately from public-facing content.

Once the full sequence is clear and a test post successfully moves through "button - endpoint - form - post-submit action - verified outcome," you can download JetFormBuilder Formless Actions Endpoints and begin implementing it carefully on your website. For more complex projects, keep a short reference of your routes and enable logging during the initial monitoring period. It will save time when an editor or manager eventually reports the first issue.