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 therecords() 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.
Securing custom data
Filament does not apply Eloquent global scopes or automatically check model policies for array records. Yourrecords() 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 therecords() 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.
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.
$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
isActiveas thekey:$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:
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.
Actions
Actions receive anarray 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.
Bulk actions
For actions that interact with a single record, the record is always present on the current table page, so therecords() 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:
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.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: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 therecords() 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:
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.
$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 thesearch parameter to the DummyJSON API and how it is handled by the API.
$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 thefilter parameter to the DummyJSON API and how it is handled by the API.
$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 yourrecords() 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:
$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.
External API create action example
The create action in this example provides a modal form that sends aPOST 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.
External API edit action example
The edit action in this example provides a modal form for editing product details and sends aPUT 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.
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.record parameter:
External API delete action example
The delete action in this example sends aDELETE 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.
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.