Partly, and the nuance matters. Every generated application exposes a full REST API — one family of routes per data type — but it is protected by the session cookie: there is no API key yet that would let another piece of software connect on its own. Without writing a line, you do get JSON and CSV export of every dataset, file import on measurement data, and direct database access if you host it yourself. And because the code is yours, adding an API key remains a standard piece of work.
What the application actually exposes
A generated application is not an interface sitting on top of an opaque database: it is built like a normal web application, with a REST API behind its screens. For every data type described in your request, the engine emits the same family of routes: list and create, then read, update and delete a specific record. A deletion erases nothing permanently, by the way — it goes through the trash, and a restore route exists to undo it.
These routes are not an optional extra: they are exactly the ones the application's own screens use. So there is no "real" internal API on one side and a watered-down public one on the other — it is the same API, and it sits in the code you take away.
The limit to know: no API key today
As soon as an application requires a login — the default for business data — its routes are protected: every call must carry the signed session cookie issued at login, and a read-only account is refused any write on the server side, whatever route it takes.
That protection has a direct consequence, better known before committing: there is, today, no API key and no token letting another piece of software authenticate on its own, without a browser. A third-party tool therefore cannot query the application machine-to-machine as it stands. We would rather write it plainly than let "the application has an API" suggest more than it does.
What works without writing a line
The Settings screen offers an export of every dataset, in JSON or CSV. It is the shortest path to a spreadsheet, a reporting tool or an accountant: the data comes out when you decide, in formats everybody reads.
The other way round, measurement data — readings, tracks, series produced by a device — gets an import route and a file-upload button: CSV, and GPX for tracks. Finally, if you host the application yourself, its PostgreSQL database is yours: a reporting tool can read from it directly, without going through the API.
If you need a full integration
The point to hold on to is that none of these limits is a lock. The application is a standard Next.js and Prisma project, exportable as a ZIP or pushed to your own GitHub repository: adding API-key authentication to routes that already exist is well-charted work for a developer, on readable code.
That is the difference with a tool whose integration depends on a connector the vendor either offers or does not. Here the question is never "will the platform allow it?" but only "who writes it?" — and the day you do, you have nobody to ask.