What I Learned Building Flutter Apps on Top of WordPress REST APIs

Using WordPress as a Flutter backend looks simple at first: fetch JSON, render cards and open a post. The interesting problems begin when the app needs to behave like a product instead of a remote website viewer.

Stable identifiers matter more than labels

Names change. Capitalisation changes. Parent and child terms can share similar labels. A mobile app should store stable IDs and explicit relationships wherever possible. The display name is presentation; the identifier is the contract.

Offline filtering needs a deliberate snapshot

If a teacher chooses a class while offline, the app still needs to know which subjects are valid for that class. A compact, ID-aware filter snapshot can be refreshed from the server and reused locally without downloading an entire taxonomy tree each time a modal opens.

Parent-first rules simplify both API and UI

Some content models make sense only after a parent choice is known. If subject options depend on class, allowing subject-only requests creates ambiguous behaviour. Making class the first required choice gives the server and the interface a clearer contract.

Internal links should remain inside the product

When an article links to another item inside the same content system, sending a user to an external browser breaks continuity. A better approach recognises internal URLs, resolves the destination and opens the corresponding native screen.

Design endpoints for product behaviour

The best REST endpoint is not always the generic endpoint the CMS exposes by default. A small purpose-built endpoint that returns the exact filter map, relationships and labels an app needs can be faster, easier to cache and much easier to reason about than stitching several requests together on the device.