The Users API is the account-management layer. It lets you create, read, update, and delete user records under your Qflow tenant programmatically — the foundation of white-label and multi-tenant integrations where resellers spin up branded sub-accounts on demand without anyone logging into the Qflow ControlPanel.

URL pattern

All endpoints on this page live under:

https://api.qflowhub.io/users/v1/api/<endpoint>

Users is segment-versioned with the /api/ prefix (same shape as Events / Guests / Team — only Comms is path-stripped). Every request needs both an OAuth bearer token AND an Ocp-Apim-Subscription-Key header — see Authentication.

What it does

When to use this surface

• Platform integrators running events on behalf of their own customers. The Users API mints a Qflow account for each new customer without manual provisioning.
• Self-serve sign-up flows where end users register through your branded UI and you create Qflow accounts in the background.
• Bulk migration from another system — script the imports before pointing live traffic at Qflow.

Quick start — create your first user

curl -X POST 'https://api.qflowhub.io/users/v1/api/user' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "userName":   "newcustomer",
    "email":      "new.customer@example.com",
    "password":   "Initial-pass-9182",
    "firstName":  "New",
    "lastName":   "Customer",
    "timeZoneId": "Europe/London"
  }'

Response includes the server-assigned id (a fresh GUID) — capture it from the response for any follow-up calls.

Read in this order

1. Users — the single-record shape + CRUD walkthrough.
2. Credentials — when you need to flip a password or username out-of-band.
3. Lookup & metadata — discovery + the translations endpoint for branded UI.

For full request/response schemas + try-it, see the auto-generated API Reference.

The Users API is the white-label partner surface — for ticketing companies, event-management platforms, and conference organisers who offer Qflow under their own brand. (Reselling is one model, but not required.) It lets you provision Qflow user accounts under your enterprise, control their credentials, and deliver them to your customers under your branding.

It's the partner-facing piece of Qflow's white-label offering. Once you've created an account through this API, that user logs in to your branded Qflow surface (web, iOS, and Android), manages their own events, attendees, team members, and invitations using the Check-in and Comms APIs — all from within the experience you control.

The white-label package

White-label is more than just user provisioning — it's a turnkey resale of Qflow's full check-in stack under your brand:

• Branded web dashboard — at your_brand.qflowhub.io with your logo, colours, login background, and translations. Users sign in here directly, or seamlessly via iFrame SSO from inside your own portal.
• Branded iOS + Android apps — custom-built mobile check-in apps with your logo, name, colours, and app-store listing. Your users download "Your Brand Check-in" from the App Store / Play Store, not "Qflow". See Native apps for the delivery + publishing flow.
• iFrame SSO — drop a "Check-in" tab into your existing portal. Users authenticate via your platform; Qflow's dashboard loads inline with single sign-on. The fastest path to a fully embedded experience.
• Direct API integration — alternatively, build your own check-in UI on top of the Check-in and Comms APIs. Maximum control. Your users never see a Qflow surface at all — even the dashboard is yours.
• Programmatic user provisioning — this API. Onboard users from your signup flow without ever sending them to a Qflow signup page.

To your customer, the entire flow — signup, dashboard, mobile scanner — feels like part of your product. They never need to know Qflow is the engine.

When you'd use it

• Reselling Qflow as part of your platform — you handle signup in your own UI, then call the Users API to create the matching Qflow user account behind the scenes.
• Programmatic customer onboarding — automated provisioning from your CRM / signup form / billing system.
• Bulk credential operations — periodic password rotations, reset-on-leave flows for departed users.
• Lookups + reporting — find users by email, count active users in your enterprise, etc.

If you're using Qflow directly (not white-labelling for resale), you don't need this API — sign up at qflowhub.io and use the Check-in and Comms APIs against your single account.

Concepts

• Enterprise — your branded slice of Qflow. Has a name, an enterprise pin (short alphanumeric prefix), branded subdomain (e.g. your_brand.qflowhub.io), custom logo, custom colours, and your translations. All users you provision belong to this enterprise.
• Enterprise pin — the short string that prefixes every user's username. If your pin is acme, your users sign in as acme/joe.bloggs@example.com.
• User — an account inside your enterprise. Each user has their own events, attendees, team members, and comms templates — managed by them via the Check-in and Comms APIs. Users inherit your enterprise's branding and translations.
• Calling client — the OAuth client you authenticate with carries your enterprise context. Created users automatically inherit your enterprise membership; you don't pass the enterprise id explicitly on every call.
• Trust — created users default to untrusted; sending operations require KYC verification per-user. See Authentication.

