- 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.
HubSpot + Ziggu
HubSpot and Ziggu are connected by Ziggu. We build the connection and we run it, so there is nothing to install in your HubSpot portal and nothing for your team to maintain. When a deal reaches a stage you choose, or when someone ticks a field on that deal, the project is created in Ziggu, the client is attached to it, and the documents on the deal come across. HubSpot stays the place where the sale is run. Ziggu is the client portal where your client lives with the result.
Key takeaways
- Ziggu builds and runs this connection. There is no app to install in HubSpot and no marketplace listing to find.
- You choose the trigger: a deal stage, or a simple yes/no field on the deal that someone ticks when a record is ready to move.
- Contacts, projects and the documents attached to the deal move from HubSpot into Ziggu.
- Inviting the client stays a deliberate step your team takes, so nobody sees a portal before it is ready.
- If you would rather own the connection yourself, IO Digital builds this integration on Ziggu's public REST API, and so can your own developers.
Why connect when HubSpot already handles the follow-up
HubSpot is built for your team: the pipeline, the sequences, the internal notes, the reporting. None of that is what a client needs once the contract is signed.
After the signature the questions change, and on a long project they keep coming for a year or more. When is my next choice due. Where is the document I signed. What did I already pay, and what is next. Those questions arrive by email and by phone, and every one of them costs somebody an afternoon.
That is the part HubSpot was never meant to carry. The handover is the point of the connection: the moment a deal closes, everything the client will need is already in one place, instead of scattered across a mailbox.
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, your project and your unit are the same record and those levels stay invisible. If you deliver ninety of something inside one project, you use all of them. The connection behaves the same either way; what changes is the mapping, which is the one conversation worth having properly.
What data moves between HubSpot and Ziggu
The first column is the name your team knows from the app. The second is the endpoint a developer would call if you ever wanted to rebuild or extend this connection yourself.
| What it is in Ziggu | Endpoint | Direction | When |
|---|---|---|---|
| The project, and the units inside it | /projects, /units | HubSpot to Ziggu | On your trigger |
| The contact on the deal, attached to the right unit | /customers, /unit_customers | HubSpot to Ziggu | With the project |
| The company behind the contact | /companies | HubSpot to Ziggu | With the contact |
| Documents attached to the deal, filed under the category you choose | /documents, /attachment_categories | HubSpot to Ziggu | With the project |
| The invitation to the portal | Sent from Ziggu by your team | Manual | When you decide the portal is ready |
How do you connect HubSpot to Ziggu?
- Ask Ziggu for the HubSpot connection. Because we build and run it, this starts as a conversation rather than an install.
- Decide the trigger with your sales team: a deal stage such as Contract signed, a yes/no field on the deal, or both.
- Agree what a Ziggu project is in your pipeline. One deal per project and one deal per unit are different mappings.
- Decide which documents on the deal should reach the client, and which category they appear under in Ziggu.
- Agree who sends the invitation and what has to be in the portal first.
- Run one deal end to end and look at what the client actually sees before you switch it on for the whole pipeline.
Prefer to own it yourself? The same job can be done on Ziggu's public REST API, by your own developers or by IO Digital, who build this connection for Ziggu customers. Endpoint reference: Ziggu API documentation.
Why the trigger is worth arguing about
A deal stage is the obvious answer and it works when every sale follows the same path. It stops working the moment you have deals that close but should not start yet, or projects that begin before the paperwork is finished.
That is why the field exists. A yes/no field, ticked by whoever knows, moves a record when it is genuinely ready without bending your pipeline around the integration. Most teams end up using the stage for the standard case and the field for the exceptions.
Why the invitation is a separate step
Everything else here is automatic, and the invitation is not. That is deliberate.
A project that has just been created is empty. If the client walked in the moment the deal closed, they would find a portal with nothing in it, which is a worse first impression than no portal at all. Because the invitation is a separate action, somebody looks at what arrived, adds what is missing, and then opens the door. One click, at the moment you choose.
Where teams use it
Starting the client experience without a scramble
The gap between a signature and the first real contact is where confidence is lost. When the deal creates the project, everything is already in place, so opening the portal is a decision rather than a project of its own.
Keeping the pipeline out of the client's view
HubSpot holds the forecast, the internal notes and every deal you did not win. None of that is client material. Ziggu shows the client their own project and nothing else, which is what makes it safe to give them access at all.
Handing over without a handover meeting
What sales entered is already in Ziggu when the delivery team picks it up. See how property developers use Ziggu.
What HubSpot and Ziggu do not do
- There is no Ziggu app in the HubSpot marketplace. Ziggu builds and runs the connection, which is a different arrangement from installing something yourself.
- Clients are not invited automatically. The connection prepares the project and attaches the contact; a person decides when the portal opens.
- Ziggu's public API has no webhooks. A connection you build yourself polls on a schedule rather than listening for events.
- Task management and milestones have no endpoint in the public API, so they cannot be read or written from outside Ziggu.
- The API is rate limited to 60 requests per minute across all endpoints, which is what shapes a first load of an existing pipeline.
- Ziggu does not replace HubSpot. Your pipeline, your sequences and your reporting stay where they are.
Questions about the HubSpot integration
Is there a Ziggu app in the HubSpot marketplace?
No. Ziggu builds and runs this connection for you, so there is nothing to install in your portal.
What makes a project appear in Ziggu?
A trigger you choose: a deal reaching a stage, or a yes/no field on the deal that someone ticks when the record is ready. Many teams use both.
Does the client get invited automatically?
No, and that is deliberate. The connection creates the project and attaches the contact; someone on your team sends the invitation once they have checked the portal is ready to be seen.
Do the documents on the deal come across?
Yes. They land in the project's documents in Ziggu, filed under the category you decide during setup.
Can our own agency build it instead?
Yes. IO Digital builds this connection on Ziggu's public REST API, and your own developers can do the same.
Does our client need a HubSpot account?
No. Clients only ever see Ziggu. HubSpot stays internal.
What happens to a deal that closes but should not start yet?
That is exactly the case the field trigger exists for. Leave the field untouched and nothing moves, whatever the stage says.
Last verified: 28 August 2026.
