Integrating Prospectus Plus with a CRM using webhooks

Prospectus Plus can send prospect and personalisation data to external systems when a personalised prospectus is created. This is most commonly used to pass lead data into a CRM, marketing automation platform, admissions system, spreadsheet, or a middleware service.

You can connect Prospectus Plus using tools such as Zapier, Microsoft Power Automate or n8n. However, you do not have to use Zapier. If your team, CRM provider, or integration partner can provide a webhook endpoint that accepts a structured payload, Prospectus Plus can post data directly to that endpoint.

Who this article is for

This article is for CRM, digital, admissions, marketing, or IT teams who want to receive Prospectus Plus data in another system.

It is especially useful if you want to:

• create a new enquiry or lead record in your CRM

• update an existing record when a prospectus is created

• store the user’s selected courses, subjects, campuses, or content preferences

• trigger follow-up communications, such as open event invitations

• avoid using Zapier or another third-party automation platform

• route data differently for different campuses, departments, or recruitment teams

How the integration works

Prospectus Plus uses an outbound webhook model.

This means Prospectus Plus pushes data out when a relevant action occurs. Your system does not need to listen to Prospectus Plus events or pull data from our platform. Instead, you provide an endpoint URL, and we send a POST request to it when a personalised prospectus is created.

A typical flow looks like this:

1. A user creates a personalised prospectus.

2. If Walled Garden Mode or a custom registration form is enabled, the user submits their contact details and any required form fields.

3. Prospectus Plus generates a unique personalised prospectus URL.

4. Prospectus Plus sends a structured payload to your webhook endpoint.

5. Your endpoint receives the payload and processes it.

6. Your CRM or middleware creates or updates the relevant record.

Depending on your setup, the receiving endpoint may be managed by your institution, your CRM provider, a third-party agency, or a middleware platform such as Zapier, Power Automate or n8n.

What Prospectus Plus needs from you

To configure a webhook integration, we normally need:

• the webhook endpoint URL that Prospectus Plus should post to

• any authentication requirements, such as a bearer token, API key, or OAuth 2.0 token flow

• any required headers

Prospectus Plus can support different authentication approaches depending on your system. Some institutions provide a webhook URL with a static authentication token. Others require Prospectus Plus to request an OAuth 2.0 token before sending the payload.

Example payload

The example below shows the type of data Prospectus Plus can send. This is an anonymised sample using fictional institution, prospect and course data.

This example is for demonstration purposes only. Prospectus Plus instances can be configured differently, and personalisation questions, field names, selected options and registration form fields may vary between institutions. If you need an exact example payload for your own Prospectus Plus instance, please request this through technical support.

{
 "wordpress": {
 "id": 1234
 },
 "prospectus": {
 "key": "abc123xy",
 "url": "https://prospectus.examplecollege.ac.uk/prospectus/abc123xy",
 "personalisation": {
 "campuses": "city-campus,riverside-campus",
 "qualification": "a-level",
 "subject-areas": "business,politics,law"
 },
 "overview": {
 "your-courses": "Business, Government and Politics, Law",
 "your-college": "Example City College, Example Riverside College",
 "supporting-you": "Financial Support, Learning Support, Personal Tutors, Student Welfare, Maths and English, Travel Support",
 "whats-on-campus": "Cafes and Dining, Library, Study Spaces, Sustainability",
 "your-future": "University Progression, Apprenticeships, Careers Advice",
 "our-community": "Trips and Visits, Clubs and Societies, Student Union, Equality and Inclusion",
 "applications": "Qualifications Explained, How to Apply, Application FAQs, Your Application Journey",
 "next-steps": "Open Events, Contact Us, Follow Us"
 }
 },
 "author": {
 "first_name": "Alex",
 "last_name": "Smith",
 "email": "alex.smith@example.com",
 "year_of_entry": "September 2027"
 }
}

What each part of the payload means

prospectus

This contains the unique prospectus reference, URL, personalisation choices and content overview.

personalisation

This section contains the structured values selected by the user. These are usually the most useful fields for CRM segmentation and routing. These are for demonstrative purposes only as the questions can vary between licences, and are individual to each licence. If you require more visibility on the exact payload, please request a licence specific payload from our technical support team.

Example: For multi-campus institutions, the campuses value could be used to decide where the enquiry should be routed. For example, if a user selects both city-campus and riverside-campus, your middleware or CRM can create one record with multiple campus interests, or route the enquiry to more than one team if your process requires it.

overview