How it fits with the other APIs

1. You provision (Users API) —

   From your platform's signup, admin, or billing flows, call POST /api/user to create a Qflow user account under your enterprise. The user inherits your branding, translations, and subdomain.

2. Your customer signs in (your branded surface) —

   They land in the web dashboard at your_brand.qflowhub.io, your branded iOS / Android apps, or via an iFrame SSO embed inside your existing portal. To them, it's part of your product.

3. Your customer runs events (Check-in + Comms APIs) —

   Behind the scenes, the dashboard / apps drive the Check-in and Comms APIs to manage events, attendees, team members, tickets, and webhooks — all scoped to their own account.

You don't typically call Check-in / Comms from your backend — your end users do, from inside your branded Qflow experience. Your direct integration is just with the Users API + iFrame SSO.

URL pattern

All Enterprise endpoints live under:

https://api.qflowhub.io/users/v1/api/<endpoint>

Every request requires both an OAuth bearer token AND an Ocp-Apim-Subscription-Key header — see Authentication.

Endpoints

For request / response schemas + interactive try-it, see the auto-generated API Reference.

iFrame SSO (the second half of the white-label story)

Provisioning the user is half the white-label experience — the other half is signing them in to your branded Qflow surface without a password prompt every time. Use the AES-encrypted SSO token flow to embed the Qflow dashboard inside your own product:

→ iFrame SSO

Branding + translations

Branding (logo, primary colour, favicon, login background, etc.) and translation strings are configured at the enterprise level, not per-user — so all users in your enterprise see the same surface. Configure these via the Qflow admin dashboard at your_brand.qflowhub.io/manage. The Users API doesn't expose programmatic branding endpoints today; if you need that, contact support@qflowhub.io.

Your white-label offering includes branded native apps. Each app is built fresh against a profile tied to your account — name, icon, splash, colour scheme, feature toggles, content. We configure that with you up-front; no in-app branding work falls to your team.

We hand off the binaries. You set up the developer accounts, re-sign the iOS build, and own the store listings.

For pricing, email support@qflowhub.io. One annual rebuild is included after initial onboarding — content, branding, or feature-toggle updates at no extra charge.

What you get

After our branding + features call, we deliver:

The iOS build is signed with our distribution certificate so it installs and runs end-to-end — but before you submit, you re-sign it with yours (see below).

What's on you

1. Enroll an Apple Developer + Google Play Console account in your name
2. Re-sign the .ipa with your distribution certificate
3. Upload to App Store Connect and the Play Console
4. Submit for review and manage the listing

We can advise and rebuild on request; the accounts and submissions are yours.

Apple — App Store

Enrol in the Apple Developer Program

You'll need an individual or organisation enrollment (around $99/year — confirm current pricing at Apple's enrollment page). Organisations need a D-U-N-S number; budget a few days if you don't already have one.

Re-sign your .ipa

The .ipa we deliver is signed with our distribution certificate. Before uploading to App Store Connect you re-sign it with yours so the binary is associated with your team.

You'll need two things on your side first, both created in Certificates, Identifiers & Profiles:

• A distribution certificate under your team
• A provisioning profile for that certificate, tied to the bundle ID we ship the app with (we send this to you on delivery)

Easiest path is fastlane resign:

fastlane resign your_app.ipa \
  signing_identity:"iPhone Distribution: Your Company (TEAM_ID)" \
  provisioning_profile:./your_app.mobileprovision

It re-signs in place and emits a fresh .ipa ready to upload.

Upload to App Store Connect

Use Apple's Transporter app (free on the Mac App Store):

1. Sign in with your Apple ID
2. Drag the re-signed .ipa into the window
3. Submit; the upload takes a few minutes to process

Once it's processed, head to App Store Connect to fill in the listing (name, screenshots, description, age rating) and submit for review.

Google — Play Store

Enrol in the Play Console

One-time $25 — sign up at play.google.com/console. Activation usually takes 24–48 hours.

Upload the .aab

We recommend Play App Signing — Google manages the production signing key and you upload your .aab directly. This is the default for new apps.

1. Create the app in the Play Console
2. Set up the internal testing track and upload your .aab there first
3. Fill in the store listing (icon, screenshots, description, content rating)
4. Promote to production when you're ready to roll out

External: Play App Signing docs · Testing tracks

The .apk we ship alongside the .aab is for sideloaded testing only — install it on a tester's device outside the Play Store. Don't upload the .apk to production; use the .aab.

