Archisnapper + Ziggu

Archisnapper and Ziggu connect through Ziggu's public REST API. The snags your team logs on site reach Ziggu daily, where you decide which ones to publish to the client. From there the client follows the points that concern them, reports new ones, and confirms a repair when it is done. That confirmation can travel back to Archisnapper. Your client never opens Archisnapper, and none of it arrives as email.

Key takeaways

• Archisnapper connects to Ziggu through Ziggu's public REST API. You can build it yourself, have a partner build it, or use a ready-made connector from Peliqan or Stratokit.
• Snags sync daily. Nothing is visible to the client until someone on your team publishes it.
• You control what a client sees three times over: by category in Archisnapper, by publishing or not in Ziggu, and by who has access to which report.
• Clients can report a new snag in Ziggu. Your team reviews it and decides whether it goes into Archisnapper.
• A client can be asked to confirm a snag is resolved, and that status can flow back to Archisnapper as an update.

Why not just give the client access to Archisnapper

Because Archisnapper is a site tool. It holds every point on every job you have running, in the language your site team uses, at a level of detail that is right for them and overwhelming for a client. Handing them that view creates questions, not clarity, and it exposes work in progress that was never meant for them.

The alternative most teams fall back on is email, and that is worse. A snag reported by email lands in one person's inbox, where it has to be read, forwarded to whoever is responsible and chased. It gets lost, and when it does not, it still costs three messages.

Ziggu sits in between. The client sees the points you chose to publish, in plain terms, on their own project. They report a new one there, your team reviews it, and it goes into Archisnapper if it belongs there. See Reports.

Nothing reaches the client until you say so

The daily sync brings snags into Ziggu. It does not put them in front of the client. Someone on your team publishes them, and that gap is deliberate: a point logged at eight in the morning with a photo and a one-word description is not something you want a buyer reading at nine.

So there are three filters, and they answer different questions. Categories in Archisnapper decide what crosses over at all. Publishing decides when a client sees it. Access per report decides who sees it. Most teams end up using all three.

Closing a point without an argument

The part teams underestimate: in Ziggu you can ask the client to confirm a snag is resolved. They press one button. That confirmation can travel back to Archisnapper as an updated status, so your site team sees it where they work.

What that buys you is not the click. It is that six weeks later nobody is arguing about whether a point was fixed, because the client said so, in writing, at the time.

What data moves between Archisnapper and Ziggu

The first column is the name your team knows from the app, the second is the endpoint your developer will actually call. Where the table says project, read the individual home or unit if you deliver several inside one development: in Ziggu those are the same kind of record.

‍

How do you connect Archisnapper 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 connector. Stratokit builds connectors for construction software. Peliqan comes at it from the data side. Either is deployed and configured rather than written, and adapted to how you work.

Whichever route you take, two decisions come first. Which Archisnapper categories are client-facing, and which Ziggu project a given Archisnapper site maps onto. If you deliver several homes inside one development, that second decision is the whole job, because each buyer has to see their own points and nobody else's. Settle both, run it once on a single site, and look at what the client would see before you widen it.

Where teams use it

Fewer calls asking whether a point was picked up

A client who can see the point, its category and its status stops asking. Your site team logs a snag once, in the app they already use, and nobody types it a second time to put it in front of the client.

Catching what the client spots, without the inbox

Clients notice things. In Ziggu they report them against their own project, with a photo, and your team decides what happens next. Compare that to the same report arriving as an email at nine on a Friday evening.

Carrying delivery into aftercare instead of restarting it

The points logged at delivery are the same points still open a month later. Because they live in Ziggu's Reports next to the rest of the project, aftercare continues where delivery left off rather than starting from a fresh spreadsheet.

What Archisnapper and Ziggu do not do

• Snags sync daily, not the moment they are logged. A point recorded on site this morning is in Ziggu tomorrow.
• Nothing reaches the client automatically. Someone on your team publishes it. That is a feature, and it is also work.
• There is no Ziggu app inside Archisnapper. Somebody builds or deploys the connection, whether that is you, your partner, Stratokit or Peliqan.
• A client-reported snag does not go straight into Archisnapper. Your team reviews it first. That is deliberate.
• Projects are matched, not created. A snag that does not resolve to a project that already exists in Ziggu has nowhere to land, so the mapping has to be right before you scale up.
• Ziggu's API is rate limited to 60 requests per minute across all endpoints, which is what shapes a first load of an existing snag list.

Questions about the Archisnapper integration

Does the client see every snag?

No, and you control it three times. Categories in Archisnapper decide what crosses over. Publishing decides when the client sees it. Access per report decides who sees it.

How quickly does a snag appear?

Snags sync daily. After that it is visible to the client as soon as your team publishes it.

Can a client report a snag themselves?

Yes, in Ziggu, against their own project. Your team reviews it and pushes it into Archisnapper if it belongs there, so nothing reaches the site team unfiltered.

Can the client confirm a snag is resolved?

Yes. You can ask the client to mark a point resolved in Ziggu, and that status can be sent back to Archisnapper as an update. One button for them, and a written record for you.

We deliver twenty homes in one development. Does each buyer see only their own points?

Yes, provided the mapping is set up that way. Ziggu can split a project into the individual units inside it, and a snag is attached to one of them. Teams running one job per client never need that split: their project and their unit are the same record.

We use Letsbuild instead. Does that work too?

Yes, on the same kind of route. See Letsbuild and Ziggu.

Last verified: 27 August 2026.