Many third‑party APIs (e.g., Miniflux, GitHub) always return full objects, including fields that are irrelevant for specific recipes. The resulting payloads can be 10-100× larger than needed, causing server‑side 500 errors when the backend cannot handle the size.
When this happens, the recipe gets stuck in a “limbo” state - the plugin becomes uneditable from the UI and the only way to clean it up is to exec into the container and manually delete the response data with artisan tinker.
A way to trim unnecessary fields before the data reaches the recipe would make these APIs usable without hitting size limits and could also avoid any potential errors. The official TRMNL backend actually has a solution for this, see here: Parsing plugins with the Sandbox Runtime. This uses JavaScript to filter the payload using a transform function.
It'd be great to have this or a similar feature.
Many third‑party APIs (e.g., Miniflux, GitHub) always return full objects, including fields that are irrelevant for specific recipes. The resulting payloads can be 10-100× larger than needed, causing server‑side 500 errors when the backend cannot handle the size.
When this happens, the recipe gets stuck in a “limbo” state - the plugin becomes uneditable from the UI and the only way to clean it up is to exec into the container and manually delete the response data with
artisan tinker.A way to trim unnecessary fields before the data reaches the recipe would make these APIs usable without hitting size limits and could also avoid any potential errors. The official TRMNL backend actually has a solution for this, see here: Parsing plugins with the Sandbox Runtime. This uses JavaScript to filter the payload using a
transformfunction.It'd be great to have this or a similar feature.