Presence+ Developer Platform · run by a nonprofit with Divine Mercy University
The API for the people who help people.
Identity, roles on relationships, consent, outcome measures and the hand-up to licensed care, held once in the Presence+ Network and open to your application through a REST API and SDK. Build the app your parish, campus, practice or ministry needs in weeks, on a record that already knows what a ministry is.
Applications are reviewed within one business day. HIPAA and SOC 2 are in progress; developers without a compliant organization keep client data in the Presence+ data store.
Built with and used by
- Divine Mercy Universityuniversity
- Mindspiritpractice
- Midstministry
- Raphaelministry
- [placeholder] Parish or dioceseministry
- [placeholder] Campus ministryministry
- [placeholder] Counseling practicepractice
- [placeholder] University partneruniversity
Why this exists
Ministries never talked to each other. Now they can.
A person who asked for help in one place was invisible in the next. The parish, the campus, the counselor and the course platform each kept their own list, and nothing moved between them except by email. The Presence+ Network is the shared record in the middle, and the platform is how your application joins it.
Then
- 01One spreadsheet per ministry, one login per app, one person entered five times
- 02A referral was an email, and nobody knew whether it landed
- 03Consent lived in a drawer; data lived wherever the vendor put it
- 04Outcomes were a feeling; nothing was measured session by session
- 05Every app re-invented accounts, roles and permissions, usually badly
Now, on the Presence+ Network
- 01One identity: Sign in with Presence+ works across every app on the Network
- 02Roles live on relationships, so leader, member and companion are facts about edges, not a column
- 03Consent is enforced on every call, relationship by relationship
- 04Regular Outcome Measures (licensed PCOMS) are served to every app
- 05A hand-up to licensed care and the step back down are part of the record
Identity
Sign in with Presence+ in a dozen lines
The identity server at api.presence.plus is a standard OpenID Connect issuer: authorization code with PKCE, discovery, userinfo. Your users get one account across every app on the Network; you get their memberships as claims.
Register a client, point it at the issuer, and let the person sign in the way they already do in the Presence+ shell. The access token then authorises your calls to the API as that person, with their roles and consents applied server-side.
const ISSUER = "https://api.presence.plus";
const d = await fetch(`${ISSUER}/.well-known/openid-configuration`).then(r => r.json());
// 1. Send the person to sign in (authorization code + PKCE)
const url = new URL(d.authorization_endpoint);
url.searchParams.set("client_id", process.env.PRESENCE_CLIENT_ID!);
url.searchParams.set("redirect_uri", "https://yourapp.example/auth/callback");
url.searchParams.set("response_type", "code");
url.searchParams.set("scope", "openid profile email memberships:read");
url.searchParams.set("code_challenge", challenge);
url.searchParams.set("code_challenge_method", "S256");
// 2. Exchange the code, then read who they are
const token = await exchangeCode(code, verifier);
const me = await fetch(d.userinfo_endpoint, { headers: { Authorization: `Bearer ${token.access_token}` } }).then(r => r.json());
// { sub, name, email, picture, memberships: [...] }curl https://api.presence.plus/.well-known/openid-configuration
# after the code exchange
curl https://api.presence.plus/api/oauth/userinfo \
-H "Authorization: Bearer $ACCESS_TOKEN"The platform
The Network holds the record. Your application holds the experience.
Everything a helping app needs and no app should own is held once and reached through one API.
Identity
01One person, every app
Sign in with Presence+ across the shell and every application on the Network. COPPA age attestation and guardian consent are handled server-side, so every app inherits them.
Relationships
02Roles on edges
Communities, groups, households and helping relationships, with the role carried on the relationship, not pinned to the person. Supervision is a circle, and the data model knows it.
Consent
03Enforced on every call
What a helper may see follows the relationship it was written on. The API applies it; your app never has to re-implement it.
Measures
04Regular Outcome Measures
The licensed PCOMS scales (ORS, SRS and relatives) served to any app, owned by the person, shared only by their choice.
Pathways
05Accompaniment Pathways
A community's ordered way forward, with branches, measures and named exits, that your app can walk a person along.
Signals
06The shell's home board
Send what matters next (a check-in due, a session at four, a message unread) and it appears on the person's Presence+ home with your app's name on it.
SDKs and frameworks
We speak your language
The REST API and the identity server work from anything that can make an HTTPS request. The SDK ships for TypeScript and Node first; the rest follow as members ask for them.
- REST + OpenID ConnectAvailableany language, today
- TypeScriptBeta@presenceplus/sdk (members)
- NodeBeta@presenceplus/sdk (members)
- Next.jsBetavia the TypeScript SDK
- ReactBetavia the TypeScript SDK
- AstroBetavia the TypeScript SDK
- SvelteKitBetavia the TypeScript SDK
- RemixBetavia the TypeScript SDK
- PythonPlanned
- RubyPlanned
- PHPPlanned
- LaravelPlanned
- ElixirPlanned
- GoPlanned
- FlutterPlanned
- WordPressPlanned
Available: supported today. Beta: shipping to Developer Network members now. Planned: on the roadmap; the REST API works from these languages in the meantime.
Integrations
The services the platform already connects to
Your application gets these through the Network rather than wiring each one itself.
- Available
Better Outcomes Now (PCOMS)
The Outcome Rating Scale, Session Rating Scale and related measures, under license, served to every app on the Network.
- Available
Stripe
Course purchases and memberships, processed by Stripe; your app receives the record, never the card.
- Available
Google Calendar and Outlook
Helpers' availability and sessions, synced both ways.
- Available
LiveKit and Deepgram
Video sessions and transcription, with consent recorded on the relationship.
- Available
Twilio and email
Messages people have asked for, sent by a person who knows them, never a campaign.
- Available
Anthropic
AI features that summarise, suggest and prepare, under terms that keep data out of training.
- Available
Supabase
The HIPAA-protected data store, owned by the nonprofit and controlled by the university.
- Planned
CarePortal
Verified needs from caseworkers routed to helpers in the same community.
From the people building on it
What developers and ministry leaders say
[placeholder] Replace with the quote Tom supplies.
[placeholder] Replace with the quote Tom supplies.
[placeholder] Replace with the quote Tom supplies.
A nonprofit, with the universities that lead in ministry
Not an asset to be sold. A commons with a board.
The Presence+ Network is operated by True Presence, Inc., a 501(c)(3), with Divine Mercy University. The board is small today. We are inviting the institutions that lead in ministry and formation to seat members, so that every ministry on the platform works from shared best practice and the platform is governed by the people it serves.
Operates the Presence+ Network
True Presence, Inc.
The nonprofit that holds the record, the HIPAA-protected data store and the identity server. Nobody can buy it.
Founding academic partner
Divine Mercy University
Creator of the Catholic Christian Meta-Model of the Person and, with Presence+, the Meta-Model of the Christian Ministry the platform is built on.
Builds the software
Mindspirit LLC
The engineering company behind the Network's software, licensed to the nonprofit like any other application.
Invited to the board
[placeholder] Your institution
Universities, dioceses and ministry networks that want a seat in governing the commons.
Pricing
One membership, priced like a developer tool
The Presence+ Developer Network is a monthly membership. Nonprofit and community use of the Network itself is free; the membership is for access to the SDK, the sandbox and the people who built the platform.
A team of three building a parish app
| Developer Network membership1 developer + 1 organization | $25 |
| Additional developers2 × $10 | $20 |
| Sandbox instanceyour own, with seeded data | included |
| Identity server, API and signals to the shell | included |
| Course library for your team | included |
| Total per month | $45/mo |
Included in the membership
- ✓REST API and SDK access on approval
- ✓A sandbox instance of the Network to build against
- ✓Sign in with Presence+ for your app's users
- ✓Signals to the Presence+ home board
- ✓The course library, open to applicants
- ✓Applications reviewed within one business day
We can only work with developers whose organization is HIPAA and SOC 2 compliant. If yours is not, you agree to keep client data in the Presence+ data store, which is held by the nonprofit; that compliance is part of what the membership gives you. Presence+ itself is in progress with SOC 2. The SDK is closed source; the fee is for access.
$ presence apply
Start building on the Network
Apply, get your sandbox, ship to the Presence+ sandbox, and go live on the platform with the identity server and the home board behind you.