- Store all project files, plans, specs and contracts, in one clear place.
- Notify clients when new documents are uploaded.
- Track views to see who accessed each document.
- Clients always find the latest version, no confusion.
Teamleader Focus + Ziggu
Teamleader Focus and Ziggu connect through Ziggu's public REST API. A deal that reaches the stage you choose becomes a Ziggu project with its contacts attached, and quotations and invoices arrive as decisions and instalments. The point is not that the data moves. The point is that your client stops hunting: every choice on the project, your quotation and everything that follows it, waits in one client portal instead of scattered across your quoting tool, your mailbox and a shared drive.
Key takeaways
- Teamleader Focus connects to Ziggu through Ziggu's public REST API. You can build it yourself, have a partner build it, or use a ready-made template on Peliqan.
- A deal that reaches the stage you nominate becomes a Ziggu project, with the linked contacts already attached.
- Quotations arrive in Ziggu as decisions and invoices as instalments, so a client answers your proposal in the same place they approve everything that comes after it.
- A quotation that is signed electronically in Teamleader keeps that flow: the Ziggu decision carries a link that opens the Teamleader signature app.
- This is a scheduled connection, not an event-driven one. A deal that reaches your stage becomes a project on the next run, and you set how often that is.
Why connect them at all
Teamleader already sends a quotation, and the client can already sign it there. So the reason to connect is not the quotation. It is everything around it.
On a project with any customisation in it, a client does not make one decision. They approve the proposal, and then whatever your work requires after it: a drawing, a specification, a material, a change during the job, a report at the end. The list depends on your trade. The shape does not. If the proposal lives in your quoting tool and the rest lives in email, the client has two places to look and you have a follow-up problem.
Bringing the Teamleader quotation into Ziggu's decisions puts the whole sequence in one list, in the order it has to happen. The electronic signature stays where it belongs: Ziggu shows the decision, and the link on it opens the Teamleader signature app, so you keep the signing flow you already trust and the client still only opens one app. See Decisions and Approvals.
Project, unit, and why the difference matters here
Ziggu organises work as projects, and a project can hold one unit or hundreds. A unit is the smallest thing a single client has: one apartment in a development, one house, one fit-out, one order. Between project and unit sit optional levels, phases and lots and buildings, which large projects use and small ones never see.
If you run one job per client, which is how most Teamleader users work, your project and your unit are the same record and those levels stay invisible. That is worth knowing before you agree the mapping, because it decides what a Teamleader deal has to become.
What data moves between Teamleader Focus and Ziggu
Written into Ziggu through the public API. The first column is the name your team knows from the app, the second is the endpoint your developer will actually call.
| What it is in Ziggu | Endpoint | Direction | When |
|---|---|---|---|
| Contacts and the companies behind them | /customers, /companies | Teamleader to Ziggu | Every scheduled run |
| A deal that reached your chosen stage, as a new project | /projects | Teamleader to Ziggu | First run after the stage change |
| The contacts linked to that deal, attached to the project | /unit_customers | Teamleader to Ziggu | With the project |
| Quotations, as decisions with the options offered and a link to sign in Teamleader | /decisions, /proposals | Teamleader to Ziggu | Every scheduled run |
| Invoices, as instalments | /installments | Teamleader to Ziggu | Every scheduled run |
| The invitation to the portal | Sent from Ziggu by your team | Manual | When you decide the portal is ready |
How do you connect Teamleader Focus to Ziggu?
Three routes, same API underneath. Pick the one that matches who is going to maintain it.
- Build it yourself. Request an integration token from Ziggu, then write against api.ziggu.app/public. Tokens are issued per organisation. Endpoint reference: Ziggu API documentation.
- Have your integration partner build it. Same API, same token, someone else's maintenance.
- Use a ready-made template on Peliqan. Peliqan carries connectors for both Teamleader Focus and Ziggu, so the template is deployed and configured rather than written. Templates are copied and adapted per customer, so the field mapping is agreed at setup.
Whichever route you take, three decisions come first: which deal stage creates the project, which Teamleader fields land where in Ziggu, and how often it runs. Settle those, run it once against a single deal, and check the project, the contacts, the decisions and the instalments before you point it at the whole pipeline.
Where teams use it
Giving the client one place for every decision, not just the quote
The proposal comes from Teamleader. Everything the client has to approve after it does not. In Ziggu they queue up as one list the client works through, which is what stops the same client emailing you to ask what they still have to approve.
Handing a signed deal to the delivery team without retyping it
Sales works in Teamleader and stops there. The client, the contacts and the agreed scope are already in Ziggu when the delivery team opens the project. Nobody copies a contact into a second system, and nobody starts a project on an out of date address.
Running the same handover on every project
Because the trigger is a deal stage, the handover happens the same way every time. No project starts because someone remembered to start it. See how architects and contractors use Ziggu.
What Teamleader Focus and Ziggu do not do
- This is a scheduled connection, not an event-driven one. A deal that reaches your stage becomes a project on the next run, not in the same second. You set the schedule.
- There is no Ziggu app inside Teamleader and no Teamleader app inside Ziggu. Somebody builds or deploys the connection, whether that is you, your partner or a template on Peliqan.
- Clients are not invited automatically. The connection prepares the project and the contacts; a person in Ziggu decides when the portal opens.
- What a given implementation moves is agreed at setup. Treat the table above as the shape of the connection, not as a fixed contract.
- Ziggu's public API has no webhooks, so nothing pushes a change back to Teamleader the moment it happens in Ziggu.
- Ziggu's API is rate limited to 60 requests per minute across all endpoints, which is what shapes a first load of an existing pipeline.
Questions about the Teamleader integration
Is there a Ziggu app in the Teamleader Marketplace?
No. The connection runs on Ziggu's public REST API. You build it, a partner builds it, or you deploy a template on Peliqan.
What triggers a project to be created in Ziggu?
A deal reaching the stage you nominate. The project appears on the next scheduled run.
Can the client still sign the quotation in Teamleader?
Yes. The decision in Ziggu carries a link that opens the Teamleader signature app, so the signing flow does not change and the client still only opens one app.
Why bring quotations into Ziggu if Teamleader can already send them?
Because the quotation is one of many decisions on a project that is not off the shelf. Drawings, specifications, materials, changes and delivery reports all need an answer too. In Ziggu they sit in one list the client works through, in order.
Does the client get invited automatically?
No. The connection creates the project and attaches the contacts; someone on your team sends the invitation from Ziggu once the portal is ready to be seen.
Does anything sync from Ziggu back to Teamleader?
Not in the direction described here. This connection moves data from Teamleader into Ziggu.
What if we already use another CRM?
The same API serves HubSpot, Salesforce and Zoho.
Last verified: 28 August 2026.
