Showing availability and taking bookings from your own website

4 minute read time · Updated June 18, 2026

One question we’re often asked is some variation of “how can people see our availability, or book with us, directly from our own website?” It’s a great question, and MIDAS gives you a few different ways to do exactly that. In this post we’ll walk through the options and help you pick the right one.

There are three features to know about. Two of them, Public Booking Requests and Public Web Bookings, are included as standard in every MIDAS system. The third, Web Calendars, is an optional add-on. They solve different problems, and they also work nicely together.

At a glance

Feature	What it does	Included or add-on?	Best for
Web Calendars	Embeds a calendar of your bookings into your own website, so visitors can see what’s on.	Optional add-on	Displaying your schedule or availability on your site.
Public Booking Requests	Lets visitors check availability and submit a booking request, which you approve before it becomes confirmed.	Included as standard	Taking enquiries you want to review before confirming.
Public Web Bookings	Lets visitors make and pay for a confirmed booking directly, with no approval step.	Included as standard	Instant, self-service bookings with online payment.

If you just want people to see what’s on

Sometimes you don’t need visitors to book anything online at all. You simply want to show them what’s already happening, or whether a particular space is free, right there on your own website. That’s what the Web Calendars add-on is for.

Web Calendars generates a tidy daily or monthly calendar of your bookings that you can embed directly into a page on your website using an IFRAME, or simply link to. You control exactly which venues and booking types appear, and how much detail is shown. With a little custom styling, you can even reduce a calendar down to a simple “available or booked” display for a particular room.

Web Calendars is our most popular add-on, but it is an optional paid extra rather than a standard feature. You can add it to your system at any time via mid.as/upgrade, or include it from the outset when you first purchase.

If you want people to request a booking

If you’d like visitors to be able to ask to book a space, but you want the final say before anything is confirmed, use Public Booking Requests. This feature lets non-users check your availability and submit a booking request, which lands in your system awaiting approval. A request only becomes a confirmed booking once a venue manager approves it.

This is ideal when you need to vet bookings, for example to check details, confirm payment separately, or simply make sure the request is appropriate before it goes in the diary. You can also restrict requests to particular email domains, and even set certain request types to be approved automatically.

If you want people to book and pay instantly

If you’d rather let visitors book a space there and then, with no approval step, use Public Web Bookings. This works much like Public Booking Requests, but instead of creating a request, it creates a confirmed booking straight away, including an online payment step so the visitor pays at the point of booking.

To accept payments for Public Web Bookings, you’ll first need to enable Stripe or PayPal in your system.

Both Public Booking Requests and Public Web Bookings are disabled by default, and need to be switched on by an administrator via MIDAS Admin Options → Public before they can be used.

The best of both: display and book together

Here’s where it all comes together. Web Calendars isn’t only for display. You can configure a calendar so that when a visitor clicks a date, they’re taken straight to your Public Booking Request or Public Web Booking screen, with that date already selected for them.

That means you can show an attractive calendar of what’s on directly on your own website, and let visitors click through to request or book an available slot in a couple of taps. It’s a great way to combine a polished public-facing display with the booking features already built into your MIDAS system.

Which should you choose?

Want to show your schedule or availability on your website? Use Web Calendars.
Want visitors to request a booking that you approve? Use Public Booking Requests.
Want visitors to book and pay instantly? Use Public Web Bookings.
Want to display and let them book in one journey? Use Web Calendars linked to either of the public booking features.

Whichever route suits you, you can find full setup details in our help documentation for Public Booking Requests, Public Web Bookings, and the Web Calendars add-on. If you’re not sure which is the best fit for your organization, just get in touch and we’ll be happy to point you in the right direction.

Tags: addons, public booking requests, web calendars, web requests

Permalink

Capture exactly what you need: getting creative with custom fields

5 minute read time · Updated June 17, 2026

Every organization runs its bookings a little differently. Out of the box, MIDAS captures the essentials with each booking – the date and time, the venue, who it’s for, the type of booking, the number of attendees, any resources, and a notes field. For your clients, it records names, organizations, contact details, and addresses.

But what if you need to capture something specific to your operation? Perhaps a a signed waiver, a purchase order number, or a link to a room layout. That’s exactly what custom fields are for. They let you add your own booking fields and client fields on top of the standard ones, so MIDAS records precisely the information you need.

