Zapier lets you connect Renterra to thousands of other apps without writing any code. This article covers the one-time setup: creating an API key, pointing a Renterra webhook at Zapier, and understanding the data Renterra sends. Once this is done, you can build automations for any app Zapier supports.

Renterra doesn't have its own Zapier app yet, so you'll use Zapier's built-in Webhooks by Zapier to talk to us. That means two things:

API keys and webhooks aren't available in Sandbox accounts, so you'll need to set this up in your live account.

Your API key lets Zapier read data out of Renterra — customer names, order totals, and anything else your automation needs.

Before Renterra can send you events, you need somewhere to send them.

These events are available today. Related events are grouped, so ticking order subscribes you to everything underneath it.

Each endpoint sends to a single URL, and each Zap has a single Catch Hook URL. So one endpoint feeds one Zap.

That means you'll usually want a separate endpoint for each Zap you build, subscribed only to the events that Zap should react to. Two Zaps that do different jobs — one that creates a record, one that closes it — need two endpoints.

Putting several events on one endpoint sends them all into the same Zap, which then has to work out which event it received and branch accordingly. That needs a Paths by Zapier step, and Paths is only available on higher Zapier plans. Separate endpoints avoid the problem entirely, and they're easier to troubleshoot because Message Attempts is listed per endpoint.

Do subscribe one endpoint to many events when a single Zap treats them all the same way — posting every Renterra event into a Slack channel, for example, or forwarding everything to a reporting tool.

Zapier needs to see an event before it can map the fields, and Renterra can send it a sample one. You don't have to create a real record just to test.

Once your Zap is built, fire a real record through it — save an actual quote, or close an actual order — before you turn it on. That confirms the whole chain works with your own data.

Click your endpoint in the Endpoints list to open its detail view. The Overview tab shows:

If a delivery failed, fix the problem and use the Replay button to send it again. You don't have to recreate the record in Renterra just to retest.

Before you build anything, open the Event Catalog tab. For each event it gives you two views side by side:

This is the reference to work from. An order.created payload, for instance, carries exactly ten fields on the order record — and knowing that up front tells you what you'll need to fetch from the API instead.

Three things to know:

Most Renterra events fire more often than you want your Zap to run. order.created fires for every quote, reservation, and rental, not just the one you care about.

Add a Filter by Zapier step right after your Catch Hook and set a condition on a field from the payload.

For example, to act only on Storefront quotes:

This keeps your Zap task usage down and stops unwanted records from reaching the destination app.

When you need more than the webhook gives you, add a Webhooks by Zapier > Custom Request step to call the Renterra API.

Configure the step like this:

Some endpoints you'll use often:

Most of the API is read-only. Customers can be created and updated, and contacts can be updated. Branches, vendors, inventory, orders, invoices, payments, work orders, and accounting data can be listed but not changed.

The full endpoint list, including every field and filter, lives in our API Documentation.

Every webhook Renterra sends is signed, but since a Zapier Catch Hook URL is already hard to guess, most automations don't need to verify it — if yours does, add a Code by Zapier step to check the signature before continuing.