Build Features With A REST API Layer For Rapid Deployment


“Don’t touch it,” you say to your team.

You’re referring to your 20-year old CRM running on PostgreSQL.

It works, but it’s old, so it’s not a system you want to go digging around in or mess with.

If you were to build on top of that CRM, it would be a huge undertaking and who knows what technical debt you’d incur by doing so.

Not really an option.

At some point you eventually want to move the data off of that older CRM, but that’s for later.

The task in front of you is that you need to build a support ticketing system AND you need the data in that CRM.

And it needs to be done FAST.

What’s the best way to handle this scenario:

  1. Without tying yourself down to some external platform that will lock you into their ecosystem
  2. Withing getting charged you more as you scale or,
  3. Without having to build it from scratch
  4. And without incurring a bunch of technical debt or added complexity to an old system

What you need is something flexible, which is what a REST API layer is.

A system that lets you create the core forms without starting from scratch AND be able to handle data supplements.

What do I mean?

Building A Data Supplement System

The goal is to build a new system, on the side, as a supplement to your 20 year old PostgreSQL-based CRM.

The central piece of a ticketing system will likely be a long-ish form that collects a number of pieces of data to create the support ticket.

You build that with drag and drop forms in before you finish your coffee. Done.

Now, a significant portion of the data that needs to populate the fields isn’t going to come from the user. It’s going to come from the CRM database.

Since everything in has an API, you can configure the form to pull all the relevant data from the CRM when the logged-in user creates a new ticket (new form).

This of course is easy because forms are client-rendered, which I talked about here.

And by the way, you can configure to authenticate against your existing users database—no need to create a new one.

Then whatever fields are left, the data supplements, the user completes and hits submit and the support ticket is built.

Where does that ticket live?

In, not the CRM.

Because no one’s touching that CRM.

Then, whenever you need to pull some data, such as show me all the tickets from this customer, it’s one API call to load those tickets. is acting like a RESTful database in this scenario.

A working prototype could be setup in a matter of days (or perhaps even less).

Think of as a thin, REST API layer that you put on top of your existing systems and that lets you introduce new features and capabilities with speed. That’s what I mean when I say rapid deployment.

And if you decide to ALT-F4-scrap the project rm -r /ticketingsystem/*, your CRM remains intact, just as it was before you started.

How Using A Supplementive REST API Layer To Build New Features Avoids Complexity With Your Existing Systems

Published by Wizard is a zero-trust, data governance strategy platform, embedded in your environment, that enables you to build business process workflow applications or anything that uses forms with lightning bolt speed. is unique in its reach to the application layer regarding governance because we acknowledge forms are the primary entry point into everything data related. Forms are the UI, forms are the data model, and forms are the API model.

LighthouseHQ Case Study: Digital Transformation
Get Answers

Need More Answers?

Ask and we'll get back with you in 1 business day.

Contact Us

Send us a message to contact support or ask a question.

Schedule a meeting

Open Source Platform

Read our FAQ to find out what exactly is Open Source

View the Platform Documentation

View the API Documentation

View the Open Source Code

Learn More

Learn How It Works

Read the Release Notes

Discover Industries that use

Read our Blog