In this post we’ll look at the types of custom field available, and share some real-world ideas for putting them to work.

The building blocks

You can add custom fields to either bookings or client records, and each field can be one of the following types:

Text – a single-line text field, ideal for short pieces of information such as a reference or order number.
Text Area – a multi-line field for longer notes. You can set how many rows it shows by default, and make it resizable so users can drag it larger when they need to.
Number – accepts numerical input only.
Checkbox – a simple tick box, perfect for yes/no questions.
List (Single Select) – a drop-down from which one predefined item can be chosen.
List (Multi Select) – a drop-down from which several items can be chosen at once.
Range – a slider control for picking a numeric value between a minimum and maximum you define.
URL – a clickable web link to an external resource.
File – lets users upload and attach files or documents directly to a booking or client record. (Available in self-hosted editions of MIDAS – see why file fields aren’t available on cloud-hosted systems.)

Each field can be shown or hidden, made optional or required, restricted to certain users, and given a short description that appears above it to guide whoever is filling it in.

Ideas for custom booking fields

A waiver or terms checkbox – with a link

A custom checkbox field with an HTML enabled description.

A field’s description accepts simple HTML, which opens up some neat possibilities. Add a Checkbox field named something like “I have read and accept the Terms & Conditions of Hire”, and in its description include a link to your waiver or terms document. Mark the field as Required, and a booking can’t be saved until the box is ticked – giving you a simple record that the waiver was acknowledged for every booking.

A link to supporting documents

A URL field is a tidy way to associate an external document with a booking without storing the file itself – useful on any edition, including cloud-hosted. You might link to a shared document, a SharePoint page, a risk assessment, or an event running order held elsewhere. Whoever opens the booking can jump straight to the relevant document with a click.

A purchase order or cost code

A simple Text field captures a PO number or internal cost code against each booking, ready to appear on the resulting invoice. You can even apply input validation to a text field using a regular expression, so MIDAS only accepts entries that match the format your finance team expects.

An expected-numbers slider

While MIDAS already records attendees, a Range slider can be handy for capturing a softer estimate – for instance a “Confidence in numbers” or “Setup complexity” scale – giving your team a quick visual cue when they open the booking.

Ideas for custom client fields

A salutation or title

A custom client "Salutation" field — A custom client “Salutation” field

A List (Single Select) client field with items like Mr, Mrs, Ms, Dr, and Rev means your emails and letters can address clients correctly, drawing on the field automatically through your templates.

Insurance certificates and contracts

Upload and attach an insurance document to a client record — Upload and attach an insurance documents to client records

On self-hosted systems, a File client field lets you attach an insurance certificate, signed contract, or accreditation document straight to a client’s record – so it’s always to hand when you need it, rather than buried in someone’s inbox.

Membership or account numbers

A Text or Number client field is the natural home for a membership ID, account reference, or loyalty number, keeping it alongside the rest of the client’s details.

Putting your fields to work in templates

Custom fields aren’t just for the booking screen. Each one becomes available as a template variable, so you can include its value in booking confirmation emails, invoices, and print outs. Rename or remove a custom field, and MIDAS automatically updates the corresponding variable references in your templates for you.

Custom field input validation with REGEX support

Getting started

Custom fields are managed via MIDAS Admin Options → Fields, where you can switch between your booking fields and client fields and add as many of your own as you need. For the full details, see our Manage Fields help documentation.

However you run your bookings, custom fields let you shape MIDAS around your process rather than the other way around. If you come up with a clever use of your own, we’d love to hear about it!

Tags: custom booking fields, custom fields

Permalink

Security Enhancements in MIDAS v4.42

5 minute read time · Updated April 29, 2026

MIDAS v4.42 brings several important security enhancements. Here’s what’s changed and why it matters.

Argon2id now the preferred method of password hashing

For many years MIDAS has utilized “bcrypt” to store password hashes. While “bcrypt” is still accepted industry practice, newer encryption methods like “Argon2id” offer improved protection.

“bcrypt” is computationally expensive. This means it takes a significant amount of processing time to compute each password hash. bcrypt also includes a configurable “work factor” controlling how “computationally expensive” each calculation is.

Back in 2017, a “work factor” of 10 was widely considered by security experts to be sufficient at the time, and this is the factor we used in MIDAS.

