Can you connect Woub to your existing construction software through an open API?

What does Woub's open API offer?

An API provides technical access through which software can request data or perform operations. Woub's open API gives developers a route to connect the project environment with other systems. Access permissions and appropriate setup are needed; ‘open’ does not mean project data is publicly accessible.

De Woub explanation of API integrations mentions development by your own IT department or supplier. Woub supports its own API's functionality and can discuss custom development on request. Make separate agreements for developing and managing the complete integration.

For a contractor, the first choice is practical: which handover keeps happening manually? For example, making an accepted instruction available as a recognisable project for the site team. Administration stays in the package used for that purpose. Woub supports daily project communication and follow-up alongside it.

An integration does not automatically resolve the division of responsibilities. Even when a project is created automatically, someone needs to make sure the right employees participate and site information is correct.

Which Woub data flows are demonstrably supported?

Distinguish between what the API documents and what a specific existing integration does. Both are verifiable information, but do not prove every combination of systems can handle the same handover.

The API documents project and checklist operations

The documentation consulted on 22 October 2026, Woub developer documentation, describes creating, retrieving and updating projects, and creating, retrieving and updating checklists, among other things. It also contains information about authentication, error codes and request limits. According to the documentation, an API key can be requested through support.

These are documented building blocks, rather than a promise that your full business process is already configured. For each operation, the developer needs to check which fields, permissions and conditions apply. The documentation was read for this article; no transactions with customer data were performed or customer integrations tested.

Existing routes show how specific an integration is

At Exact Bouw, the integration guide describes how a configured project status can trigger project creation in Woub. Quotation lines can be transferred by chapter as a checklist, with quantities and descriptions but no prices. This is a specific handover to site work, rather than proof that all financial or scheduling data moves both ways.

Exact Online has its own guide. Among other things, it explains how an accepted quotation with an appropriate reference can lead to project creation. Treat Exact Online and Exact Bouw as separate routes; the name ‘Exact integration’ says too little about functionality.

For Robaws, Woub describes a route through Softwareshaker Connect. The instructions mention projects and forwarding approved quotation lines into tasks in Woub. Here too, assess the settings and conditions for your environment.

View the Woub integrations before commissioning custom development. An existing route may be a better starting point. Then check precisely the handover you need; a product logo does not describe the data flow.

What is the difference between custom development and a standard integration?

An existing integration has documented functionality you can have configured. With custom development, you commission a specific handover. A one-off import is different again: it adds data but does not automatically keep it current.

Suppose your business software does not appear among the documented integrations. You want an approved instruction in that package to produce a project in Woub. That is a custom development request. Whether it is feasible depends on the capabilities and conditions on both sides.

Illustrative example: instruction P-104 to the site team

The steps below are a design example for an integration, rather than an already tested product route.

1. Determine the starting point. The instruction receives the agreed approved status in the source system. That is the event at which the handover may begin.

2. Choose the data. Record which project name, reference and necessary location details need to go to Woub. Leave financial information out if the site team does not need it.

3. Prevent a second project. The developer configures how source reference P-104 links to the Woub project. A repeated message must not create another project unchecked.

4. Make site work practical. Agree who checks setup, participants and required site information before the team starts.

5. Arrange corrections. Does the address change later? Record beforehand whether that change is transferred, which source remains the primary reference and who resolves a discrepancy.

The benefit to test is less repeated copying while retaining a recognisable project. That does not require a full copy of ERP in Woub. Nor does a change someone mentions in a conversation automatically become an approved administrative update.

Which technical partners can help?

Your own IT department, software supplier or integration partner can investigate technical feasibility. For the Robaws route mentioned, the Woub guide specifically refers to Softwareshaker Connect. That is a documented route for that application, rather than evidence that every partner supports every package.

Choose a party that understands both the work process and technical capabilities. Have them demonstrate more than creating a project once. Also ask what happens with missing data, a changed address, a repeated message or a temporarily unreachable system.

Record who is responsible for setup, daily management and recovery after errors. Woub can support its own API while the custom developer is responsible for translating between the two systems. Make explicit where an employee can turn if the handover stalls.

When requesting a quotation, also ask about recurring costs and maintenance when either system changes. A successful demonstration is a start; the management agreement determines how the integration remains useful.

How do you prevent incorrect integration claims?

Describe an integration as a specific handover. ‘Our software is connected’ says little. ‘An approved instruction creates a project with the agreed reference in Woub’ is verifiable, provided that route has actually been confirmed and tested.

Use five questions before going into use:

• What goes where? State the data, source, destination and direction.

• When does it happen? Record the event or agreed update time.

• Who determines what is correct? Assign the primary source and person responsible.

• What happens if it goes wrong? Test errors, repetition, corrections and recovery after an outage.

• What remains manual? Identify checks, approval and informing those involved.

The Woub documentation mentions authentication and request limits. Have the developer account for them and manage access appropriately. Do not share keys in project chats, and do not let error messages contain unnecessary customer data. These are setup considerations, rather than proof that your integration has already received technical approval.

An API also does not automatically authorise AI to change external administration systems. Anyone wanting to change a financial agreement, programme or model status needs to arrange the necessary authority and checks separately. Woub remains complementary to ERP, BIM, estimating, DMS and specialist scheduling.

A clear approach first, automation afterwards

You do not need to wait for custom development to improve project communication. Start with one project and the same recognisable reference as in your existing software. Agree who processes confirmed outcomes. Investigate an integration once it becomes clear which manual handover keeps recurring.

View the subscriptions and conditions and try Woub free for 14 days.

Start small. Enjoy the peace of mind. Expand only then.