Skip to main content

Introduction

Filament’s table builder was originally designed to render data directly from a SQL database using Eloquent models in a Laravel application. Each row in a Filament table corresponds to a row in the database, represented by an Eloquent model instance. However, this setup isn’t always possible or practical. You might need to display data that isn’t stored in a database—or data that is stored, but not accessible via Eloquent. In such cases, you can use custom data instead. Pass a function to the records() method of the table builder that returns an array of data. This function is called when the table renders, and the value it returns is used to populate the table.
The array keys (e.g., 1, 2, 3) represent the record IDs. Use unique and consistent keys to ensure proper diffing and state tracking. This helps prevent issues with record integrity during Livewire interactions and updates.

Securing custom data

Filament does not apply Eloquent global scopes or automatically check model policies for array records. Your records() callback must return only data the current user may access, including any tenant or ownership restrictions. Apply those restrictions at the data source before sorting or paginating. Search terms, filters, and record selections are client-controlled and must not determine which data the user is authorized to access. Authorize custom actions explicitly, using an authorize() callback or a check in the action’s callback before accessing or changing data. Permission to display a row does not imply permission to create, update, or delete it. For URL actions, the destination route must authorize access independently. If you use an API credential, its access to the upstream service does not establish the current user’s permission to perform an operation.

Columns

Columns in the table work similarly to how they do when using Eloquent models, but with one key difference: instead of referring to a model attribute or relationship, the column name represents a key in the array returned by the records() function. When working with the current record inside a column function, set the $record type to array instead of Model. For example, to define a column using the state() function, you could do the following:

Sorting

Filament’s built-in sorting function uses SQL to sort data. When working with custom data, you’ll need to handle sorting yourself. To access the currently sorted column and direction, you can inject $sortColumn and $sortDirection into the records() function. These variables are null if no sorting is applied. In the example below, a collection is used to sort the data by key. The collection is returned instead of an array, and Filament handles it the same way. However, using a collection is not required to use this feature.
It might seem like Filament should sort the data for you, but in many cases, it’s better to let your data source—like a custom query or API call—handle the sorting instead.

Searching

Filament’s built-in searching function uses SQL to search data. When working with custom data, you’ll need to handle searching yourself. To access the current search query, you can inject $search into the records() function. This variable is null if no search query is currently being used. In the example below, a collection is used to filter the data by the search query. The collection is returned instead of an array, and Filament handles it the same way. However, using a collection is not required to use this feature.
In this example, specific columns like title do not need to be searchable() because the search logic is handled inside the records() function. However, if you want to enable the search field without enabling search for a specific column, you can use the searchable() method on the entire table.
It might seem like Filament should search the data for you, but in many cases, it’s better to let your data source—like a custom query or API call—handle the searching instead.

Searching individual columns

The individual column searches feature provides a way to render a search field separately for each column, allowing more precise filtering. When using custom data, you need to implement this feature yourself. Instead of injecting $search into the records() function, you can inject an array of $columnSearches, which contains the search queries for each column.
It might seem like Filament should search the data for you, but in many cases, it’s better to let your data source—like a custom query or API call—handle the searching instead.

Filters

Filament also provides a way to filter data using filters. When working with custom data, you’ll need to handle filtering yourself. Filament gives you access to an array of filter data by injecting $filters into the records() function. The array contains the names of the filters as keys and the values of the filter forms themselves. In the example below, a collection is used to filter the data. The collection is returned instead of an array, and Filament handles it the same way. However, using a collection is not required to use this feature.
Filter values aren’t directly accessible via $filters['filterName']. Instead, each filter contains one or more form fields, and those field names are used as keys within the filter’s data array. For example:
  • Checkbox or Toggle filters without a custom schema (e.g., featured) use isActive as the key: $filters['featured']['isActive']
  • Select filters (e.g., author) use value: $filters['author']['value']
  • Custom schema filters (e.g., creation_date) use the actual form field names. If the field is named date, access it like this: $filters['creation_date']['date']
It might seem like Filament should filter the data for you, but in many cases, it’s better to let your data source—like a custom query or API call—handle the filtering instead.

Pagination