By 2020, computing power had evolved and so “best practice” was to upgrade to a “work factor” of 12, which we transparently rolled out to MIDAS for our v4.25 update that year.

Now in 2026, we’re firmly in the quantum computing and AI age. While bcrypt is still considered secure, it is only “computationally expensive” from a processing (CPU) perspective.

Newer methods, like “Argon2id”, are both processor-intensive and memory-intensive, and so offer an even greater line of defense against brute-forcing password hashes.

We’ve implemented Argon2id for MIDAS v4.42. End users won’t see any difference, but password hashes stored in each MIDAS system’s database are now more secure than ever, and will be automatically updated the first time a user signs in to v4.42.

Self-Hosted customers: You’ll need to install the Perl module “Crypt::Argon2” if you wish to take advantage of this security enhancement. If this module isn’t available on your server, MIDAS will fall back to using bcrypt.

Option to sign out a user everywhere when maximum number of failed sign-in attempts reached

One of the existing security features in MIDAS is the ability for the software to automatically ‘lock’ accounts after a configurable number of failed sign-in attempts. Account access can then be quickly restored by an administrative user, or via a link that MIDAS will email to you if your account becomes locked in this way.

An account becoming ‘locked’ due to a high number of failed sign-in attempts prevents further sign-in attempts being made on that account. Until now, any existing active sessions that the user may have were allowed to continue unaffected.

For MIDAS v4.42, we’ve introduced a new security setting (found under MIDAS Admin Options → Security) that, if enabled and a user account becomes automatically ‘locked’ due to a high number of failed sign-in attempts, all active sessions for that account will be automatically terminated as well.

Suspending a user account instantly expires all active sessions for the user

If an administrator manually suspends a user account, MIDAS will now also expire all active sessions for that user. Previously, if an account was manually suspended, it wouldn’t affect any currently active sessions — now it does.

Security Fixes

We’ve also addressed a handful of security and account-related bugs for v4.42 which were discovered by our team…

Fixed: Possible to bypass forced password expiry

One of the “legacy” settings in MIDAS is the ability for administrators to routinely force users to change their password. Enabling this option isn’t something that we recommend. Indeed, this is considered bad practice, as forcing users to regularly change their passwords actually harms rather than improves security.

Despite that, some organizations still insist on routine password change policies, and therefore, we’ve had to retain this option in MIDAS.

MIDAS v4.42 fixes a small issue related to this, whereby since v4.39, if a user is forced to change their password due to it having expired, the user could easily bypass this requirement by simply hitting reload/refresh in their browser when prompted to set a new password. We’ve resolved this for v4.42.

Fixed: Weak passwords were allowed when passwords were reset

MIDAS includes a visual strength indicator when entering a new password. Very Weak, Weak, and Common passwords are blocked and aren’t allowed. However, a small bug existed that could allow a weak password to be chosen during a password reset. This has been resolved for v4.42.

Fixed: Not possible to add new user accounts in suspended state

Administrators have extensive control over the permissions that can be assigned to each individual user account. Individual user accounts can also be quickly ‘Suspended’ by an administrator. Until now, however, a small bug prevented new user accounts from being added in an initial ‘suspended’ state. This has now been resolved for v4.42.

3rd Party Deprecations and Updates

MIDAS includes a small number of 3rd party components, and it’s important to us that we use the latest versions of these wherever possible.

To that end, for MIDAS v4.42 we’ve updated jQuery to v4.00 and jQuery-Autocomplete to v1.5.0.

We’ve also deprecated qTip2, as this is no longer maintained by the developer. qTip2 was used in MIDAS for dynamic tooltips, like those you see when you ‘hover’ over the name of a venue in the booking grid.

Instead, we’ve built our own dynamic tooltip system from the ground up for v4.42.

Tags: security, v4.42

Permalink

Microsoft SMTP AUTH Deprecation in 2026: What You Need to Know

5 minute read time · Updated April 8, 2026

Microsoft SMTP AUTH Basic Authentication Deprecation

If your MIDAS booking system is currently configured to send emails via Microsoft’s SMTP servers, it’s time to take action.

Microsoft has announced that it will be retiring support for SMTP AUTH (also known as “Basic Authentication” for SMTP) in 2026. Once this change takes effect, any application which is configured to use Microsoft SMTP endpoints for outgoing mail will no longer be able to send emails.

