I’m building a restaurant menu website (similar to a Culver-style menu) where all menu data—categories, item names, descriptions, prices, images, and availability flags—is stored in Airtable and fetched dynamically using the Airtable REST API. Each menu category (e.g., ButterBurgers, Frozen Custard, Drinks) is linked to a separate table, and the website consumes this data to render the full menu on the frontend. While the setup works correctly in most cases, I’m running into inconsistent behavior when retrieving records via the API.
Specifically, some API responses return only partial data sets or miss linked records, even though those records are present and correctly linked inside Airtable. In certain cases, a category endpoint returns fewer items than expected, and refreshing or re-running the same API request sometimes returns a different result. I’ve verified that the API key, base ID, table names, and view filters are correct, and I’m not hitting documented rate limits. This inconsistency makes it difficult to reliably render complete menu categories on the live site.
I’m trying to understand whether this behavior could be related to view-based filtering, linked record limits, pagination (offset) handling, or caching behavior on either the Airtable API or my frontend. Are there recommended best practices for structuring Airtable bases and API requests when powering a large, multi-category restaurant culver menu? Any guidance on avoiding partial responses or ensuring consistent data retrieval would be greatly appreciated.