Filament’s built-in pagination feature uses SQL to paginate the data. When working with custom data, you’ll need to handle pagination yourself. The $page and $recordsPerPage arguments are injected into the records() function, and you can use them to paginate the data. A LengthAwarePaginator should be returned from the records() function, and Filament will handle the pagination links and other pagination features for you:
In this example, the forPage() method is used to paginate the data. This probably isn’t the most efficient way to paginate data from a query or API, but it is a simple way to demonstrate how to paginate data from a custom array.
It might seem like Filament should paginate the data for you, but in many cases, it’s better to let your data source—like a custom query or API call—handle the pagination instead.
If you have multiple custom tables on a page and are using the queryStringIdentifier('customIdentifier') method to distinguish them, you will need to add an options argument to the LengthAwarePaginator with the pageName, like options: ['pageName' => 'customIdentifierPage']. Note that adding the Page suffix to your custom identifier is required here.

Actions

Actions receive an array instead of a Model in their $record parameter. These are custom actions, so apply the authorization checks described above, including authorization in the destination route for the URL action below.
When using custom data, the table data is not automatically refreshed after an action is executed. If you have an action that changes the state of a table record in the current pagination page, you should call $this->resetTable() in your action function.

Bulk actions

For actions that interact with a single record, the record is always present on the current table page, so the records() method can be used to fetch the data. However for bulk actions, records can be selected across pagination pages. If you would like to use a bulk action that selects records across pages, you need to give Filament a way to fetch records across pages, otherwise it will only return the records from the current page. The resolveSelectedRecordsUsing() method should accept a function which has a $keys parameter, and returns a Collection of record data:
Treat $keys as client-controlled. The resolver must only return records the current user may access, with the same tenant and ownership restrictions as records(). Authorize the intended operation on each returned record before processing it; selection is not authorization.
However, if your user uses the “Select All” button to select all records across pagination pages, Filament will internally switch to tracking deselected records instead of selected records. This is an efficient mechanism in significantly large datasets. You can inject two additional parameters into the resolveSelectedRecordsUsing() method to handle this case: $isTrackingDeselectedKeys and $deselectedKeys. $isTrackingDeselectedKeys is a boolean that indicates whether the user is tracking deselected keys. If it’s true, $deselectedKeys will contain the keys of the records that are currently deselected. You can use this information to filter out the deselected records from the collection returned by the resolveSelectedRecordsUsing() method:

Using an external API as a table data source

Filament’s table builder allows you to populate tables with data fetched from any external source—not just Eloquent models. This is particularly useful when you want to display data from a REST API or a third-party service.
The examples in this section use DummyJSON, a demonstration API. Before adapting them for production, add authentication, authorization for each operation, input validation, error handling, and rate limiting appropriate to your API. Filament does not automatically authorize array records or scope them to a tenant. Follow the custom data security guidance. DummyJSON simulates create, update, and delete requests without persisting changes.

Fetching data from an external API

The example below demonstrates how to consume data from DummyJSON, a free fake REST API for placeholder JSON, and display it in a Filament table:
The records() callback returns the response’s products keyed by their stable id. Keep these keys across sorting, filtering, and pagination so a selection or mounted action continues to identify the same product even if the API changes the order of its results. Handle failed requests separately rather than treating an empty array as a successful response.
DummyJSON returns 30 items by default. You can use the limit and skip query parameters to paginate through all items or use limit=0 to get all items.

Setting the state of a column using API data

Columns map to the array keys returned by the records() function. When working with the current record inside a column function, set the $record type to array instead of Model. For example, to define a column using the state() function, you could do the following:
You can use the formatStateUsing() method to format the state of a text column without changing the state itself.

External API sorting

You can enable sorting in columns even when using an external API as the data source. The example below demonstrates how to pass sorting parameters (sort_column and sort_direction) to the DummyJSON API and how they are handled by the API.
Pass $sortColumn as sortBy and $sortDirection as order to let the API sort the results. Use pagination to fetch more than the API’s default page of results.

External API searching

You can enable searching in columns even when using an external API as the data source. The example below demonstrates how to pass the search parameter to the DummyJSON API and how it is handled by the API.
Pass $search as the q parameter to the search endpoint. Use pagination to fetch more than the API’s default page of matching results.

External API filtering

You can enable filtering in your table even when using an external API as the data source. The example below demonstrates how to pass the filter parameter to the DummyJSON API and how it is handled by the API.
Read the selected category from $filters['category']['value'] and choose the category endpoint, or the products endpoint when no category is selected. Use pagination to fetch more than the API’s default page of results.