For MIDAS, if you’re using Microsoft’s SMTP servers, this means that booking confirmations, reminder emails, and other automated notifications sent from MIDAS would silently fail – potentially disrupting your organization’s scheduling and communications.

Here’s what you need to know, and what steps to take before the deadline.

What Is SMTP AUTH and Basic Authentication?

SMTP AUTH is a method that allows applications to authenticate with a mail server using a username and password in order to send outgoing email. It has been widely used for decades.

Why is Microsoft removing Basic Authentication and SMTP AUTH?

It’s worth noting that Microsoft’s decision to retire SMTP AUTH is driven by their own platform strategy around modern authentication – it doesn’t mean that sending email via SMTP is inherently insecure. Under the hood, SMTP works the same way it always has, and the username/password authentication used by SMTP hasn’t fundamentally changed. What Microsoft is retiring is the ability to authenticate to their mail servers this way, as they push users towards OAuth-based access within their ecosystem. MIDAS does not currently support OAuth, but this is not a concern — there are plenty of reliable, independent SMTP providers that continue to support standard SMTP authentication without any issues.

Are You Affected?

You may be affected if your MIDAS booking system’s outgoing email settings are currently configured to use any of the following SMTP servers:

smtp-mail.outlook.com — used by personal Outlook.com/Hotmail accounts
smtp.live.com — an older endpoint also associated with Outlook.com/Hotmail/Live accounts
smtp-legacy.office365.com — a temporary fallback endpoint for Microsoft customers that stilled relied on SMTP AUTH after the initial Basic Auth deprecation push.
smtp.office365.com — An Exchange Online endpoint used by Microsoft 365 services.
outlook.office365.com — another Exchange Online endpoint sometimes used in place of smtp.office365.com

You can check your current email sending settings via MIDAS Admin Options > Email.

The good news is that the fix is straightforward, and we’ve made it as easy as possible for MIDAS customers.

For Cloud-Hosted MIDAS Customers

If you’re on our cloud-hosted platform, we have the simplest possible solution for you: switch to MIDAS’s built-in Zero-Configuration Email Delivery.

This option requires no SMTP credentials, no third-party accounts, and no technical configuration on your part. MIDAS handles email delivery on your behalf, so you don’t need to worry about SMTP servers at all. You can find full details on how to enable this feature in our dedicated guide:

👉 Zero-Configuration Email Delivery for MIDAS

We strongly recommend all cloud-hosted customers make this switch at their earliest convenience – and certainly before Microsoft’s 2026 deadline.

For Self-Hosted MIDAS Customers

If you run MIDAS on your own server or hosting environment, you’ll need to update your outgoing mail settings to use an alternative SMTP provider. Fortunately, there are several excellent options available, many of which offer generous free tiers that would suit most MIDAS installations.

We recommend the following providers:

SMTP2GO

SMTP2GO is a reliable, cloud-based email delivery service with a free tier that allows up to 1,000 emails per month. It’s straightforward to set up and works seamlessly with MIDAS’s outgoing mail settings. Simply create a free account, verify your sending domain, and update your MIDAS SMTP settings with the credentials provided.

Mailgun

Mailgun is another popular transactional email service offering a free tier for low-volume sending. It provides robust deliverability, detailed sending logs, and is well-suited for automated system emails like those generated by MIDAS. After signing up and verifying your domain, update your MIDAS SMTP configuration with your Mailgun credentials.

To update your SMTP settings in MIDAS, navigate to MIDAS Admin Options > Email and enter the new SMTP server details provided by your chosen transactional email delivery service.

Don’t Wait Until It’s Too Late

According to Microsoft, their revised SMTP AUTH Basic Authentication Deprecation Timeline is as follows:

Now to December 2026: SMTP AUTH Basic Authentication behavior remains unchanged.
End of December 2026: SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed.
New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method.
Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication.

While Microsoft’s deadline is the end of December 2026, we recommend customers make this change sooner rather than later.

Email is a critical part of how MIDAS keeps your staff and visitors informed – from booking confirmations to reminders and notifications. A disruption to outgoing mail can go unnoticed until someone realizes they never received a confirmation, which can cause real-world scheduling problems.

Taking a few minutes now to update your settings will ensure uninterrupted email delivery well into the future. If you have any questions or need assistance, please don’t hesitate to contact our support team – we’re happy to help.

Tags: email, microsoft, smtp

Permalink