Identity Link API Changelog

This changelog documents all released versions of the VU Identity Link API. The most recent entries appear first. Review this page before upgrading your integration to identify behavior changes that may affect your flow.

​

v2.4.1 (current)

​

VU Cloud Services is available

• Self-service api-keys for every Premium and Pro account: the Cloud Services section of the portal is now enabled. ID Analysis, Face Analysis and Facial Antispoofing integrate with api-keys that you create, rotate, pause and revoke from the portal, with no ticket. Connection Fingerprint is contracted through sales and does not use api-keys. See the documentation.
• Trial period: up to 5 api-keys per service, each with 10,000 trial calls. Usage is not billed during the launch period.
• A refused api-key tells you why: when the service is not enabled for the account, the portal explains the reason instead of showing a generic error.

​

Behavior changes

• GET /verifications/{size}/{page} enforces the maximum of 100 per page: a size above 100 is served as 100, and a missing, zero or negative size is also served as 100 (a negative size used to answer 500). If you requested more than 100 per page, page through the results.

​

New features

• Back to the requested screen after signing in: a link to any portal screen takes you to that screen after you sign in.

​

Improvements

• Verification link with an expired portal session: when the person’s browser held an expired portal session, the verification link sent them to the sign-in page. Now the verification continues.
• Support contact email: it arrived with the account-confirmation subject. It now has the support subject.

​

v2.3.2

​

New features

• Share button when a link is created: it sits next to Copy, on the screen of the newly created link. On a phone it opens the system share sheet. On a desktop it opens a menu with Email, WhatsApp, Copy short link, and Show QR. The QR is generated in the browser, without sending the link to any external service.
• Documentation from the side menu: a new Documentation item, visible on every plan, with two entries: the guides at docs.vu-one.com and the API reference (Swagger).

​

Improvements

• Sharing the link from the QR hand-off on Android: sometimes the link was neither shared nor copied, and no message appeared. The link is now copied before the share sheet opens. If the sheet fails or is cancelled, a message confirms that the link was copied. If the copy also failed, the link is shown on screen so it can be copied by hand.

​

v2.3.1

​

Improvements

• Paying again after a card expires: adding a payment method failed when the account no longer had a card attached. POST /billing/paymentMethod now works without a previous card and, if the subscription has an unpaid invoice, charges it. If the issuer declines the payment, the account stays as it was and the portal shows the reason.
• Customer location map: it showed the OpenStreetMap “Access blocked” notice instead of the map. The map now loads.

​

v2.3.0

​

VU Cloud Services (coming soon)

These features are already in the platform and are enabled when VU Cloud Services becomes available to every account. The documentation is already published.

• VU Cloud Services section in the portal: a new section with the catalogue of available services —ID Analysis, Face Analysis, Facial Antispoofing, and Connection Fingerprint— each with its description, its price, and its integration documentation, in Spanish, English, and Portuguese.
• Self-service api-keys: create, rotate, pause, and revoke api-keys from the portal, with no ticket to open. The secret is shown once, when the key is created or when a rotation is confirmed. Connection Fingerprint is arranged with a sales representative and does not use api-keys.
• Usage per api-key: every api-key has its own usage screen, with what has been consumed, the trial-period limit, the remaining balance, and what it is worth. Usage is not billed during the launch period.
• Notice at 80% of the quota: when an api-key passes 80% of its quota, the account owner receives an email with the service, the usage, and the limit. There is no need to watch the usage screen to find out.
• Sales contact request from inside the product: available in the catalogue, on the usage screen, and when the trial period runs out. It is idempotent per company: once the request is sent, a further click returns the same one instead of creating another.

​

Behavior changes

• Downgrading or cancelling a plan warns before it is confirmed: the screen spells out which integrations stop being available and what happens to each api-key.

​

Improvements

• iOS and the location permission: someone who had already denied location was told the browser had blocked the request, and in flows where location is mandatory they were left with no way out. The message now explains the actual situation, and there is always a way back.
• The browser’s automatic translator: it garbled the text of the verification flow. The flow now declares its language correctly and the translator respects it.
• Business name in Settings: the company card showed an internal identifier under the label “Business Id”. The label now reads Business Name and shows the account name.
• Language selector on mobile: reachable again on sign-in, sign-up, email confirmation, and the dashboard header.
• Portal visual fixes: distorted typefaces, the side menu overlapping at intermediate widths, navigation on narrow screens, the contact-request message, and opening a portal URL without a session, which now leads to sign-in instead of an empty screen.

​

v2.2.1

​

Changes

• End-user Terms and Conditions and Privacy Policy updated to version 2.1.
• Legal documents in Portuguese: the Portuguese verification flow now serves the Terms and Conditions and the Privacy Policy in that language.

​

v2.2.0

​

New features

