Drupal as a mobile app backend: APIs, auth and caching

Using Drupal as a content backend for mobile apps

Drupal can act as the content backend for native iOS and Android apps through its core web services APIs, while the app owns navigation, layout and interaction. This fits a team that already runs Drupal for editorial work, wants one content model shared by the website and the apps, and needs editors to publish once for every channel. It fits less well when the app's main job is transactional (orders, bookings, account changes) with little editorial content behind it, because those flows need their own security and integration design. Drupal and all contributed modules hosted on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so licensing cost sits in hosting, build, integration and support work. The current major version is Drupal 11, and the core release schedule lists Drupal 12 for the week of December 7, 2026, so a new app should be planned against the version your team will still be supporting when it ships.

Before committing, confirm three things with your own engineers and your Drupal partner: which content types and fields the app needs, whether the app must work without a network connection, and which identity provider will sign users in. Content types that the app consumes should be listed explicitly, because the API you expose is a contract with every released app version, and older app builds stay in the field long after you change the backend. Ask who on your side will own that contract and how long each version must keep working. The answers decide whether the Drupal API layer needs custom resources, a field allowlist or a separate versioned endpoint, and they set the scope of testing before any mobile code is written.

Expect the main cost to be design and build work rather than licensing. Your team pays for the content model review, the API configuration and any custom code, the identity integration, the mobile team's client work and the hosting and operations behind both. Much of this is one-time, but API maintenance, security updates and app store release cycles recur for as long as the app is live. When you request a quote, ask for the written scope to name each API resource, the authentication method, the offline behavior, the push approach and the performance test plan, so that the estimate can be compared with what your own team would deliver.

Which API and authentication approach fits your app

Public articles, product details, event listings and similar content usually need no sign-in. Drupal core's JSON:API module publishes entities as resources an app can read directly, so the first decision is which content types and fields belong in the feed.

Anonymous access. Grant the anonymous role view permission only for the content types the app needs, and confirm that unpublished revisions stay hidden.
Cacheable responses. Public GET requests can sit behind a CDN or reverse proxy, which reduces load on Drupal when many devices fetch the same list.
Field exposure. Review which fields JSON:API returns, since internal notes or moderation fields can appear by default.
Pagination and filters. Set page sizes and filters on collection endpoints so a phone does not download an entire catalog at once.

Check anonymous permissions and cache headers with a test client that carries no session, and confirm the response matches what the public may see.

Offline caching and content update delivery

A mobile app that reads Drupal content has three delivery problems: what the device keeps when the network drops, how the app learns that an editor changed something, and how it is told to refresh. Each card below is a decision that connects the Drupal side (JSON:API responses, cache tags, the Drupal page cache) to what the app stores and when it fetches. Confirm each choice with your app team before the content model is locked.

Choose what the device stores

Decide which content types are available offline and which need a live request. Article bodies and reference lists are usually good candidates, while personalized data, pricing or access-controlled content usually is not. Each offline entity needs a local schema, a size limit and a rule for partial downloads, such as images fetched later. Ask the app team how the cache is keyed, since JSON:API paths with query parameters change the key on every filter. Set expectations for editors too, because a device may show content that was valid at its last sync.

Plan sync with changed timestamps

Most offline clients fetch only what changed since their last sync. In Drupal, that means exposing a reliable changed time on each resource and filtering the JSON:API collection on it, then deciding how deleted or unpublished items reach the device. Unpublished content does not disappear from a list by itself, so the API must signal removals or the app keeps stale records. Test paging across large collections, and confirm how your chosen modules expose these filters before promising incremental sync.

Invalidate caches on publish

Drupal's page cache and reverse proxies can serve old API responses after an editor publishes. Cache tags let Drupal mark the responses that depend on a node, and a purge step in your CDN or proxy must act on those tags. Confirm that API responses vary correctly by authentication and language, so one user does not receive another's cached data. Ask your hosting team who owns purge rules, how long a purge takes to propagate to edge locations, and how a failed purge is detected.

Push notifications sit outside Drupal

Drupal core does not send push notifications to iOS or Android devices. A push service must be connected to the publish workflow, usually through a custom module or an external worker that reads the publish event and calls the vendor's service for each platform. Apple and Google each have their own credentials, delivery rules and device token handling, and those rules must be checked for each app platform before design starts. Decide who may trigger a push and whether each notice is sent once, per device or per user.

Use push as a signal, not payload

A push message should tell the app that something changed, with an identifier, and let the app fetch the content from the API when it opens. Sending full article bodies in the push payload exposes content on lock screens and creates size limits that differ by platform. The app should also reconcile after a push, because devices may be offline or the message may be dropped. Ask the app team to define the handler and the fallback sync, and confirm both with your push vendor's documented limits.

