Registration URL API

Overview

Rather than directing visitors through the standard registration journey, partners may collect registration information themselves and pass it directly into HubPeople using URL query string parameters.

The registration system will automatically:

• Populate registration fields
• Skip completed onboarding steps
• Validate all supplied data
• Apply supplied member interests where they match
• Create the member account
• Store campaign tracking information
• Detect member location
• Redirect members to the desired post-registration experience

This approach allows partners to maximise conversion rates while retaining the security and validation provided by the HubPeople platform.

Returning integrators: see the Changelog for what has changed since you last implemented.

Registration Flow

The onboarding process is progressive. Information supplied via URL parameters is injected into the registration flow before onboarding begins. Any completed steps are automatically skipped.

Typical onboarding stages include:

1. Gender
2. Looking For
3. Date of Birth
4. Email Address
5. Password
6. Display Name
7. Location
8. Profile Details
9. Terms & Conditions
10. Registration Complete

If a required value has not been supplied, the user will simply be prompted during onboarding. Where a valid value has been supplied, that stage is skipped for the user.

Login URLs

HubPeople Hosted Sites

Affinity

https://auth-affinity.com/s/login/{siteGuid}

Excite

https://auth-excite.com/s/login/{siteGuid}

Example

https://auth-affinity.com/s/login/00000000-0000-0000-0000-000000000000

Custom Domain

Where your Members Area domain points to HubPeople infrastructure:

https://members.example.com/s/login

Registration URLs

HubPeople Hosted Sites

Affinity

https://auth-affinity.com/s/register/{siteGuid}

Excite

https://auth-excite.com/s/register/{siteGuid}

Example

https://auth-affinity.com/s/register/00000000-0000-0000-0000-000000000000

Custom Domain

https://members.example.com/s/register

Example

https://app.example.com/s/register

Query Parameters

All registration data is supplied as URL query string parameters.

Example

https://app.example.com/s/register?mt=1&lf=2

All parameter values must be URL encoded.

Parameter Reference

Identity

Gender (mt)

Passing mt skips the "I Am" onboarding step.

Looking For (lf)

Passing lf skips the Looking For step. Supports multiple selections by adding values together.

Examples

Date of Birth

Preferred parameter names

Example

dd=17
dm=11
dy=1983

Legacy aliases remain supported

dobday1
dobmonth1
dobyear1

Couple registrations additionally support

dobday2
dobmonth2
dobyear2

Members must be at least 18 years old.

Profile

Ethnicity Values

The same values apply on both Affinity and Excite sites.

Build Values

The same values apply on both Affinity and Excite sites.

Age Range (agemin / agemax)

Sets the age range of members the new member wants to see, the preference otherwise collected by the age-range slider during onboarding. Passing either parameter fills the range and skips the Age Range step outright; it is not shown pre-filled for confirmation.

Example

https://app.example.com/s/register?mt=1&lf=2&agemin=40&agemax=50

Rules and limits

• Send whole numbers. Both values are read as integers, so decimals, ranges and text are not valid.
• The two values must be different. A range whose minimum equals its maximum is not a valid age range.
• Send agemin lower than agemax. The values are stored exactly as supplied and are not re-ordered.
• Keep both values inside the range your site offers. The platform default is 18 to 99, where 99 means 99 and over, and a site's own configuration may narrow that further. The slider on your own signup steps shows the range in use.
• Because the step is skipped, these values are taken as given: they are not corrected, not clamped to your site's range, and never put back to the member for confirmation. A wrong or out-of-range value carries straight into the account, so validate the numbers before you build the link.

If you do not send them

• Send neither, and the member sets the range on the Age Range step as before.
• Send a date of birth but no age range, and the step is pre-filled with a default range around the member's own age. It is still shown, so the member can adjust it.

Interests

Partners may pass a list of member interests in the query string. Each value is matched against the interests configured on that site's signup steps, and every value that matches is applied to the member.

Example

https://app.example.com/s/register?interests=Friendships%3BCooking&mt=1&lf=2

How values are matched

• Values are matched on the interest label, the wording a member sees on the interest step, not on an id.
• Matching is case insensitive, and both the value you send and the interest label are trimmed of surrounding spaces. Cooking, cooking and Cooking with padding all match the same interest.
• Interests whose labels contain spaces are supported: interests=Friendships;Cooking;Serious Relationship.
• Interests whose labels contain a comma are supported: interests=Cooking;Wining, dining and dancing sends two interests, the second one keeping its comma.
• Any value that does not match is ignored. Unmatched values never block the registration or produce an error.
• Matching runs against that site's own signup configuration, not a platform wide list. An interest that exists elsewhere on the platform but is not on your site's signup steps will not be applied.

The registration flow reads the value whether or not it is encoded, but encoding is the safer habit here, and more so than it was with a comma: an unencoded space is not valid in a URL at all, and a bare semicolon is treated as a parameter separator by some servers, analytics tools and ad platforms that may handle the link before it reaches us. Encode the separator as %3B.

