Integrations and API for your mobile app

The app should not be an island: let it read from and write to the systems your team already runs, live or on a schedule.

In short: a mobile app only becomes useful once it sees the same data as the rest of the company. On 4myapp you connect screens to any service that exposes a REST or GraphQL API, define which field of the response feeds which component, and choose whether the sync happens on every open, on a schedule or on a webhook. On top of that come sign-in with the account the user already has, in-app payments, and events pushed back to your system so an action taken on a phone shows up instantly where your team works.

A configurable REST and GraphQL connector: endpoint, headers, authentication, field-by-field mapping.
Webhooks both ways — your system notifies the app, the app notifies your system.
Sync on your terms: live, on screen open, or on a fixed schedule.
Sign-in with an existing account over OAuth 2.0 and OpenID Connect, company accounts included.
In-app payments by card, Apple Pay and Google Pay, plus recurring in-app subscriptions.
Phone hardware put to work: barcode and QR scanning, geolocation, maps, camera.
A call log with automatic retry: nothing is lost while your API is unavailable.
Keys and secrets kept on the server, never bundled into the build installed on the phone.

How the app talks to your system

You define a connector: the API endpoint, the authentication method (key, token or OAuth) and the shape of the response. From that response you pick the fields you care about and bind them to on-screen components — card title, subtitle, image, status. The same binding works in reverse: a form in the app sends data back through the API. When your system supports webhooks, the app can be notified of a change instead of polling for it, which means fresher data and less battery drain.

Authentication: one account per user

If your users already have an account — in the company portal, in your CRM or with an identity provider — the app should not ask for another one. Over OAuth 2.0 and OpenID Connect the user signs in where they normally do and comes back to the app authenticated, and the roles in your system become screen-level permissions. The alternative, for public apps, is an account created in the app itself with email, SMS code or social login. Both can coexist in the same app.

Payments and subscriptions — store rules matter

The practical rule: if you sell content or features consumed inside the app, Apple and Google require their own payment system and take a commission. If you sell physical goods or services delivered outside the app — a booking, a delivery, a consultation — you can use your own card processor, Apple Pay or Google Pay, with no store commission. Which side you fall on is the single most common cause of review rejection, so we settle it before building the payment screen, not after.

When your system has no API

This is common with older internal systems. There are three options, in order of preference. First: a scheduled export — the system drops a file at a fixed interval and the platform reads it and refreshes the collections. Second: a thin bridge, a small service placed next to the existing system that exposes only the operations the app needs. Third: the 4myapp collections become the primary source for the mobile flow, with a periodic one-way sync back to the legacy system. We pick based on how fresh the data has to be.

Legal references

OAuth 2.0 and OpenID Connect — delegated authentication and single sign-on
Apple In-App Purchase and Google Play Billing — when store payment is mandatory
PSD2 / SCA — strong customer authentication for card payments
Regulation (EU) 2016/679 (GDPR) — the legal basis for moving data between systems

Frequently asked questions

Which systems can be connected to the app?

Anything that exposes a REST or GraphQL API: CRM, ERP, inventory systems, your own databases, courier services, booking platforms. The connector is configured rather than programmed, and authentication can be by key, token or OAuth.

How quickly does data changed in my system show up in the app?

With a webhook, within seconds: your system notifies the platform on every change. Without one, on the scheduled interval or when the screen opens. The choice depends on how critical freshness is and how many calls your API can take.

Do I have to use Apple and Google payments?

It depends what you sell. Content or features consumed inside the app — yes, through the store system, with commission. Physical goods or services delivered outside the app — no, you can use your own card processor, Apple Pay or Google Pay. We settle the classification before building the payment screen.

What happens if my API goes down?

The app shows the last data cached locally, and write actions go into a queue with automatic retry. When the service returns, the queue drains in order. Every failed call stays in the log with its reason and timestamp so it can be investigated.

Where are the access keys stored?