Protect offline data on the device

Cached content may include drafts, embargoed material or content for a single role, so the device must not keep anything the user is no longer allowed to read. Plan token expiry, logout wipes and what happens when a user's roles change on the server. Encrypt the local store using the platform's secure storage, and confirm with your security team how cached data is handled during device loss or account reassignment. Authentication design sits in a separate topic, but offline storage must follow it.

API performance with subrequests and caching

A mobile screen rarely needs one resource. A product detail screen may need the article, its author, related items, images, taxonomy terms and a menu, and each of those is a separate request if the app follows entity references one at a time. Each call adds network latency that is paid on a phone's radio, often on a slow connection, so the number of round trips usually matters more than the size of any single response. Before choosing a fix, list every screen the app renders and count the calls it makes on a cold start and on a warm one. That inventory is the baseline every later decision is measured against.

Two Drupal-side mechanisms reduce those round trips. JSON:API supports the include parameter, which returns related entities in one response, and sparse fieldsets, which trim fields the screen never shows. Where a screen depends on data from several endpoints, the Subrequests module lets Drupal resolve multiple internal requests inside a single HTTP call, so the app sends one batch request and receives the combined result. Confirm how each option behaves with your access model, because included entities and batched subrequests still pass through Drupal's permission checks. Also confirm the module version against your Drupal core release, since compatibility is tracked per release on Drupal.org. Caching sits behind those requests. Drupal's internal page and dynamic page caches, cache tags and contexts decide whether a JSON:API response is rebuilt or served from cache, and a reverse proxy or CDN in front of the API can serve identical anonymous responses without touching PHP or the database. Authenticated responses, which mobile apps send most of the time, usually bypass shared caches because they vary by user, so per-user cache contexts and private caching need their own plan. Ask your team to measure hit rates for both anonymous and authenticated traffic separately, and to test cache invalidation by publishing an edit and confirming the app sees it within the freshness window you agreed with editors. Figures for latency or throughput should come from your own load tests against your own screens, not from published benchmarks.

How to set up Drupal for a mobile app backend

This sequence takes a Drupal site from version and runtime checks through content modeling, API exposure, token authentication, caching and device testing. The result is a backend that a mobile app can call predictably, with each layer verified before the next one depends on it.

Confirm Drupal version and PHP runtime
Your team confirms which Drupal major version the backend will run on and checks that the PHP version on the hosting platform meets that version's requirement. Drupal 11 requires PHP 8.3 or later, Drupal 10 requires PHP 8.1 or later, and no supported Drupal version runs on PHP 7. Drupal 10 reaches end of life on December 9, 2026, according to the core release schedule, so a new mobile backend should start on Drupal 11 unless there is a documented reason otherwise. Confirm the database (MariaDB, MySQL, PostgreSQL or SQLite) and web server (Apache, Nginx or another supported server) as well. The step is done when a clean install runs, the status report is free of errors, and the versions are recorded in your architecture decision log.
Model content around app screens
Content architects map each screen, list and detail view in the app to Drupal content types, fields, taxonomies and references. Decide which entities the app needs directly, which need aggregated views, and which fields belong to editors versus system data. Keep one canonical content model rather than one per platform, and document field names, required fields and media types because they become the API contract. The step is done when every screen in the agreed app design has a named source entity, and an editor can create a sample item that contains all the fields a screen needs.
Enable and configure the API layer
Developers enable the core JSON:API module (or GraphQL, if that is the chosen query model) and restrict exposed resources and fields to what the app consumes. Unpublished content, internal fields and administrative data should not appear in responses. Set up pagination limits, filter and sort rules, and the URL prefix so the app's endpoints stay stable. The step is done when an unauthenticated request returns only published, permitted content, and an authenticated request for a restricted field is refused as expected.
Set up token authentication and a test client
Choose the authentication model for the app, typically OAuth 2.0 through the Simple OAuth contributed module, or an identity provider over OpenID Connect if users sign in through a corporate directory. Define a client per app platform, set grant types, scopes and token lifetimes, and decide how refresh tokens are stored on devices. Create a scripted test client that requests a token, calls protected endpoints and refreshes the token. The step is done when the test client can obtain, use, refresh and revoke a token, and a request with an expired or revoked token is rejected.
Add caching and a CDN layer
Platform engineers enable Drupal's page and entity caching, configure a reverse proxy or CDN for anonymous API responses, and confirm that cache tags invalidate responses when editors publish or change content. Authenticated responses need separate handling so one user's data is never served to another. Measure response times for the main list and detail endpoints under expected load in a staging environment before setting any targets. The step is done when a published change appears in the API after the expected invalidation, and cached responses never contain another user's data in test cases.
Verify with real device traffic
Test with physical iOS and Android devices on the networks your users actually use, including poor mobile connections. Check offline behavior, token renewal after the app is backgrounded, and how the app handles API errors and empty states. Confirm the push mechanism for content updates, whether that is a silent notification that triggers a refresh or a polling schedule, and that it works with the platform notification services you use. Log API errors and slow requests from the devices and trace them back to Drupal. The step is done when a test script of agreed user journeys passes on each device class, and the team has a documented list of known limitations for release.

