It looks like you’re from {country}
Project management
Rentman gets searched a few hundred times a month in the Netherlands, which by the standards of this page bank is nearly nothing. That number describes Google, not the rental and crew planning business — AV companies, event technicians and dry-hire warehouses run real money through Rentman, they just do not go looking for an integration by typing its name.
What they ask us for, once we are in the room, is specific: a website that shows what is actually free to book, not a static "contact us for availability" page, and a request that turns into a real quote in Rentman instead of a phone call somebody has to remember to log.
Rentman is Dutch software for equipment rental and crew planning: what gear is in which case, which case is on which truck, which crew member is booked on which job, and a quote or invoice that follows from all of it. It is used by AV and event companies, festival and stage suppliers, and dry-hire warehouses — a market small in headcount and genuinely serious in the money that moves through it.
A few hundred monthly searches for "Rentman koppeling" is a fact about how people search, not about the market. Nobody googles a system integration for software their whole company already runs on; they ask whoever built their last website, or they ask us directly. We would rather say that plainly than let a keyword number talk anyone out of a project that pays for itself in one avoided double booking.
All three come from the same gap: the site quotes availability it does not actually have, because it is not asking Rentman.
A request comes in through the website for a date that looks open, because the site has no idea Rentman already has that gear out on another job that week. Somebody finds the clash two days before the event, and now it is a phone call to a supplier or a client, not a website problem.
What you see instead
The website checks real availability in Rentman before it lets anyone request a date, so the clash never gets as far as a booking to begin with.
A client calls or emails describing what they need for an event, and somebody translates that into a Rentman quote by typing in equipment, days and crew from memory or from notes. Thirty minutes of quiet, careful work, for information the client basically already gave once.
What you see instead
A request submitted through the site becomes a draft quote in Rentman with the equipment, dates and requested crew already filled in, ready for someone to check and price rather than build from nothing.
A planner checks Rentman for who is free, then messages three people to confirm because the schedule changed twice this week and nobody fully trusts it. The group chats become the real planning tool, and Rentman becomes the thing that gets updated afterwards.
What you see instead
Crew status and job assignments stay visible from one place, updated as Rentman is updated, so a WhatsApp thread stops being the source of truth.
This is not an invoicing arithmetic problem — a rental business books an event once, not fifty times a day, so minutes-times-volume is the wrong lens. The honest cost is two things: the double booking discovered late, which costs a rented-in replacement, an apology, or a cancelled job; and the quote that takes half an hour to build by hand, on a request that could have arrived half-built.
One avoided double booking on a mid-size event, or a handful of quotes a month that go out same-day instead of next-day because nobody had to type them from scratch, is worth more than most of what a €1,700 project costs. Where it genuinely is not worth it: a very small operation quoting two or three jobs a month, run by one person who already knows the calendar by heart.
With Rentman the connection is the smaller half of the project; the real work is a website that can show genuine availability and hand off a clean request, which is as much a site feature as an integration.
A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.
The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.
WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.
WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.
When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.
Rentman's API is a REST API built around the objects a rental business actually has — projects, equipment, crew, quotes — not a generic invoicing model bent into shape. The arrow says which way something moves.
Real equipment availability per date (out of the tool)
What is actually free to book, item by item or by category, so a website can say yes or no honestly instead of showing a contact form for every date.
A website request as a draft quote or project (into the tool)
Dates, requested equipment and crew from the form arriving in Rentman as a draft, ready to check and price rather than build from a phone call.
Crew availability and assignments (out of the tool)
Who is booked on what, visible outside Rentman for anyone who needs to plan around it, instead of a message asking whether someone is free.
Customer and contact details (both ways)
Matched between Rentman and a website account or a CRM, so a returning client is recognised instead of typed in again for every job.
Confirmed bookings and invoices into your accounting package (out of the tool)
Once a quote is confirmed, the invoice lines go to Exact Online or Moneybird instead of being rebuilt there by hand.
Most projects start with the first two rows — real availability shown, a request arriving as a usable quote. The rest follows once that is trusted.
The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.
Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.
A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.
Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.
Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.
This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.
A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.
Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.
APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.
For Rentman specifically, the size of the market has no bearing on the price of the project: the work is the same whether a few hundred companies in the Netherlands use Rentman or forty thousand. What moves the price is how much of the availability and quoting logic the website needs to reproduce.
A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.
What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.
Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.
No — it means almost nobody searches for a system integration by the name of software their company already depends on. The volume tells you about Google, not about whether a double-booked flightcase or a half-hour hand-built quote is costing you real money. It usually is.
Yes, and it should not try to ask Rentman a question on every single page view. Availability is usually cached and refreshed on a short schedule — often every few minutes — which is honest enough for a booking website and does not put your site's speed at the mercy of Rentman's.
Yes. Dry hire is mostly the availability and quote flow without the crew planning half; full-service AV usually wants both. We scope the two separately, because a dry-hire site with a fast availability check is a smaller project than one that also has to reflect crew assignments.