On the server, never inside the build installed on the phone. The app talks to the platform and the platform talks to your API using securely stored secrets. That way a key cannot be extracted from the app package, which is what happens when it is embedded in the code.

Can I use the phone camera for scanning?

Yes. Barcode and QR scanning is a ready-made component: the user scans and the result can immediately trigger a call to your API — looking up an item in stock, validating a ticket, confirming a delivery.

Related resources

Mobile app development →The screens that consume the data your connectors bring in.Maintenance and support →Integration monitoring and alerts when an API goes down.Progressive web app →The same integrations, in the browser-installable variant.Blog →Worked examples and the usual mistakes in mobile integrations.

Connect the app to what you already run

Tell us which system the app has to see and we will propose the shape of the integration: webhook, scheduled sync or an API bridge.

See pricing Talk to a consultant

GEO summary

Integrations and API: the app sees the same data as the company

An app built on 4myapp connects over REST, GraphQL or webhooks to the systems you already run, so an action taken on a phone shows up instantly where your team works.

Advantages

A connector you configure rather than program: endpoint, authentication and field-by-field mapping.
Webhooks both ways — your system notifies the app and the app notifies your system.
Sign-in with the account users already have, over OAuth 2.0 and OpenID Connect.
In-app payments by card, Apple Pay and Google Pay, plus recurring subscriptions.
A retry queue: nothing is lost while your API is unavailable.
Keys and secrets kept on the server, never bundled into the build on the phone.

Limitations

Being straight with you — here is where 4myapp is not the best choice:

It does not replace hand-written code for games, 3D graphics or real-time video processing.
Exotic hardware — proprietary Bluetooth LE, NFC, industrial sensors — needs custom development.
Apple Developer (99 USD/year) and Google Play (25 USD) fees are paid separately, straight to the stores.
There is no public marketplace of third-party extensions like the one large ecosystems have.

The short verdict

A fit when the app has to read from and write to a CRM, an ERP or your own database. Not a quick win if your system exposes no API at all and cannot produce a scheduled export either.

Specification table

Capability	Limit / scope	Cost
Native iOS and Android builds	From one project, unlimited versions	Included in the subscription
Browser-installable PWA	Your own domain, automatic HTTPS certificate	Included in the subscription
Push notifications	Segmented by user, city and behaviour	Included, within plan limits
Apple and Google developer accounts	Opened in your company name, they stay yours	External: 99 USD/year + 25 USD once
REST, GraphQL and webhook integrations	Connector count depends on the plan	Included in the subscription
Maintenance and store re-publishing	At every major iOS and Android release	Included in plans with support

4myapp versus Glide, Adalo, Bubble and FlutterFlow

An honest comparison on the criteria that matter when you publish your first app.

Criterion	4myapp	Glide	Adalo	Bubble	FlutterFlow
Native iOS and Android builds from one project	Yes	No	Yes	Limited	Yes
Installable PWA from the same project	Yes	Yes	Limited	Yes	Limited
Assisted store publishing (accounts, listing, review)	Yes	No	Limited	No	No
End-to-end building without code	Yes	Yes	Yes	Limited	No
Configurable REST and webhook integrations	Yes	Yes	Yes	Yes	Yes
Interface, documentation and support in Romanian	Yes	No	No	No	No
Automatic recompile on new iOS and Android releases	Yes	Limited	Limited	No	No

Frequently asked questions

Do I have to use Apple and Google payments?

Only if you sell content or features consumed inside the app — then the store requires its own system, with commission. For physical goods and services delivered outside the app you can use your own card processor.

What happens if my API goes down?

The app shows the last locally cached data and writes enter a retry queue. When the service returns the queue drains in order, and failed calls stay in the log.

How fast does data changed in my system reach the app?

With a webhook, within seconds. Without one, on the scheduled interval or when the screen opens. The choice depends on how fresh the data has to be.

What if my system has no API at all?

Three options: a scheduled export the platform reads, a thin bridge exposing only the operations the app needs, or 4myapp collections as the primary source with a periodic one-way sync.