Security and operational considerations for app APIs

A mobile app API outlives its first release, and each of these controls ages differently. Token policy, client scopes, rate limits, app secrets, security patching and the PHP runtime all determine how exposed the backend is on the day a vulnerability is published. Plan them together before the first app store submission.

Token lifetime and revocation

Access tokens issued to phones should be short-lived, with refresh tokens that the server can revoke when a device is lost, a user leaves or a session is reported as compromised. Decide how long a refresh token stays valid, whether it rotates on each use, and how a logout on one device invalidates sessions on others. Confirm how your chosen OAuth or OIDC module handles revocation endpoints and test that a revoked token is rejected by every content route, not only the login flow.

Scopes per client

Each app should receive only the scopes it needs, so a read-only news app cannot create or edit nodes even if its token is stolen. Map scopes to content types, roles and write operations, and keep separate OAuth clients for iOS, Android and any internal tool. Review the scope list whenever a feature adds a new endpoint, because a permissive default on a shared client is a common source of over-broad access.

Rate limiting at the edge

Drupal does not limit request rates on its own in a way that fits mobile traffic, so limits usually belong at a reverse proxy, API gateway or CDN in front of the site. Set limits on login, token refresh and search endpoints first, since these are the usual targets for credential stuffing and scraping. Confirm with your platform team where limits are enforced, what response a throttled client receives, and how the app handles a retry.

Secrets in the app binary

Anything compiled into an iOS or Android build can be extracted, so a client secret embedded in the app is not confidential. Public mobile clients should use the authorization code flow with PKCE and no static secret, while server-side integrations keep their secrets in a vault. Ask your team to confirm that no API keys for third-party services ship in the bundle and that the app stores tokens in the platform keychain or keystore.

Handling Drupal security advisories

The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and security releases arrive on the third Wednesday of the month. Define who subscribes to advisories for core and every contributed module the API depends on, how quickly a patch is tested against the app's endpoints, and who approves an emergency deploy. Treat an advisory on an authentication module as an urgent change even when the app itself is unaffected.

Keeping PHP on a supported version

Each Drupal major version requires a minimum PHP release, and no supported Drupal version runs on PHP 7. Check the PHP version your hosting provides against the requirement for the Drupal version you run, and plan the PHP upgrade before moving to the next Drupal major. Schedule PHP patch updates in the same routine as Drupal updates, and test API responses after each runtime change, since serialization and session behavior can shift.

Questions teams ask before building a Drupal mobile backend

What drives the cost of a Drupal backend for a mobile app?

The main drivers are the content model, the number of screens and the API surface they need, the authentication scope, the offline and push requirements, and how much testing the app needs across devices. A content model with many referenced entities, translations and editorial states takes longer to design and test than a flat set of article-like types. Each screen that needs a different shape of data adds mapping work, and every extra authentication flow, such as single sign-on or device-bound sessions, adds security review. Ask for a written scope that lists these items separately so each can be priced and tested on its own.

How long does a Drupal mobile backend take to build?

Duration depends on the same drivers as cost, plus the state of the existing Drupal site and the readiness of the app team. A greenfield content model with a few screens and standard login is a different project from a backend that must serve an existing estate with offline sync and push. No duration is given here because none has been supplied as a researched fact. Ask for a timeline in the written scope that ties each milestone to a deliverable, and ask which parts depend on decisions from your app or product team.

What does our team need to provide for the engagement?

Plan to provide a named product owner who can make content model and screen decisions, access to the current Drupal site or a staging copy, the identity provider details if you use single sign-on, and access to the app team for API contract reviews. You will also need someone who can approve test devices and release windows. Hosting access matters too: the backend runs in infrastructure you control, so your platform team should confirm where Drupal, its database and caches will run before the build starts.

Can our internal team build a Drupal mobile backend without a partner?