Encoded, the same example reads

interests=Friendships%3BCooking%3BSerious%20Relationship

The semicolon is the separator, so an interest whose label itself contains a semicolon cannot be passed.

Finding the interest labels for your site

Take the labels from your own site's signup steps, worded exactly as they appear there: that is the list the registration flow matches against, and it changes whenever you change your signup configuration.

For background on what interests exist across the platform, and the niches they feed, see the public niche directories: Affinity niches and Excite niches. Only the interests on your own signup steps will match, so treat those pages as reference, not as a parameter list.

Marketing Tracking

Standard UTM tracking is fully supported.

All four utm_ parameters are stored and used for tracking and reporting purposes, so always send them where available. Other common tracking parameters, such as GCLID and similar click ids, are logged by our servers but not actively used.

Registration Options

Localisation (culture)

Sets the language used throughout the onboarding flow.

Supported values

Example

culture=fr

Location

HubPeople supports several methods of determining a member's location.

When a valid location is supplied in the query string (zipCode, lat/long or iplocation), the Location onboarding step is skipped outright; it is not shown pre-filled for confirmation.

ZIP Code

zipCode=90210

Currently supported for United States ZIP Codes only.

Latitude / Longitude

Partners may supply decimal latitude and longitude coordinates.

Example

lat=32.782502
long=-96.820704

Latitude and longitude provide the most accurate location information and are recommended where available.

IP Location

Partners may alternatively pass the user's IP address.

Example

iplocation=76.172.73.71

Location Resolution Priority

When multiple location values are supplied, HubPeople resolves location using the following order:

1. ZIP Code (US sites only)
2. Latitude / Longitude
3. IP Location
4. Browser detected IP

This ensures the most accurate location information is used.

Post Registration Redirect

Allows partners to control the first page shown after successful registration.

Example

redirect=meetme

Base64 Support

To simplify integration and avoid issues with reserved URL characters, email addresses and passwords may be Base64 encoded before URL encoding.

Email

Base64 encode the email address and then URL encode the resulting value.

Example

em=cGFydG5lci5kZW1vQGV4YW1wbGUuY29t

Decodes to

partner.demo@example.com

Password

Passwords may also be supplied as Base64 encoded values.

Example

p=VGVzdGluZzEyMw%3D%3D

Decodes to

Testing123

Security Recommendation

Passwords supplied using the p parameter are supported for backwards compatibility and integration simplicity. However, transmitting passwords via URL query strings is not recommended, as URLs may be stored in browser history, web server logs, reverse proxies and analytics systems.

Where possible, partners should allow the HubPeople registration flow to securely collect the user's password instead of supplying it via the URL.

Complete Example

https://app.matelocal.com/s/register
?firstname=Test%20User
&em=cGFydG5lci5kZW1vQGV4YW1wbGUuY29t
&p=VGVzdGluZzEyMw%3D%3D
&dd=17
&dm=11
&dy=1983
&mt=1
&lf=2
&agemin=40
&agemax=50
®=1
&tcs=agree
&lat=32.782502
&long=-96.820704
&interests=Friendships%3BCooking
&utm_source=google
&utm_campaign=summer
&redirect=meetme

Validation Rules

Error Handling

The registration platform is designed to fail gracefully.

• Unknown parameters are ignored.
• Invalid parameter values are ignored.
• Age range is the exception: supplying agemin or agemax removes the Age Range step, so a non-numeric or out-of-range value is not corrected and is never re-requested during onboarding.
• Interest values that do not match an interest on the site's signup steps are ignored, and the rest of the list is still applied.
• Missing mandatory information is requested during onboarding.
• Invalid location values fall back to the next available location source.
• Registration cannot complete until all mandatory fields have been successfully validated.

Data Protection

If you collect registration information on your own pages before passing it to HubPeople, you are the data controller for that data. Ensure you have an appropriate legal basis and consent for collecting it, transmit it only over HTTPS, and do not log or retain registration URLs, as they contain personal data.

Note that some fields carry extra obligations: ethnicity, and preference fields such as gender, looking for and interests, may constitute special category data under GDPR and similar laws, requiring explicit consent and stricter handling.

This is guidance, not legal advice; partners are responsible for their own compliance.

Best Practices

• Always URL encode all parameter values.
• Prefer Base64 encoding for email addresses.
• Use latitude and longitude where available, as these provide the most accurate location.
• Include UTM parameters for campaign attribution.
• Send agemin and agemax together, and check them against the range your own signup steps offer: supplying them skips the age-range step, so nothing downstream corrects a bad value.
• Separate interests with a semicolon, encoded as %3B.
• Keep any interests you pass in step with your signup configuration: if an interest is reworded or removed from your signup steps, links carrying the old label stop applying it silently.
• Only send information that has already been collected from the user.
• Do not rely on query string passwords for new integrations; allow HubPeople to collect passwords during onboarding wherever possible.
• Test integrations on both desktop and mobile devices.
• Avoid logging full registration URLs if they contain personally identifiable information.

Changelog