External API pagination

You can enable pagination when using an external API as the table data source. Filament will pass the current page and the number of records per page to your records() function. The example below demonstrates how to construct a LengthAwarePaginator manually and fetch paginated data from the DummyJSON API, which uses limit and skip parameters for pagination:
Use the injected $page and $recordsPerPage to calculate the API’s skip offset. Return a LengthAwarePaginator containing the current page’s items and the API’s total count, so Filament can display the correct pagination controls.

External API actions

When using actions in a table with an external API, the process is almost identical to working with Eloquent models. The main difference is that the $record parameter in the action’s callback function will be an array instead of a Model instance. Filament provides a variety of built-in actions that you can use in your application. However, you are not limited to these. You can create custom actions tailored to your application’s needs. The examples below demonstrate how to create and use actions with an external API using DummyJSON as a simulated API source.
These examples do not implement application authorization. Check the current user’s permission for each operation and record before loading modal data or sending an API request, and enforce tenant or ownership restrictions in your API or server-side data access. Modal confirmation, form validation, and API authentication do not replace those checks. See securing custom data.

External API create action example

The create action in this example provides a modal form that sends a POST request to the API. DummyJSON simulates creation without persisting the product. Before using this recipe with a real API, authorize creation and handle failed requests before showing a success notification.
  • modalHeading() sets the title of the modal that appears when the action is triggered.
  • schema() defines the form fields displayed in the modal.
  • action() defines the logic that will be executed when the user submits the form.
If you don’t need a modal, you can directly redirect users to a specified URL when they click the create action button. In this case, you can define a custom URL pointing to the product creation page:

External API edit action example

The edit action in this example provides a modal form for editing product details and sends a PUT request. DummyJSON simulates updates without persisting them. Before using this recipe with a real API, authorize access and updates to the product and handle failed requests before showing a success notification.
  • icon() defines the icon shown for this action in the table.
  • modalHeading() sets the title of the modal that appears when the action is triggered.
  • fillForm() automatically fills the form fields with the existing values of the selected record.
  • schema() defines the form fields displayed in the modal.
  • action() defines the logic that will be executed when the user submits the form.
If you don’t need a modal, you can directly redirect users to a specified URL when they click the action button. You can achieve this by defining a URL with a dynamic route that includes the record parameter:

External API view action example

The view action in this example opens a modal displaying detailed product information fetched from an external API. This allows you to build a user interface with various components such as text entries and images. For private data, authorize access to the product before fetching or displaying these details. A read-only modal does not make its contents public or authorize access.
  • color() sets the color of the action button.
  • icon() defines the icon shown for this action in the table.
  • modalHeading() sets the title of the modal that appears when the action is triggered.
  • schema() defines the form fields displayed in the modal.
  • modalSubmitAction(false) disables the submit button, making this a read-only view action.
  • modalCancelActionLabel() customizes the label for the close button.
The select parameter is used to limit the fields returned by the API. This helps reduce payload size and improves performance when rendering the table.
If you don’t need a modal, you can directly redirect users to a specified URL when they click the action button. You can achieve this by defining a URL with a dynamic route that includes the record parameter:

External API delete action example

The delete action in this example sends a DELETE request for a product. DummyJSON simulates deletion without persisting it. Before using this recipe with a real API, authorize deletion of the product and handle failed requests before showing a success notification. Asking for confirmation does not authorize deletion.
  • color() sets the color of the action button.
  • icon() defines the icon shown for this action in the table.
  • modalIcon() sets the icon that will appear in the confirmation modal.
  • modalHeading() sets the title of the modal that appears when the action is triggered.
  • requiresConfirmation() ensures that the user must confirm the deletion before it is executed.
  • action() defines the logic that will be executed when the user confirms the submission.

External API full example

This example adds sorting and pagination to the products, search, and category endpoints. When a search is entered, it uses /products/search; otherwise, it uses the selected category’s endpoint or /products.
In this example, search takes precedence over the category filter: selecting a category does not restrict search results. If your application needs both constraints, use an API that supports them together, or filter the complete matching dataset before paginating. A client-controlled filter must never be your authorization boundary. For private data, enforce the current user’s access restrictions on every endpoint, regardless of the search or filters they choose.
The select parameter is used to limit the fields returned by the API. This helps reduce payload size and improves performance when rendering the table.