Creating and onboarding a client via the Glide API

All API calls are documented here.

Create the client in Glide with the above call. Bear in mind the following tips:

• To create a new client ucode must be unique, even amongst deleted clients. This is the client code.
  • This call will return 400 'Already exists' if the client code is taken.
  • You can update an existing client code using the call below:

• You can populate the main client partner and manager on this call, via the par and man parameters. You can supply either their Glide ID (preferred) or their initials (as held in Glide).
• The call will return the Glide ID of the newly created client, which you can use in all the following steps in this guide.

The next step involves activating or deactivating some or all of the recurring workflow systems. Technically, we activate the workflow sub-system. Whilst many workflows only contain one sub-system, they can support any number of them. A common example may be where a Year-End Accounts workflow is split between an Accounts and a Corporation Tax sub-system.

Bear in mind that all workflow sub-systems default to active or inactive, and so they will already have a status as soon as you have created the client. They can default to active for all clients, individual clients only or organisation clients only. You may therefore find yourself needing to deactivate a workflow programmatically. You can view the default status in the Glide web application workflow editor (sub-systems tab).

If you wish to change the default, please consult the Glide support team, as this needs to be undertaken with care to avoid changing the status of existing clients.

You can see a list of workflow systems by calling:

The systems that have the following values in CreationType can be activated or deactivated:

• NextYearEnd (a maximum of one active system will create jobs by reference to the 'Next Year End' on the client card summary tab).
• TaxYears.
• ClientDateTrigger.

Systems that return ManualCreation can not be activated or deactivated, as the concept is not relevant to them.

Please ensure that SystemStatus is returning Active. This means that the workflow system itself is in use in the Glide system. The above call will also share information about draft/deactivated workflow systems.

Once you know which workflow system you wish to interact with, you need to establish the relevant sub-system IDs. You can see a list of workflow sub-systems, with their parent system ID, by calling:

The response to the above call will include SystemID, which links back to the ID of the workflow system.

Once you know which sub-systems you wish to activate or deactivate, call the endpoint below:

• {id} is the Glide client ID returned by step 1.
• {sy} is the workflow system ID.
• {di} is the workflow sub-system ID.
• {value} is 1 for 'active' (i.e. to activate the workflow) and 0 for 'inactive' (i.e. to deactivate a workflow that has defaulted to active).

Remember, you only need to do this if the desired status for your new client is different to the default status that will apply to it.

All of the recurring workflow sub-systems will have a minimum of one route (essentially a version of the flow diagram), but they can have multiple versions. One route will be the default route, and all active clients will use that route by default.

If your sub-system has more than one route and if you do not want your new client to use the default, follow this step to change the allocated route.

You can see the default route name and ID in the sub-systems response.

You can establish a list of routes either by reviewing the Glide client card interface, where you'll only see a route dropdown if there is > 1 available route, or by calling either of the endpoints below:

The first call will return all routes. The second call requires a sub-system ID to be supplied as {id} and will return routes for a specific sub-system.

If you determine that you need to change some routes, then you can do so with the following call:

• {id} is the Glide client ID from step 1.
• {sy} is the workflow system ID.
• {di} is the workflow sub-system ID.
• {value} is the route ID.

Next, you need to consider setting the first job date. If you do not have access to this information, then you could instead direct a user to complete this step via a message or similar.

The 'first job date' simply means the earliest job that the practice is responsible for completing. Depending on the situation with the new client, this may be in the past or future.

What you need to do here depends on the System.CreationType.

Where the Creation type = NextYearEnd:

It is likely that one workflow system will create jobs by reference to the Next Year End field on the summary tab of the client card.

If you have supplied a valid UK company number in step 1, then this date should have been extracted automatically from Companies House in step 1, meaning you do not need to do anything here.

❗At the time of writing, GET /clients/info/{id} does not return NextYearEnd, meaning you can not programatically check to see that the Companies House call returned a date. This shall be added in the near future. For now, we would recommend assuming it worked if you supplied a valid company number and directing the user to check the date in all cases that the workflow system is active.

If you have clients active on this system who do not have a company number (e.g. an unincorporated client or overseas entity), then you should enter this date, using the call below:

In the request body, supply:

• ucode - being the Glide client code (❗Not the Glide ID - a version using the Glide ID will be released soon).
• opt_nextyearend - being the first job date you wish to set in YYYY-MM-DD format.

Where the CreationType = ClientDateTrigger:

These workflow systems are similar to the above in that we need to supply the first job date; however, they differ in that the trigger fields are fully customisable, and so we first need to establish the IDs of the trigger fields we may be setting.

You can return a list of trigger fields using the call below:

• {id} is the workflow system ID.

Once you know which trigger you wish to populate, you can do so with the call below.

• {id} is the Glide client ID from step 1.
• {irc} is the trigger field ID from the /system/{id}/triggers response.
• {value} is the first job date in the format YYYY-MM-DD

Please note that you do not need to literally create the first job. By setting the trigger, this will happen automatically on the auto-creation date. If this date is in the past, then the system will create the job overnight.

Where the CreationType = TaxYears:

Tax Year style workflow will create a job for all active clients once a year, on a date you determine globally for the tax year. Where this date has passed, the integration should direct the user to consider whether this client needs a job for this tax year. This job can then be created by a user in the Glide application. An API call to do this shall be available in Q2 2026.

The Glide client record will potentially contain other fields, and you may wish to set some of these as part of your programmatic onboarding process.

If you wish to do so, these two calls below will be useful.

Firstly, to establish which fields you have available, consider using the call below. As an alternative, you could navigate in the Glide application to the 'Config' menu and then 'Edit additional client fields'. Their IDs would also be available in the 'Config' menu under 'Database codes summary'.

To set the client fields, you would then use one of these calls:

In the above call, you should rawurlencode() the value to avoid issues with special characters, or consider using the call below, where the value is sent in the form field.

• {id} is the Glide client ID from step 1.
• {irc} is the Glide field ID from the /editor/systems/clientfields/list response.
• {value} is the value you are setting.

The value you are setting depends on the field type, as follows: