👀  Hiring Founding Technical Product Owner (Integrations) →



What is Agave?

Agave is the Unified API for Construction. We give developers a single API to access data and take actions across software commonly used in construction - project management, ERP, scheduling, bidding, and more.

What is a Unified API?

A Unified API is a single interface for software applications in the same category. It makes integration easier by abstracting away the differences between applications and providing a standardized endpoint, authentication, and normalized data. It creates a consistent developer experience with less integration hassle, eliminating the need to learn the intricacies of each service.

Who benefits from using Agave?

Software developers building construction products: Agave provides a front-end component to display in your application that lets users pull-in data from other products (e.g. Procore). Agave also lets you take action on behalf of your users in those products (e.g. sync data, create entries). Agave helps your application offer more functionality and attract more customers so you can grow faster. We reduce the time it takes to launch new integrations from weeks to hours. More Details

Software developers at construction companies (e.g. speciality contractors): Agave unifies your internal data in a secure layer, creating connections between sources (e.g. estimates are tied to projects, which have a start and end date). This creates a reliable source of truth to use for internal products like dashboards, project archives, supplier databases, and document workflows. Agave gives you a simple way to keep data in sync across software, particularly useful for companies working on multiple projects and across multiple systems simultaneously. More Details

Do you support white-labeling?

Yes. We have it under our “Scale” tier. We are happy to understand your needs and make it work for you.


Why does this problem exist?

Construction is a collaborative but fragmented industry. Project teams form, build, dissolve, and re-form in different ways. Each team uses varied tools that represent data differently.

The past decade has produced a variety of specialized products, with no single one serving the full needs of builders. These tools span project management, scheduling, finances, estimates, materials, bidding, safety, labor tracking, and more.

A typical construction employee uses 3-6 applications every day, and might interact with 4-5 different parties on a given project, each using different software. If this sounds messy, it is!

What’s the impact of this problem?

Lack of data access and interoperability across systems creates waste and makes answering questions that span products difficult. Cross-cutting questions about risks, cost, efficiency, and productivity are hard to answer, and people waste time doing repetitive double entry to keep records in sync.

According to the National Institute for Standards and Technology, the US construction industry generates more than $16 billion every year in waste due to lack of data interoperability between project stakeholders. This erodes margins unnecessarily, and lowers morale for employees.

Software developers building products also struggle to connect to the range of systems used by their customers. Even simple applications need to spend months building integrations one by one, or thousands of dollars for consultants to connect systems before launch. This stifles innovation, and slows progress.

While 48% of the construction industry views integrations as “very important” when making a purchasing decision, a full 27% of apps do not support any integrations.

Does this problem exist elsewhere?

Yes. Industries like consumer banking, payments, and payroll all suffer from fragmented systems and data silos. Companies like Plaid, Stripe, and Finch are solving this by making data integration and APIs their core business.

These companies provide a single platform that others can build on. Their systems are key building blocks that catalyzes innovation by saving time for software developers, who can instead invest in features that make their products unique.

We’re creating this building block for construction, one of the world’s oldest, largest, and least digitized industries. The time is right, with construction tech startups receiving $1.3 billion in funding during 2020 (+56% since 2019) and $2.1 billion in 2021. We’re here to ensure that integrations in this growing ecosystem are no longer a barrier.

Team / Background

Why can Agave solve this problem?

We’ve spent the past seven years solving this problem in different contexts. First, at a startup called Graphiq, where we helped consumers make more-informed decisions. Then, after being acquired by Amazon, where we enabled Alexa to answer millions of questions per day for customers worldwide.

In both cases, we solved problems of connecting data across thousands of sources in a central structure we called a knowledge graph, underpinned by an ontology. Then, we built applications on top of this, like natural-language Q&A, automated data visualizations, and Alexa knowledge skills.

We’ve traveled far into the “idea maze” of uniting scattered data and making it useful for end-users. We’ve identified patterns in construction that we’ve seen before, and have an edge solving this.


Can’t I do all of this myself in-house?

If you have software developers, it’s possible to build integrations in-house. However, each one takes weeks to months to finish. Legacy on-prem systems can take more than a year!

This work is not enjoyable (ask your developers), is not differentiated (all Procore integrations look the same), comes with risks (e.g. maintaining security standards), and requires ongoing costs (e.g. scrambling to account for changes in underlying systems).

Third-party consultants can streamline this process. But they require engagement meetings, partnership agreements, hands-on assistance, and ongoing maintenance.

Why is Agave better?

Agave abstracts the differences between systems and packages them in a single, reliable, secure API. Agave removes the need to understand each product you want to integrate with, map sprawling data models to your own, ensure security, maintain stability, spar with legacy systems, handle rate-limiting, decipher error codes, manage authentication, monitor changes, and more.

Just like Stripe and Plaid remove the need to write custom code to integrate with every credit card and bank, Agave removes this headache for every project management, ERP, CRM, scheduling, and bidding software.

Agave offers SDKs in multiple languages, consolidated docs, out-of-the-box security, centralized logging, a single data model that standardizes terminologies across systems, normalized data, standardized pagination, and lower maintenance costs.

Agave is the fastest, most self-serve way to add integrations today, and offers pricing that scales with your growth.

Will I be locked into Agave?

We won’t lock you in. If you need to migrate away, Agave will provide a full list of Agave id and source system id pairs to help you move things over.


How does Agave auth work?

Agave supports the native authentication workflow for each source system (such as Procore, QuickBooks Online, or ServiceTitan) and present you with a simple OAuth-like flow to get a persistent token for each authenticated user account.

If the source system supports account-level permission and scope configuration, Agave preserves and acts according to those limits.

More details on Agave authentication workflow

Will access tokens expire?

Agave handles token refresh so they will never expire for you.

Do I need to install the Agave API app in the marketplace?

For the source systems that have a marketplace (Procore, BIM 360, Autodesk Build), yes.

Do I need to install the Agave API marketplace app for each user or each account?

No, marketplace apps are typically installed on the company-level. It only needs to be done once for each company by an admin.

Do you support this field in your unified model?

We try to make our data model comprehensive and contain all the common fields used in the industry and are receptive to suggestions. We are always happy to add common field to support new use case.

For the fields we don’t yet support, you can still get it by access source data. We provide you the raw output from the source system, so you’re not limited by our development speed.

Why do we use the “string” format for fields that are dollar or number-based like “amount”?

What specific format to use for encoding decimal values accurately is pretty hard — JSON which we use as the exchange format doesn’t have float or double or anything; just a number format for everything.

Some APIs return strings for monetary values (e.g., PayPal), others which deal exclusively with actual transaction amounts that are always larger than 0.01 (one cent) can safely use float, and others (like Stripe) denote the value as multiples of the smallest fraction (“amount: 100” is 100 cents or $1). For us, some of the values we deal with can be super small (e.g., $0.0000001 per individual nail).

Of the APIs we work with, Procore and Jobpac and BIM360 and ACC and ServiceTitan are JSON APIs that return strings for dollar amounts. QBD, QBO, Sage Intacct, Spectrum are XML and the value is string (and in any case, always accurate and lossless). CMiC is the only system I can find that uses JSON numbers for amounts.