Adopt the Standard — openworkid.org

LinkedIn has the distribution.
upstand.work has the proof.

Every platform that shows professional profiles has the same problem: profiles are self-reported. Adopting the upstand.work standard means your platform can display verified credentials it didn't have to build itself — and signal to users and AI agents that the professionals on your platform are real.

—The case for adoption

Three things change when a platform implements the standard.

Trust signal

Verified profiles convert faster. A professional with three peer-verified experiences is demonstrably different from one with a self-written bio. Your platform surfaces that difference.

AI-agent ready

AI recruiting agents are already screening candidates. Structured, verified data via MCP means your platform's professionals are discoverable and trustworthy to AI systems — unverified profiles are not.

No build cost

You don't build the verification system. You don't run the trust graph. You integrate — and point to an open, neutral standard that neither you nor your competitors own.

The contrast effect

When a recruiter sees two profiles on your platform — one with a "Verified by upstand.work" badge showing five peer verifications, one without — the question shifts from "is this person good?" to "why isn't the other one verified?" That question does the marketing for you.

—Who should adopt

Three categories of platform have a clear adoption case. All three can integrate independently without a formal partnership.

Freelance platforms

Job boards & freelance marketplaces that need quality signals

Volume-based platforms cannot beat the incumbents on scale. They can beat them on trust. Verified professionals become a differentiator — "only verified freelancers" is a category, not a feature.

Examples: niche job boards, industry-specific talent platforms, remote-first marketplaces

"Our platform only shows professionals with verified experience — not just self-reported profiles."

HR software

ATS, HRIS, and background check tools that handle professional data

Candidate verification is a natural extension of ATS workflows. Integrating the Verification API means hiring managers see verification status inline — without building the verification system.

Examples: Personio, BambooHR-style tools, candidate screening products, onboarding platforms

"Automatically surface verified candidates. No manual reference checks for basic credential confirmation."

Communities

Professional communities, guilds, and associations that vouch for members

Communities have trust but no infrastructure. The standard gives them a way to formalise "this person is one of us" — verifiable by outside platforms and AI agents.

Examples: professional associations, Discord communities, Substack networks, alumni organisations

"Our members are verified. Membership means something — and now it's provable outside this community."

—What you get — and don't get

Adopters that formally register get co-marketing and Steering Group voice. What they never get is user data or exclusivity.

→ What registered adopters get

✓Co-marketing — "Powered by upstand.work Standard" on your platform and in our adopters list

✓Priority API access — higher rate limits and early access to new MCP tools before general availability

✓Steering Group voice — when the group forms (3–5 adopters), registered adopters have a seat and can propose schema changes

✓Migration support — direct contact for implementation questions and schema edge cases

✓Changelog notification — direct email when schema changes are proposed or merged

→ What nobody gets

✗Exclusivity — no exclusive access to verified profiles in any category or region, ever

✗User data — the Verification API returns verified/unverified and count only. No profile data, no contact details

✗Schema control — no single adopter can change the schema unilaterally. All changes go through the public RFC process

✗Access to the trust graph — the graph of professional relationships is not a product. It is not for sale and not for export

✗Passive candidate database — the standard is not a sourcing tool. Contact must go through the structured request channel

—Integration path

Three levels of integration — each independently useful. You don't need to implement all three to start.

Schema compatibility — read and display profile data

Import ProfessionalIdentity documents. Display experience records, verifications, and extension fields in your UI. No API key required — public profiles are freely readable via the MCP server or REST API.

M1 — Available nowNo registration required

Verification API — display the badge live

Integrate the Verification API to show a live "Verified by upstand.work" badge on your platform. The badge queries the API on each page load — it reflects the current verification count, not a cached snapshot. Requires an API key.

M2 — In developmentAPI key required

Full schema adoption — write the standard natively

Your platform stores and exports professional identity data in the upstand.work JSON-LD format. Profiles created on your platform are interoperable with any other adopter. Users can move their verified identity freely between platforms.

M1 — Spec availableSteering Group eligibility

Minimal L1 integration — read a public profile

// Fetch a verified profile — no API key needed
const res = await fetch(
  "https://api.upstand.work/v1/profiles/thomas-weber"
)
const { identity, verification_count } = await res.json()

// Display name, summary, and verification count in your UI
console.log(identity.name)            // "Thomas Weber"
console.log(identity.summary)         // "Senior Finance Controller..."
console.log(verification_count)       // 3
console.log(identity.humanProof.verified) // true

—The "Verified by upstand.work" badge

An embeddable trust indicator. Live-verified against the API on each load — not a static image that can be copied. The badge shows the current verification count. If a verification is withdrawn, the count updates.

✓Thomas WeberVerified by upstand.work · 3 verifications

Badge embed — HTML

<!-- Drop into any HTML page — self-contained, live-verified -->
<script
  src="https://badge.upstand.work/v1/embed.js"
  data-username="thomas-weber"
  data-theme="dark"
  data-api-key="oiw_api_your_key_here"
></script>

Badge embed — React component

import { UpstandWorkBadge } from "@upstandwork/badge"

// Renders the live badge — fetches on mount, updates on focus
<UpstandWorkBadge
  username="thomas-weber"
  apiKey={process.env.UPSTANDWORK_API_KEY}
  theme="dark"
/>

The badge is fälschungssicher — it calls the API live rather than rendering a static image. Anyone can copy an image. Nobody can fake a live API response.

—Verification API pricing

The API is priced per verification check. Schema implementation is always free. You pay only for the live trust signal — the same model as a payment gateway charging per transaction, not per customer.

Starter

€0.50

per verification check

Up to 10,000 checks/month

Badge embed included

Standard rate limits

Email support

Growth

€0.20

per verification check

10,000–500,000 checks/month

Badge embed included

Priority rate limits

Steering Group eligibility

Co-marketing listing

Enterprise

€0.10

per verification check

500,000+ checks/month

SLA guarantee

Custom rate limits

Dedicated support

Enterprise licensing (M3)

Schema reading (L1 integration) is always free and always will be. API pricing applies only to live badge rendering and automated verification checks. Pricing will be reviewed publicly before M2 launch — any changes will be posted in the Changelog with 30 days notice.

—Partner policy

Four rules that apply to every registered adopter. These are not negotiable.

Rule	What it means in practice
Data sovereignty	Adopters may display verified profile data. They may not store it in their own database, re-export it to third parties, or use it for advertising targeting. The data belongs to the professional.
No dark patterns	The "Verified by upstand.work" badge may not be shown on profiles where the verification check returned false, or used to imply verification that does not exist. Misrepresentation terminates the partnership immediately.
Schema fidelity	L3 adopters that store profile data in the upstand.work format must preserve all fields on import, including fields they don't display. They must not silently drop `mutualFlag`, `withdrawnAt`, or `regulatoryNotice`.
Open standard integrity	Adopters may not represent a fork or modified version of the schema as the upstand.work standard. Forks are permitted under MIT License — but must be clearly distinguished from the canonical standard.

Ready to adopt?

The schema is public and free to implement today. Register as an adopter to get an API key, co-marketing, and a seat at the Steering Group when it forms.

What to include in your email

→Your platform name and URL

→Which integration level you're targeting (L1, L2, or L3)

→Approximate monthly verification check volume (for API key tier)

→Any questions about the schema or partner policy