Microsoft SharePoint + Ziggu

Microsoft SharePoint and Ziggu connect through Ziggu's public REST API. The documents you mark for sharing are written into the right project in Ziggu, filed under the right category, and the client is notified. SharePoint stays your team's workspace with its drafts and internal versions, and the client portal shows the client only what you decided to share.

Key takeaways

• Microsoft SharePoint 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.
• Documents are matched to a project and a document category in Ziggu, using your SharePoint folder structure or metadata as the rule.
• Clients never get a SharePoint login. They see the documents that were written into their project, and nothing around them.
• This is a scheduled connection, not an event-driven one. A file appears in Ziggu on the next run, and you set how often that is.

Why not share the SharePoint folder

Because the folder is not client-ready and never will be. It holds drafts, superseded versions, internal notes and the files belonging to other clients. Sharing a subfolder means maintaining permissions on every new folder forever, and one wrong inheritance is a disclosure.

The usual workaround is emailing the final PDF, which creates its own problem: nobody can tell later which version the client actually received. Writing the document into the client's project in Ziggu answers both. There is one current version, the client is notified, and you can see who opened it. See Documents.

What data moves between Microsoft SharePoint and Ziggu

The first column is the name your team knows from the app, the second is the endpoint your developer will actually call.

‍

How do you connect Microsoft SharePoint to Ziggu?

Three routes, same API underneath. Pick the one that matches who is going to maintain it.

1. 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.
2. Have your integration partner build it. Same API, same token, someone else's maintenance.
3. Use a ready-made template on Peliqan. Deployed and configured rather than written, and adapted per customer.

Whichever route you take, one decision comes first and it decides everything else: the rule that says which file belongs to which project. A folder per project is the simple version. A metadata column is the flexible one. Settle that, run it once on a single project folder, and look at what the client would see before you widen it.

Where teams use it

Sharing the approved version, not the folder it came from

Your team keeps working the way it works, with drafts and revisions in SharePoint. Only what your rule marks as shareable crosses over, so the client gets the approved plan and never sees the six versions before it.

Letting the handover pack assemble itself

Every document that has to reach the client at handover is already filed in SharePoint. Rather than building a pack by hand at the end, each document lands in the client's project as it becomes final, and the pack exists because the project is finished.

Giving a whole portfolio the same document structure

One folder pattern in SharePoint becomes the same category structure in every project in Ziggu. A client on one project and a client on another find their documents in the same place, which is what makes the portal predictable enough that people stop asking. See how property developers use Ziggu.

What Microsoft SharePoint and Ziggu do not do

• This is a scheduled connection, not an event-driven one. A file saved in SharePoint appears in Ziggu on the next run. You set the schedule.
• There is no Ziggu app inside SharePoint. Somebody builds or deploys the connection, whether that is you, your partner or a template on Peliqan.
• Projects are matched, not created. A document whose folder or metadata does not resolve to an existing Ziggu project has nowhere to land, so the mapping rule has to be right before you scale it up.
• 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 API is rate limited to 60 requests per minute across all endpoints, which is what shapes a first load of an existing document library.

Questions about the SharePoint integration

Do our clients need SharePoint access?

No. That is the whole point. Clients only ever see documents that were written into their own Ziggu project.

How does a file end up in the right project?

Through the rule you set: a folder per project, or a metadata column in SharePoint that names it. The connection resolves that to an existing Ziggu project.

How quickly does a document appear in Ziggu?

On the next scheduled run. You set the schedule.

Does the client get told when a document arrives?

Yes, the same way they are notified about any other document in Ziggu. You can also see who opened it.

Which way does it move?

Documents move from SharePoint into Ziggu. Anything beyond that is a decision taken when the connection is built.

We use something else for documents. Does that work?

Yes. Nextcloud and Dynamics 365 cover the same ground, on their own routes.

Last verified: 27 August 2026.