Yes, if the team has Drupal development skills and time to maintain the result. Drupal is open-source software licensed under GPL-2.0-or-later, so there is no license fee for the core platform, but you still pay for people, hosting and ongoing maintenance. The harder parts are usually API design for mobile clients, cache invalidation for offline content, and secure token handling. Ask your team to name who will own the API contract, upgrades and on-call response before deciding. A partner can cover part of the build, a fixed-scope piece such as an authentication review, or ongoing support under a retainer.

How does the Drupal version affect a mobile backend project?

The Drupal major version sets your PHP requirement, your upgrade calendar and the modules you can use. Drupal 11 is the current major version and requires PHP 8.3 or later. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. If the backend starts on Drupal 10 today, plan the upgrade into the project scope. Sites on Drupal 7 cannot be updated in place and must be migrated into a new site, which adds effort that a mobile project should not absorb by accident.

What breaks most often in Drupal mobile APIs, and how do we test for it?

The common failures are stale content in offline caches, token expiry during long sessions, changed field names after a content model edit, and slow responses when many related entities load in one request. Test each of these against real devices with poor connectivity, not only with desktop tools. Build contract tests for each endpoint the app calls, and run load tests against a staging environment that mirrors your caching layers. Ask any partner to show how they will test on both iOS and Android, and which device matrix they propose in the written scope.

What security questions should we settle before the build starts?

Settle how users authenticate, how tokens are issued and revoked, and which data may be cached on a device. For OAuth 2.0 and OpenID Connect flows, decide the grant types per client type and the token lifetimes, and record who can revoke a session. If you plan to use an external identity provider, the contributed OpenID Connect module can create accounts on first sign-in, and the SAML Authentication module can act as a SAML service provider for SAML-based identity providers. Confirm which controls your compliance program requires for mobile data at rest and in transit, and ask for those controls to be written into the scope.

What to do if the Drupal site is still on Drupal 7

Drupal 7 security support ended on January 5, 2025, so a mobile API built on a Drupal 7 site inherits an unsupported core for every request the app makes. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. The supported route is a new Drupal site, populated with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and your themes must be rebuilt because they cannot be migrated. For a mobile backend, that means the content model, users, roles and URL aliases move across, while the presentation layer is replaced by the app and the JSON:API or custom endpoints you define on the new site. Confirm the current core and PHP requirements for the target version against the Drupal.org pages before you fix the design, because the mobile API contract depends on them.

Decide early whether the migration and the mobile build run in sequence or in parallel. Parallel work is common, but the app should not be wired to Drupal 7 endpoints that will be discarded. Build the content types, fields and authentication model once on the target site, then map each Drupal 7 entity to its new equivalent in a migration map that your team reviews field by field. Test the migrated content through the same endpoints the app will call, including images, file references and taxonomy terms used for offline caching keys. Plan a cutover window where the old site stops accepting writes, and agree with editors how content created during the final sync will be reconciled.

If the migration cannot be finished before the app launches, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites in that position. Treat this as a bridge with a fixed end date, not a place to keep building features. Ask each provider what they cover for contributed modules, how they deliver patches, and what your team must still do to apply them. Avoid adding new mobile endpoints to the Drupal 7 site during the bridge period, because each one becomes migration work later. Put the bridge end date on the same plan as the app release, and confirm the provider terms in writing before you sign.

How DeployOpen scopes and delivers a Drupal mobile backend

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted Drupal inside the client's own infrastructure. For a mobile backend, that means agreeing in writing how the app's API surface, authentication, caching and content-update flow will work before any module code is written.

How we scope

Map which content types, fields and views the iOS and Android apps need, and which stay internal to editors.
Agree the authentication approach for mobile clients, including token handling and session lifetimes, in the written scope.
Define performance targets and test cases for API responses, cache behavior and offline sync before the build starts.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins.

How we build

Configure the JSON:API and authentication layers, then add custom endpoints only where the app's data needs require them.
Set cache tags, reverse proxy rules and invalidation so content updates reach app clients predictably.
Test API responses against the agreed contract with automated checks that run on every change to the Drupal codebase.
Review performance under realistic app request patterns and record findings for the team that will run the site.

How we hand over

Document content model, endpoints, authentication flows, cache rules and the deployment process in the project repository.
Walk your engineers through the API contract, including versioning rules for app releases that stay installed for months.
Provide runbooks for token revocation, cache purging and rollback so your team can respond without DeployOpen on call.
Deliver code under the GPL-2.0-or-later license that governs Drupal and its contributed modules, with no paid Drupal edition involved.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer aligned to the Drupal release schedule.
Plan core and contributed module updates around the monthly bugfix and third-Wednesday security release windows.
Ask for a quote built from the written scope, covering build, testing, handover and any recurring retainer as separate lines.

Drupal as a content backend for mobile apps