Renewals + things that age out

Set calendar reminders for the Apple ones. An expired distribution certificate will eventually take your iOS app down.

When you need a new version

Two paths:

• Platform updates from us — security fixes, SDK bumps, new platform features. You'll get a fresh .ipa + .aab from us at no extra charge whenever we ship one.
• Updates you request — content, branding refresh, feature-toggle changes. One rebuild per year is included; additional rebuilds are quoted separately. Email support@qflowhub.io with what you want changed.

In both cases, re-sign the .ipa and upload it + the new .aab as a new version in App Store Connect / the Play Console. Apple review is usually 24–48 hours; Play is often same-day for updates after the first release.

Help

Email support@qflowhub.io. We handle branding changes, version releases, and app-side config; you handle the developer accounts and store submissions.

If your enterprise account is set up with Qflow's white-label option, you can embed the Qflow dashboard inside an iframe in your own portal and sign your users into it without a password prompt. They see Qflow events, guest lists and statistics — fully branded as you, fully inside your product.

How it works

1. You generate a short-lived SSO token server-side, encrypted with a shared secret only you and Qflow know.
2. You embed an iframe pointing at https://<your-enterprise>.qflowhub.io/sso?successUrl=...&token=<encrypted>.
3. Qflow decrypts the token, signs the named user in, and redirects to successUrl (e.g. the events list, or a specific event).

Prerequisites

You'll need three things, all provided by Qflow when your enterprise white-label is set up:

You'll also need the user GUID of the user you want to sign in. Each user in your enterprise has a unique id — see the Users API for creating and listing users.

The encryption recipe

The token is <userId>@<enterprisePin> encrypted with AES-256-CBC using your enterprise key, then Base64-encoded and URL-encoded.

plaintext  = "<userGuid>@<enterprisePin>"
key        = your enterprise KEY (32-byte string)
iv         = "qflow_sec_vector"     (fixed 16-byte IV — same for everyone)
ciphertext = AES-256-CBC(key, iv).encrypt(plaintext)
encoded    = url_encode( base64_encode( ciphertext ) )

The result goes in the token query parameter on the SSO URL.

Examples

<?php
$userId         = '050f4a44-d7d1-452e-837a-0d2759dcfa69';
$enterprisePin  = '123';
$enterpriseKey  = 'hfdg8AZgkKCQcNCgwOBAYIBa';

$plaintext = $userId . '@' . $enterprisePin;
$iv        = 'qflow_sec_vector';

$encrypted = openssl_encrypt(
    $plaintext,
    'AES-256-CBC',
    $enterpriseKey,
    OPENSSL_RAW_DATA,
    $iv
);

$token = urlencode(base64_encode($encrypted));

$ssoUrl = 'https://your_enterprise.qflowhub.io/sso?successUrl=/events&token=' . $token;
echo '<iframe src="' . $ssoUrl . '" width="100%" height="900"></iframe>';
?>

using System;
using System.Security.Cryptography;
using System.Text;
using System.Web;

string userId        = "050f4a44-d7d1-452e-837a-0d2759dcfa69";
string enterprisePin = "123";
string enterpriseKey = "hfdg8AZgkKCQcNCgwOBAYIBa";

string plaintext = $"{userId}@{enterprisePin}";
byte[] iv = Encoding.UTF8.GetBytes("qflow_sec_vector");

using var aes = Aes.Create();
aes.Key = Encoding.UTF8.GetBytes(enterpriseKey);
aes.IV  = iv;
aes.Mode = CipherMode.CBC;
aes.Padding = PaddingMode.PKCS7;

using var encryptor = aes.CreateEncryptor();
byte[] encrypted = encryptor.TransformFinalBlock(
    Encoding.UTF8.GetBytes(plaintext), 0, plaintext.Length);

string token = HttpUtility.UrlEncode(Convert.ToBase64String(encrypted));

string ssoUrl = $"https://your_enterprise.qflowhub.io/sso?successUrl=/events&token={token}";

const crypto = require('crypto');

const userId        = '050f4a44-d7d1-452e-837a-0d2759dcfa69';
const enterprisePin = '123';
const enterpriseKey = 'hfdg8AZgkKCQcNCgwOBAYIBa';

const plaintext = `${userId}@${enterprisePin}`;
const iv = Buffer.from('qflow_sec_vector', 'utf8');
const key = Buffer.from(enterpriseKey, 'utf8');

const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);
const encrypted = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);

const token = encodeURIComponent(encrypted.toString('base64'));