• Adaptive flow: new adaptiveFlow field on POST /links that re-verifies a returning customer with a selfie alone, skipping document capture. It is tri-state: omitted follows the company setting, true and false override it for that link. Requires externalUserId to have any effect.
• linkConfig.adaptiveFlow company setting: per-company switch, off by default, that governs links which do not override it explicitly. Available on GET and PATCH /users/me/company.
• Resolved branch on the link: GET /links/{id} now returns adaptiveFlow as the resolved branch (link.adaptiveFlow or the company setting), not the tri-state value.
• PATCH /verifications/identify: new public endpoint that lets an adaptive link created without an externalUserId receive the person’s email mid-flow and re-resolve the adaptive branch.
• GET /verifications/{id}/related: new authenticated endpoint listing every other verification for the same client (same company, same externalUserId), newest first, with a dataExpired flag for rows already anonymized by retention.
• method on status polling: GET /verifications/{id}/status?include=operationGuid now also returns method, either FACE (adaptive branch) or DOCUMENT (full flow), or null while unresolved.
• Gate rules on the link: GET /links/{id} exposes company.gateRules, a resolved read-only rule set deciding which device cohorts are gated, alongside defaultTemplateVersion, the version of the globally active template.
• locationPermission: new policy, always resolved server-side, with values never, optional, and required. It appears as company.locationPermission on GET /links/{id} and as verificationConfig.locationPermission on the company. FREE plans always resolve to never.
• onboardingBusinessId restored: GET /users/me/company again includes the business id from the onboarding integration, removed for pentest #30. Settings now has a documented need to show it for support and debugging.
• POST /vuone/contact-request: new endpoint to request contact from sales from within the account. Idempotent by company: a repeat click returns the existing request (200) instead of creating another (201). Company, plan, and quota are derived from the authenticated session, never from the body.

​

Behavior changes

• linkId required on status: GET /verifications/{id}/status is a public endpoint and now requires linkId as a mandatory query parameter. Omitting it, or passing one that does not match the verification, returns 403.
• PATCH /verifications returns 404: if the verification does not exist or has expired, the endpoint returns 404 instead of 200 with no changes.
• PATCH /verifications/error returns 404: same as above.
• PATCH /verifications returns 409: if the verification status does not allow the requested operation, it returns 409 instead of 200 with no changes.
• PATCH /verifications/error returns 409: same as above.
• Strict geolocation validation: tier, policy, ipDistanceKm, and serverIp are derived server-side and are no longer accepted as input; sending them returns 400. A capturedAt more than 24 hours from the server’s clock also returns 400.
• GET /billing/{idSubscription} returns 403: beyond a missing token, it now also answers 403 when the subscription does not belong to the caller’s company.

​

Migration recommendation

1. Add linkId to every GET /verifications/{id}/status call and drop the Authorization header: the endpoint is public.
2. Handle 404 and 409 on PATCH /verifications and PATCH /verifications/error. In versions prior to 2.2.0, these endpoints responded 200 even when no action was taken.
3. Review your geolocation client: move every field inside the geolocation object and stop sending server-derived fields.
4. If you plan to use adaptive flow, make sure you send externalUserId at link creation or call PATCH /verifications/identify mid-flow.

​

v2.1.0

​

New features

• Geolocation reporting: PATCH /verifications endpoint (public, no authentication) for the client to report device location during the verification flow.
• VerificationGeolocation object: full geolocation structure with ip, accuracyRadius (km), latitude/longitude (IP-derived, strings), country, city, subdivisions, accuracy (metres, device), source (gps/wifi/cell/ip/none), tier (precise/approximate/coarse/unknown, server-derived), permission (granted/denied/prompt), capturedAt, deviceLatitude/deviceLongitude (numbers, when a device fix is available).
• Authenticated geolocation fields: GET /verifications/{id} and similar expose policy, ipDistanceKm, and serverIp when queried with authentication. These fields never appear in public responses or webhooks.
• Lightweight polling with operationGuid: GET /verifications/{id}/status accepts ?include=operationGuid to return an object instead of a bare status string.
• Source inference: the source field is inferred among gps, wifi, and cell based on device accuracy and data.
• handoffMode on company: the company object includes handoffMode (never, suggest, require) to control device hand-off.

​

Improvements

• More descriptive error responses for invalid geolocation requests.
• Strict validation of device coordinates when source is gps, wifi, or cell.

​

v2.0.x and earlier

​

Baseline functionality

• Creation and management of verification links (POST /links, GET /links, GET /links/{id}).
• Verification flows FULL FLOW (document capture and liveness) and ID ONLY (document only).
• Verification queries with OCR-extracted data (GET /verifications, GET /verifications/{id}, GET /verifications/{id}/status).
• Webhooks for real-time verification lifecycle notifications.
• User management (GET /users/me, PATCH /users/me) and company management (GET /users/me/company, PATCH /users/me/company).
• Logo upload for branding (POST /users/me/company/logo).
• Usage statistics and quotas (GET /users/me/stats).
• Paginated activity logs (GET /users/me/logs).
• Webhook endpoint management (GET /webhook-endpoints, POST /webhook-endpoints, GET/PATCH/DELETE /webhook-endpoints/{id}).
• Last-hour verification list (GET /verifications/last-hour).
• Paginated verification list (GET /verifications/{size}/{page}).
• Verification images (GET /verifications/{verificationId}/images, GET /verifications/images/{id}).
• Manual verification feedback (POST /verifications/feedback, GET /verification-feedback/reasons).
• Billing (POST /billing/paymentMethod, GET /billing/{idSubscription}).
• Service health check (GET /health/status).