The Frollo Platform comprises of a number of features and APIs. Here we look at our APIs and how they’re used from an architecture perspective.


Integrating with Frollo involves integrating the Management API and Client API. How these are integrated will depend on your architecture and use case.

The first step to integrate with Frollo is to get users and their transactions into the Frollo Platform using the Management API.

Once this is complete Webhooks should be setup. Webhooks allow the Frollo Platform to call your system when certain events occur. These are essential for messaging, notifications and change alerts.

Finally Frollo features can be integrated by integrating the Client API. Depending on your architecture this will either be done from a user context or by your backend on behalf of the user.

Once you have decided on your architecture see Getting Started for the next steps.

Management API

Management API

The Management API is designed to be used in a machine to machine (M2M) context to allow management of users, accounts and transactions on the Frollo platform. This should be integrated by your backend integration platform and used to create users, accounts and transactions in the Frollo system. Transactions created will then be enriched and be available to be consume from your backend platform.

  • Managing Users
  • Managing Accounts
  • Managing and Enriching Transactions

Client API

Management API

The Client API comprises of the user facing features such as fetching budgets or managing bills and is designed for a client app or website to use. If you choose to use a native mobile SDK these are the APIs that are consumed.

The Client API can also be used in an M2M context with an API Key to allow your backend integration platform the ability to use these features too.

  • Open Banking
  • Aggregated Accounts and Transactions
  • Budgets
  • Bill Detection
  • Goals
  • Other Features


Webhooks are necessary for your platform to receive certain events that occur. Events that can occur include:

  • Notifications and messaging
  • Feature lifecycle events
  • Data changes

Webhooks can be triggered as part of feature lifecyles, e.g. a user completing a goal or going over budget. They can also be triggered as part of user journeys to send notifications or messages. Most importantly though they can be triggered to alert that data has changed, e.g. a user performs a recategorise all on transactions or a transaction was enriched when using bulk APIs.

Integration Examples

In these two examples there is a server only integration and a direct app and server integration. Both show how each API should be integrated.

API Only

API Only integration

This architecture can be used when your integration platform is used to orchestrate all calls to and from Frollo. This allows Frollo features to be used in the most flexible way possible and allows Frollo features to be directly integrated into all platforms and combined with your existing client APIs. This scenario is ideal for situations where there is a web app, mobile apps and you want fine grained control to integrate Frollo features into your platform.

Both Management APIs and Client APIs are called from the backend integration platform. All calls are done with a M2M context so both user management and calling APIs on behalf of a user are done by the integration platform.

Use cases:

  • Multiple platforms
  • Fine grained integration control
  • Orchestrating multiple services together


API and SDK Integration

This architecture allows the mobile app or other client app to consume the Frollo APIs directly whilst also allowing the flexibility to consume Client APIs from the host too.

On the backend side of things the Management API is used to create users and load accounts & transactions into the Frollo Platform to power our features.

At the frontend Client APIs are called either directly or using an SDK to power user facing features such as viewing aggregated spending or managing goals.

Use cases:

  • Integrating the SDK
  • Simplicity and speed - no need to create APIs to wrap user facing features
  • Flexibility - features can also be used by the backend