const ssoUrl = `https://your_enterprise.qflowhub.io/sso?successUrl=/events&token=${token}`;

Embedding

Place the resulting URL in an iframe src:

<iframe
  src="https://your_enterprise.qflowhub.io/sso?successUrl=/events&token=<encrypted_token>"
  width="100%"
  height="900"
  frameborder="0">
</iframe>

The iframe parent (your portal) needs to be on a domain we've allow-listed as a referrer. Send us the domain when you're set up.

successUrl — where to land

successUrl is the path inside the Qflow dashboard the user is redirected to after sign-in. Common targets:

Keep successUrl to a path; don't include the host. The browser combines it with the enterprise host automatically.

Security notes

• Always generate the token server-side. Never compute the encryption in the browser — the key would be exposed.
• Tokens are short-lived per the iframe load. Generate a fresh token each time the iframe is rendered; don't reuse stale ones.
• Validate the userId belongs to your enterprise before generating the token. Don't blindly accept any GUID from your own UI without a server-side check, or a hostile client could probe other users' accounts.
• Revoke users in the Users API rather than relying on stopping token generation — a deactivated user signed in via SSO is still effectively signed in until they log out or the session expires.

Getting set up

White-label setup (enterprise prefix domain, branding, allow-listed parent domain, enterprise key issuance) is done by Qflow support. Email support@qflowhub.io with your enterprise PIN and the parent domain you'll embed from to get started.

The shape of a user

Every user record has a server-assigned id, a userName, an email, and a timeZoneId. Optional fields cover identity (firstName / lastName / companyName), the password, and a free-form customData JSON dictionary you can use to attach your own caller-side metadata.

id is server-assigned on create — any id you send in the body is ignored and a fresh GUID is allocated. Capture the returned value for follow-up calls.

Creating a user

POST /api/user. Required: userName, email, password, timeZoneId.

curl -X POST 'https://api.qflowhub.io/users/v1/api/user' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "userName":    "newcustomer",
    "email":       "new.customer@example.com",
    "password":    "Initial-pass-9182",
    "firstName":   "New",
    "lastName":    "Customer",
    "companyName": "Acme Ltd",
    "timeZoneId":  "Europe/London",
    "customData":  "{\"crmId\":\"CRM-42\",\"plan\":\"starter\"}"
  }'

Field-level notes:

• userName — pass the bare login identifier on create / change endpoints. Server-side it's stored as <enterprise>/<userName> (enterprise-namespaced). Read endpoints return the prefixed form, so be ready to strip the <enterprise>/ prefix client-side if you only want the bare username for display.
• email — lowercased and trimmed server-side. Uniqueness is enforced via ASP.NET Identity's standard user-store check.
• timeZoneId — must be a valid TZDB id (Europe/London, America/New_York, etc.). Aliases (BST, EST) are rejected.
• customData — free-form JSON dictionary. Most integrators stringify their own schema here. No server-side schema enforcement.
• No idempotency key — the server-assigned id is regenerated even if you send one, so POST can't be made idempotent on your own id. But userName (and email) are unique, so an identical retry is rejected with 400 (duplicate username) rather than silently creating a second account. Use byemail to check existence if you're unsure.

Reading a user

GET /api/user/{userId} returns the full record:

curl 'https://api.qflowhub.io/users/v1/api/user/<userId>' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>'

For "I have the email, not the id", use Lookup & metadata's byemail endpoint instead.

Updating a user

PUT /api/user accepts profile-field updates. Send the full body with id plus any fields you want to change. Credentials (password, userName) don't change via this endpoint — they have their own Credentials endpoints, separately, so they can require old-credential verification.

curl -X PUT 'https://api.qflowhub.io/users/v1/api/user' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id":          "<userId>",
    "firstName":   "Updated",
    "lastName":    "Name",
    "companyName": "Acme Ltd",
    "timeZoneId":  "America/New_York"
  }'

customData is partial-merged on PUT — keys you send overlay; existing keys you omit are preserved. To wipe a key, you'll need to set it to null or empty explicitly; there's no whole-dictionary clear on this endpoint.

Deleting a user

DELETE /api/user removes the user account. Deletion is permanent — there's no recovery via the API. Body carries just the id.

curl -X DELETE 'https://api.qflowhub.io/users/v1/api/user' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{ "id": "<userId>" }'

Once gone, the account and everything that referenced it (their events, attendees, team-member assignments owned by them) is unrecoverable. Be sure before calling.

Where to next

