API & MCP REFERENCE
The relationship graph, as an API and MCP server.
Read and write your tenant’s people, companies, deals, notes, tasks, activity, and relationship intelligence — over REST or MCP. 52 operations under /v1, one API key.
THE API
One key. Everything your team knows about a relationship.
Eight things you can read and write — people, companies, deals, notes, tasks, activity, meetings, and your team. One x-api-key header, paginated and filtered, scoped to what each user can already see.
Every list endpoint takes page · per_page · sort_by · order, filters such as email / domain / linkedin_url, and modified_since for incremental sync. Responses are JSON; errors are 401 (bad key) · 403 (wrong tenant or user) · 429 (rate limit). Every schema is defined in the OpenAPI 3.1 document.
Read · Write
PERSON
Every contact your team has emailed or met — deduplicated into one record.
GET POST PUT /v1/persons
Read · Write
COMPANY
Organizations, resolved by domain or LinkedIn, with the right people attached.
GET POST PUT /v1/companies
Read · Write
OPPORTUNITY
Your live pipeline — deals, mandates, transactions, with your own custom fields.
GET POST PUT /v1/opportunities
Read · Write
NOTE
Write a follow-up straight back to the record — rich text, linked to any entity.
GET POST PUT DEL /v1/notes
Read · Write
TASK
Create and assign action items with due dates — straight from an agent.
GET POST PUT DEL /v1/tasks
Read
ACTIVITY
The full email and meeting history behind every relationship.
GET …/activities · …/activity-stats
Read
MEETING
What’s on the calendar, and who’s actually in the room.
GET /v1/meetings
Read
USER
Who’s on the team — the directory that powers “who do I know.”
GET /v1/users · /v1/me
THE INTELLIGENCE
Four answers your CRM was never going to have.
A CRM only knows what someone took the time to type into it, and most email and meetings never get typed in. Rings reads the calendar and inbox directly, so these come from what actually happened, not from what got logged.
How strong?
PATHPOWER®
One number for how well your firm knows someone — shown 0–100, with a plain strength label. Score a whole watchlist in a single call.
GET …/pathpower · /v1/pathpower/scores
Who knows them?
PATHS
The warmest way in — ranked contacts and the people in between, so an intro beats a cold email.
GET …/recommended-paths
What’s the story?
AI SUMMARY
A briefing on any person or company, pre-written and cached — so reads cost you nothing per call.
GET …/ai-summary
What happened?
HISTORY
Every email and meeting with this person, captured at the server level and turned into a record. A CRM has the slice someone logged; this is the whole history, because nothing waits to be entered.
GET …/activities · …/activity-stats
Day to day you live in four ideas — who you know, how strongly, who can introduce you, what’s happened — across 52 operations: 31 GET · 11 POST · 5 PUT · 5 DELETE.
INTEGRATIONS
Wired into the stack you already run.
Read and write, permission-scoped. 18 write operations — create, update, delete — every one bounded by what the acting user can already do in Rings.
Per-user scoping. Add x-rings-user-id to answer “who do I know,” not just the firm.
Connect in minutes. Point an MCP-compatible agent at the server — no custom retrieval layer to build.
GENERATED FROM /V1 — READ & WRITE TOOLS
recommended-paths
Ranked warm paths to a target.
GET …/recommended-paths
pathpower
Bulk strength scores, ≤100.
GET /v1/pathpower/scores
ai-summary
Cached, structured summaries.
GET …/ai-summary
activities
Email + meeting history.
GET …/activities
notes
Write a follow-up note back.
POST /v1/notes
tasks
Create a task with assignees.
POST /v1/tasks
opportunities
Update pipeline fields.
PUT /v1/opportunities/{uuid}
full /v1
Every tool maps 1:1 to an operation.
52 operations
ARCHITECTURE
Sources in. API and MCP out. Data stays where it lives.
Rings ingests via scoped OAuth, unifies into a tenant-isolated graph, and serves over REST and MCP. It doesn't replace your CRM — it completes it.
Sources
SOURCES
OAuth 2.0 · read-only · scoped
Microsoft 365 · Exchange
Google Workspace · Gmail · Calendar
Salesforce · Dynamics
LinkedIn — each user’s own export
OAuth 2.0 · read-only · scoped
Platform
RINGS PLATFORM
Tenant-isolated relationship graph
RESOLVE
Identity unification
SCORE
PathPower® strength
PATHS
Ranked warm intros
SUMMARIZE
Cached AI summaries
ANALYZE
Activity analytics
ENRICH
200M+ datapoints
Consumers
CONSUMERS
x-api-key · optional x-rings-user-id
REST Salesforce / Dynamics embeds
REST Your internal web + mobile apps
MCP Claude / ChatGPT Enterprise
MCP Your firm-built copilot
REST Snowflake / Databricks pull
REST Compliance + BI dashboards
x-api-key · optional x-rings-user-id
Sources stay read-only. Every consumer reads the graph through the same authenticated, tenant-scoped API.
SECURITY & GOVERNANCE
Controls grounded in the production API spec.
Everything below is documented in the API & MCP reference — not aspirational. Permission-scoped, tenant-isolated, and rate-limited by default; writes never exceed the acting user's own access.
Auth
API-key auth, per-user scoping
All requests require an x-api-key header (prefix pk_)
Tenant-scoped keys — optional x-rings-user-id to act as a user
User-scoped keys permanently bound to a single user UUID
Source systems connect via CASA-reviewed OAuth 2.0 scopes
401 invalid/inactive keys · 403 cross-tenant or mismatched user
Isolation
Tenant-level data partitioning
Each API key scoped to exactly one tenant — enforced server-side
GET /v1/users returns only your tenant’s active users
US-only region pinning available
Encryption in transit — TLS 1.3
Writes
A write can’t exceed the user
Every create, update, and delete runs as a specific user
A write can’t touch records that user can’t already reach
No write path escalates beyond the app’s own permissions
Source ingestion stays read-only — nothing written back to email or CRM
SOC 2 Type II
GDPR
CCPA
Optional BAA
US region pinning
Security questions? Our team works directly with your InfoSec and procurement teams. SOC 2 Type II report available under NDA.









