Reading a Settle Up group through its sync layer

Every Settle Up group — its members, their default split weights, expenses, incomes and the computed who-owes-whom figures — lives as a JSON subtree in a Firebase Realtime Database, with Android, iOS, Windows and web clients all syncing against the same tree. That single fact decides the integration. The seam an integrator wants is the same one the clients themselves use: an authenticated read and write path against that tree, not a brittle scrape of a screen.

The bottom line for a buyer: the data is well structured and reachable under an authorized account, the multi-currency and computed-debt behaviour needs deliberate handling, and the build is short. We integrate against the sync layer under a consenting account arranged with you, normalise the ledger, and hand back runnable source plus an interface spec.

What a group holds

The entities below come from Step Up Labs' own engineering posts and the app's privacy policy, named the way the app structures them. Debts are the notable one — they are derived, because the app deliberately minimises the number of transfers between members rather than storing a raw pairwise balance.

Ways in

Three routes genuinely apply to this app. They differ in reach and in how durable they are.

1 · Authorized implementation of the sync protocol

The clients authenticate a Settle Up user through Firebase Authentication and then read and write JSON paths over HTTPS against the Realtime Database — GET to read a node, PUT to update it, POST to create one, on paths shaped like permissions/<group> and members/<group>. We implement against that same protocol under an account you consent to. Reach is the whole authorized ledger: members, expenses, incomes, permissions, change history and rates. Effort is moderate; durability is high, because this is the app's own synchronisation backbone rather than a UI that shifts. Access is arranged with you during onboarding — the build runs against a consenting account or a sandbox, set up together.

2 · User-consented read-only access

Settle Up already exposes a read-only role on a group. Where you only need a one-way mirror — group balances into a dashboard, expenses into accounting — we authenticate as an account scoped to that role and never write back. Lower blast radius, slightly narrower reach (no posting), and it maps cleanly to how the app itself shares groups.

3 · Native export

The Android app emails a per-group CSV, and a premium tier emails group history as a spreadsheet. This is the low-effort fallback for periodic snapshots: no per-call auth, but coarser and Android-side, so it does not suit live or cross-platform sync.

For most buyers the first route is the backbone and the second is the safer default when only reads are needed; export is worth wiring only for occasional bulk pulls. We will say which fits once we see what you need the data for.

What we hand over

Concrete artefacts, tied to this app's surfaces, not a generic kit:

• An OpenAPI-style specification of the authorized read/write surface — group, members, transactions, permissions, change records and rates — with the field shapes observed during the build.
• A protocol and auth-flow report covering the Firebase Authentication sign-in (email/password, Google or Facebook), ID-token handling and refresh, and the JSON path conventions.
• Runnable source for the key flows in Python and Node.js: authenticate, list a user's groups, pull and normalise transactions, resolve the minimised debts, sync incrementally off the change log.
• Automated tests against a consenting account or sandbox, including the currency-switch and split-rule edge cases.
• Interface documentation and data-retention guidance aligned with the app's GDPR posture and its stated deletion path.

Reading transactions

Illustrative shape, confirmed against a consenting account during the build — sign in for an ID token, then read a group's transactions and handle the expiring token:

POST /v1/accounts:signInWithPassword        (Firebase Auth)
  { "email": "<consented user>", "password": "***", "returnSecureToken": true }
  -> { "idToken": "<jwt>", "refreshToken": "<rt>", "expiresIn": "3600" }

GET  https://<env>.firebaseio.com/transactions/<groupId>.json?auth=<idToken>
  -> {
       "-Nx9...": {
         "type": "expense",
         "purpose": "Cabin, 2 nights",
         "currencyCode": "EUR",
         "whoPaid": [ { "memberId": "m_3", "weight": "1" } ],
         "items":   [ { "amount": "240.00", "forWhom": [
                         {"memberId":"m_1","weight":"1"},
                         {"memberId":"m_2","weight":"1"},
                         {"memberId":"m_3","weight":"1"} ] } ],
         "dateTime": 1747000000000
       }
     }

# token refresh on 401 / expiry
if status == 401 or expired(idToken):
    idToken = refresh(refreshToken)          # retry the GET once
# group currency just changed? re-pull the whole group:
#   server-side conversion rewrites every transaction amount

Field names here are representative of the observed structure; the delivered spec pins the exact shapes seen against the account used for the build.

Consent and GDPR

This is not a banking or payment app — no money moves through it — so no account-information or open-banking regime applies. The governing regime is data protection. Per its privacy policy, Settle Up is run by Step Up Labs Inc., a US-incorporated company storing data in Google Cloud in the United States, with a named EU representative and data protection officer and a stated commitment to GDPR. Practically, that shapes how we work: a written scope and NDA, access through an account you consent to rather than anyone else's data, logged and data-minimised pulls, and a deletion design that follows the app's own removal path (the policy directs deletion and extra exports to privacy@settleup.io). Retention on the app side is described as indefinite unless the service shuts down; we keep what the integration retains far tighter than that.

What we plan around