• Credentials — change password / username out-of-band.
• Lookup & metadata — discovery + the translations endpoint.

Why these are separate

Credentials live on dedicated endpoints (not on PUT /api/user) because they have stricter validation: password changes require the old password, username changes need uniqueness checks within your enterprise, and either one can optionally invalidate every other active session.

Putting these on their own surface means the bulk profile update endpoint stays simple and forgiving — you don't accidentally lock out a user by sending an empty password field on a routine profile edit.

Change password

PUT /api/user/changepassword swaps a user's password. The caller must supply both the current password and the new one — there's no admin-bypass shape on this endpoint. Use this for support workflows where the user is on the phone and can tell you their current password.

curl -X PUT 'https://api.qflowhub.io/users/v1/api/user/changepassword' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id":                 "<userId>",
    "oldPassword":        "Initial-pass-9182",
    "newPassword":        "Stronger-pass-2026",
    "signOutAllSessions": true
  }'

Field notes:

• oldPassword — must match what's currently stored. Mismatch returns 400.
• newPassword — must satisfy the underlying ASP.NET Identity password policy (minimum length, mix of character classes — exact rules can vary by tenant config).
• signOutAllSessions — when true, the user's security stamp is rotated, which invalidates every active session associated with the account (useful for "this account was compromised" flows). Defaults to false. Note: the rotation doesn't carve out the requesting session — if your caller is acting on behalf of the user (rather than as an admin against someone else's id), assume their own session will also need re-authentication.

If you don't have the old password (forgot-password flow, bulk migrate from another system), the right tool isn't this endpoint — the password-reset email flow handles that case end-to-end and is the supported recovery path.

Change username

PUT /api/user/changeusername renames a user's login identifier. Both old and new values are the bare form (no enterprise prefix); the server handles namespacing.

curl -X PUT 'https://api.qflowhub.io/users/v1/api/user/changeusername' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id":          "<userId>",
    "oldUserName": "newcustomer",
    "newUserName": "acmecustomer"
  }'

Field notes:

• oldUserName — bare value, no <enterprise>/ prefix. Must match what's stored (under the prefix).
• newUserName — bare value too. Uniqueness is checked globally across all enterprises, not just within yours — if another enterprise has already taken acmecustomer, your rename fails. Pick prefixes / suffixes that reduce collision risk for high-volume cases.
• The user's existing sessions stay live — username changes don't sign anyone out. Their old username stops working immediately; the new one starts working immediately.

Where to next

• Users — the profile-field update path (everything except credentials).
• Lookup & metadata — find the user by email before changing their credentials.

Three read shapes + one metadata read

This article covers four endpoints — three for finding users, one for the translation locale set:

• List — every user in your enterprise.
• Count — total user count, a lighter alternative to the list when all you need is a number.
• Find by email — single lookup when you don't have the id.
• Translations — locale catalogue available to your tenant.

Listing users

GET /api/users returns every user in your enterprise.

curl 'https://api.qflowhub.io/users/v1/api/users' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>'

OData paging works here (?$top=, ?$skip=, ?$filter=, ?$orderby=). Useful when your enterprise has tens of thousands of users and you want pages of 50–100 rather than one giant payload.

Total user count

GET /api/users/total returns just the integer count — no record bodies, no paging. Inexpensive to poll for dashboards.

curl 'https://api.qflowhub.io/users/v1/api/users/total' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>'

Use this over GET /api/users when all you need is the headcount — much faster on large enterprises.

Find by email

GET /api/users/email does an exact-match lookup on the email field. Returns the full user record if found, 404 otherwise.

curl 'https://api.qflowhub.io/users/v1/api/users/email?email=new.customer@example.com' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>'

Useful for "do we already have this person?" checks before creating a user — POST /api/user is not idempotent, so this pre-check is the only way to dedupe retries by email.

Emails are lowercased + trimmed when stored, and the lookup is case-insensitive (per the database collation) — so any-case input matches the stored address.

Translation locales

GET /api/user/translations returns the catalogue of translation locales available to your enterprise — used to render Qflow-branded UI in the user's language without hard-coding the locale list client-side.

curl 'https://api.qflowhub.io/users/v1/api/user/translations' \
  -H 'Authorization: Bearer <access_token>' \
  -H 'Ocp-Apim-Subscription-Key: <subscription_key>'

Each entry has an id and a name (the locale identifier like en-GB, de-DE). Use to populate language pickers in your UI.

Where to next

• Users — the CRUD layer.
• Credentials — change password / username on a user you've just looked up.