Cirqll API: what you can do with it and what you need for an integration

What is the Cirqll API?

An API is a system's front door for other software. Where you click and type in Cirqll, another system sends a request through the API and gets data back, or creates something.

The Cirqll API is a REST API that uses JSON and OAuth2. Cirqll names webhooks as the third building block: instead of asking over and over whether something has changed, your integration gets a signal as soon as something happens. The technical documentation is public at docs.api.cirqll.nl.

A few practical characteristics from that documentation (as of 6 October 2026):

• All times are in UTC, in ISO 8601 format. Useful to know when you send appointments or deadlines to another system.
• You can paginate, filter and sort results, load related data in one go and request only the fields you need.
• The API supports ETag headers, so you do not have to fetch unchanged data again and again.

Which data can you read and update through the Cirqll API?

Almost everything you work with day to day. The documentation describes these parts, among others:

• Customers and contacts: your clients and the people at those clients.
• Deals, assignments and contracts: the financial side, from a running deal to a signed contract with a start and end date.
• Tasks, appointments, to-dos and notes: the work around your customers.
• Emails and templates.
• Custom fields: the fields you created yourself in Cirqll, with their category (for example customer or financial), field type and options.
• Users, roles and webhooks.

For most parts you can not only read data, but also create, update and delete it. What an integration is allowed to do depends on the permissions of the user it connects with. That is an advantage: you can give an integration exactly as much room as it needs.

The custom fields are especially interesting. Many companies use them to record where a customer came from or which product group a deal belongs to. Those fields come along through the API, so you can report or automate on them later.

What do you use the Cirqll API for?

In practice we see three kinds of use come back.

1. Reporting and analysis

You fetch deals, appointments and contracts and load them into a data model. On top of that you build a Power BI dashboard with trends, conversion per stage and performance per sales person. How to do that step by step is explained in Connecting Cirqll to Power BI. Why you want a second layer next to Cirqll's own reporting is covered in Getting more out of your Cirqll reporting with Power BI.

2. Automation

A webhook reports that a deal changes stage or that an appointment has been added, and an automation platform does the rest: creating a task, alerting a colleague, sending a confirmation. You will find five concrete examples in Cirqll and Make.com: 5 automations.

3. Keeping data in sync with other systems

Leads from your website that go straight into Cirqll as a customer, or customer details that stay aligned with your accounting package. That avoids retyping and duplicate entry. Note: when syncing in both directions, agree up front which system is leading, otherwise they overwrite each other.

What do you need for an integration with the Cirqll API?

Whether you build it yourself or bring someone in, these five things need to be in place.

1. An OAuth2 connection. Cirqll only supports OAuth2. Your integration asks for permission through Cirqll's authorisation screen and then receives an access token and a refresh token. For that you need a callback URL: the address Cirqll sends the user to after logging in. Platforms such as Make take care of this for you.
2. Tokens that refresh automatically. A Cirqll access token is valid for 15 days, a refresh token for 30 days. If your integration does not refresh them in time, it simply stops, often without anyone noticing. In practice this is the most common reason a home-built integration "suddenly" stops working after a few weeks.
3. A user with suitable permissions. Do not connect through the owner's account, but through a user that can only do what the integration needs. A reporting integration does not need to delete anything.
4. Allowing for the limit. Cirqll allows a maximum of 100 requests per minute per client. Above that you get an error (429 Too Many Requests) and have to wait a minute. Every response tells you through headers how many requests you have left. For a first large import or a scenario that loops through hundreds of records, build in pauses or batches.
5. A place where the integration runs. That can be an automation platform such as Make, Power BI itself, or your own script or cloud function. If you want to keep history or combine Cirqll with other sources, a separate database as an intermediate layer is often the wisest place. That is data engineering work.

Also: personal data flows through the integration. Record which data goes where and choose EU storage where possible.

Build it yourself, Zapier, Make or a ready-made connector?

You do not always have to program against the API yourself. There are roughly four routes.

• Zapier. Cirqll offers its own Zapier integration, with triggers for new customers, tasks, notes and contracts, among others. Fine for simple "if this, then that" steps.
• Make.com. At the time of writing there is no ready-made Cirqll app in Make, so you work with a webhook module and an HTTP module with OAuth2. A bit more setup, but you can use everything the API offers, including multiple steps, conditions and error handling.
• A ready-made connector for reporting. For Power BI you do not need to build the integration yourself. With the Cirqll Power BI Connector the tables arrive ready to use, with a dashboard template included.
• Developing it yourself. Your own script or application gives the most freedom, but then you are also responsible for tokens, limits, error handling and maintenance.

Our rule of thumb: choose the simplest route that answers your question, and only build it yourself when the standard routes really fall short.

Example: from question to working integration

A fictional example to make it concrete. A wholesaler with four account managers works in Cirqll and wants two things: every Monday an overview of contracts expiring within 60 days, and a monthly report of won deals by customer source.

This is how they approach it:

1. Sharpen the question. Which contracts count? Who gets the overview? What exactly does "won" mean?
2. Check the fields. The source is stored in a custom field on the customer. Through the API it turns out that field is empty for part of the customers, so that is filled in first.
3. Choose the route. The contract overview becomes a Make scenario that requests the contracts every Monday, filters on end date and creates an email or task per account manager. The monthly report goes into Power BI.
4. Set up the connection. A separate Cirqll user with read-only permissions for reporting, and an OAuth2 connection that refreshes tokens automatically.
5. Test and check. Do the number of contracts and the totals match what they see in Cirqll? Only then does it go live, with an alert if a run fails.

The result: no more manual lists on Monday, and a monthly report where everyone looks at the same numbers.

Help with your Cirqll API integration

Want to connect Cirqll without dealing with tokens, limits and error handling yourself? Take a look at the Cirqll Power BI Connector and dashboard template, see what we do in workflow automation and dashboarding, or check which other integrations we build. Not sure where to start? Read Automating Cirqll: which manual tasks to remove first.