This section summarises the content served to the user in their personalised prospectus. It is designed to be easier for humans to read and can be useful for CRM notes, enquiry summaries, or marketing automation rules.

Example uses include:

• storing selected courses or content themes against the CRM record

• giving admissions or recruitment teams a quick view of what the user saw

• triggering follow-up campaigns based on selected content

• building richer segmentation, such as open event invitations by subject or campus

author

This contains the user details submitted through the registration form.

The fields available in this section may vary depending on your registration form configuration. For example, some institutions may also collect communication preferences, phone number, postcode, country, level of study, or enquiry type.

Because each Prospectus Plus instance may use different registration fields and personalisation questions, CRM teams should not build against this demo payload alone. Please request an instance-specific sample payload through technical support before starting development.

Using the payload in your CRM

Most CRM integrations use the payload to create or update an enquiry record.

A typical mapping might look like this:

Your CRM team or integration partner should decide how these fields map into your own data model. Prospectus Plus can provide the outgoing payload, but your receiving system is responsible for processing it and applying your internal business rules.

Do we need Zapier?

No. Zapier is optional.

Zapier can be a good fit for teams that want a low-code way to connect Prospectus Plus to other systems quickly. However, some institutions prefer not to use Zapier because of cost, data governance, data residency, IT policy, or the need for more control over the integration.

Common alternatives include:

• a direct webhook endpoint provided by your CRM

• a middleware endpoint built by your internal developers

• Microsoft Power Automate

• self-hosted n8n

• an integration layer managed by your CRM provider or digital agency

The key requirement is that the receiving system must be able to accept and process a POST request containing the Prospectus Plus payload.

GDPR and consent considerations

Before enabling a CRM integration, you should review your data protection wording and internal lawful basis for processing.

In most cases, your institution remains the data controller for the data collected and processed through the recruitment journey. Prospectus Plus and any connected systems process the data according to the agreed configuration and contractual arrangements.

You should consider whether you need to update:

• the privacy notice linked from your prospectus registration form

• any short-form data capture statement shown at the point of submission

• wording explaining that the user may be contacted about relevant courses, open events, applications, admissions or enrolment

• wording explaining which systems or third-party processors may handle their data

• communication preference fields, where marketing consent is required

• your internal retention and CRM matching rules

For Walled Garden Mode, you can include a data capture statement, link to your privacy notice, and, where appropriate, add required or optional fields such as intended year of entry or communication preferences.

This article is not legal advice. Your data protection officer or legal team should approve your wording before the integration goes live.

Testing the integration

Before enabling a webhook in production, we recommend the following test process:

1. Provide Prospectus Plus with a test or staging webhook endpoint.

2. Confirm the expected authentication method and headers.

3. Send a test payload.

4. Confirm that your endpoint receives the payload successfully.

5. Validate that required CRM fields are populated correctly.

Test duplicate handling, especially where email address is used as the unique identifier.

1. Confirm error handling if your endpoint is unavailable.

2. Confirm that your privacy notice and form wording are approved.

3. Move to the production endpoint once testing is complete.

Error handling

Your receiving endpoint should return a clear HTTP response when Prospectus Plus posts the payload.

As a general principle:

• 2xx responses indicate that the request was received successfully

• 4xx responses usually indicate an issue with the request, authentication, or payload handling

• 5xx responses usually indicate an issue with the receiving system

Your technical team should ensure the endpoint logs incoming requests and errors. This makes it easier to diagnose any issues during testing and after launch.

Recommended checklist for your technical team

Before implementation, confirm:

• You have requested an exact example payload for your Prospectus Plus instance through technical support

• Which CRM records should be created or updated

• Which field should be used for matching existing records, usually email address

• Whether multiple campus or subject interests should create one record, multiple records, or multiple interest fields

• Whether year of entry is required

• Whether communication preferences are required

• Whether the CRM needs raw slugs, human-readable labels, or both

• Whether the personalised prospectus URL should be stored in the CRM

• Whether open event invitations or email journeys should be triggered automatically

• How failures will be logged and monitored

• Who owns support for the receiving endpoint

Support

If your team or integration partner has technical questions, please raise a support request through the Prospectus Plus support desk and include:

• the webhook endpoint URL, if available

• authentication requirements

• a description of the CRM or middleware being used

• the fields you want to receive

• whether you need an exact sample payload from your own Prospectus Plus instance

• any specific formatting requirements

• examples of any errors or failed requests

Our team can then confirm what Prospectus Plus can send and help you test the outbound webhook configuration.