Two parts of this app need deliberate engineering, and we account for both rather than discover them late.

Currency is the first. A group can switch its currency, and when it does a server-side function rewrites every expense in that group through a conversion. We design the sync so a currency change invalidates the cached group and triggers a full re-pull, and we read post-conversion amounts so downstream totals match what members see in the app.

Computed debts are the second. The who-owes-whom result is not a stored balance — the app minimises the number of transfers, so a naive pairwise sum will not match the figures users actually see. We replicate that minimisation (or read the app's own computed result) so any settlement instruction we emit reconciles to the app exactly.

There is also a platform asymmetry worth stating: CSV export is an Android-side convenience and thinner on iOS, so for any cross-platform need we key the integration on the sync layer, where the client platform stops mattering, and maintenance carries a scheduled shape check so a client-side change surfaces as a failed assertion rather than silent drift.

Where teams point it

• A travel or events operator pulling each trip group's expenses and the minimised settlements into its own reimbursement and reconciliation flow.
• A flatshare or property manager mirroring recurring shared costs into an internal ledger, read-only, so tenants keep using Settle Up while the back office stays in sync.
• A finance team consolidating multi-currency group totals into one reporting currency using the app's own daily rate history.
• A community treasurer surfacing members sorted by balance on an internal page, refreshed from the change log rather than re-read in full.

Staying honest over time

The change records are the asset for keeping a sync trustworthy. Each carries a user id and timestamp, so the delivered source pulls incrementally from the last seen change instead of re-reading whole groups, which keeps cost down and makes conflicts detectable. We pair that with a light scheduled probe: authenticate, read a known group, assert the field shapes, and alert on a mismatch. When the app's clients change, that probe fails first, before any downstream report does.

App surface

Store screenshots, for reference to what users see versus what the ledger holds underneath.

Sources checked

Checked in May 2026 against the app's own privacy policy (data storage in Firebase and Google AppEngine, US location, GDPR posture, EU representative and DPO, deletion path), Step Up Labs' engineering write-up on Cloud Functions (group, member, expense and change-record entities; server-side currency conversion and audit logging), and the team's 2025 monetisation review (scale and platforms). Primary sources:

• Settle Up privacy policy — data controller, storage location, GDPR roles, deletion and export contact.
• Step Up Labs — Cloud Functions experience — backend entities, change tracking, currency conversion.
• Step Up Labs — 2025 monetisation summary — active-user scale and supported platforms.

OpenBanking Studio integration desk · mapping reviewed 2026-05-16.

The wider field

Same-category apps a unified integration is often asked to cover alongside Settle Up. Listed for ecosystem context, not ranking:

• Splitwise — long-running shared-expense ledger tracking who owes whom across recurring groups; the most common app a buyer wants normalised against the same schema.
• Tricount — group trip and shared-cost tracker with multi-currency balances; similar member-and-expense model.
• Splid — account-free group trip splitting that holds expenses and balances per shared group.
• Plates — restaurant-focused item-level splitting that computes per-person totals including tax and tip.
• Splitser — group expense and settlement tracking popular in the Netherlands, with shared-group balances.
• Spliit — open shared-expense tracker keeping group members, expenses and reimbursements.
• Venmo — its Groups feature adds ongoing shared-expense tracking and settlement on top of the wallet.
• PayPal — its split-a-bill feature records group bills and per-person shares inside the wallet.

Integrator questions

Where does Settle Up actually keep a group's expenses and debts?

Per its privacy policy and the team's own engineering write-ups, every group lives as a JSON subtree in a Firebase Realtime Database on Google Cloud, geographically in the United States. Expenses and incomes are stored records; the who-owes-whom figures are computed, not kept verbatim, because the app minimises the number of transfers between members.

Does the integration break when a group switches its currency?

It does not, because we plan for it. A group currency change fires a server-side conversion that rewrites every expense in that group, so we re-pull the group after a switch and read the post-conversion amounts rather than caching stale totals.

Can you sync read-only without writing anything back into a group?

Yes. The app already has a read-only access role, and the integration authenticates as a consenting account scoped to that role, so it observes the ledger and the change log without posting members or expenses back.

How do you handle GDPR and the fact the data sits in the US?

Settle Up is operated by a US-incorporated entity with a designated EU representative and data protection officer and stores data in Google Cloud US, per its privacy policy. We keep the build data-minimised, run it under NDA against a consenting account, and design deletion so it follows the app's own privacy@settleup.io removal path.

We only ever used the Android CSV email export — is that enough to build on?

It works for periodic snapshots, but CSV export is Android-only and coarser than the live tree, so we key the integration on the sync layer instead and treat export as a fallback. A working build is typically one to two weeks.

One commercial note, stated once. You can take this as delivered source code from $300 — the runnable integration plus its spec and tests, paid only after delivery once you are satisfied — or call our hosted endpoints and pay per call with nothing upfront. Either way the build cycle is one to two weeks, and the starting point is just the app name and what you want the data to do; access and compliance are arranged with you. Start at /contact.html.