MMRY AI Public API
Memory infrastructure for AI assistants. Three operations, OAuth 2.0, designed for ChatGPT, Copilot, Gemini, Cursor, and MCP-compatible platforms.
Overview
The MMRY AI Public API lets external AI platforms maintain persistent memory for their users across sessions. A user grants your platform access through a standard OAuth 2.0 consent screen on mmryai.com. After that, your platform can load context at the start of a conversation, search memories during a conversation, and save new memories worth remembering — all on the user's behalf, scoped to their account.
The surface is intentionally narrow:
- Three operations. Load, search, save. Nothing else.
- OAuth 2.0 authorization code flow with PKCE. The standard. Refresh tokens rotate on every use.
- Stable shape. Memory lifecycle — how long memories last, how they age, how they're classified — is handled by MMRY AI internally. Your platform never sees those mechanics and never has to manage them.
The machine-readable spec lives at https://mmryai.com/openapi/v1.json. Like the rest of these docs, the spec is gated to authenticated MMRY AI users — fetch it with your JWT or API key. Use the download button below to save it as mmry-openapi-v1.json, then paste the JSON into your GPT builder, MCP server config, or other OpenAPI-aware tooling.
Authentication — OAuth 2.0
Every request to /v1/* requires an OAuth 2.0 bearer access token. The authorization code flow is standard:
Authorization request
Redirect the user's browser to:
GET https://mmryai.com/oauth/authorize
?client_id=YOUR_CLIENT_ID
&redirect_uri=https://your-platform.example.com/callback
&response_type=code
&state=OPAQUE_STATE_FOR_CSRF
&code_challenge=SHA256_OF_VERIFIER_BASE64URL
&code_challenge_method=S256The redirect_uri must match one of the redirect URIs registered for your client. PKCE is optional but recommended; we accept S256 or plain.
Token exchange
POST https://mmryai.com/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=THE_CODE_FROM_REDIRECT
&redirect_uri=https://your-platform.example.com/callback
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&code_verifier=YOUR_PKCE_VERIFIERResponse (200):
{
"access_token": "<64-char hex>",
"token_type": "bearer",
"expires_in": 3600,
"refresh_token": "<64-char hex>"
}Access tokens are valid for 1 hour. Refresh tokens are valid for 30 days, single-use, and rotated on every refresh.
Refresh
POST https://mmryai.com/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=YOUR_REFRESH_TOKEN
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRETinvalid_grant, treat the user as if they have logged out and restart the authorization flow from the beginning. Do not retry the same refresh_token.
Revoke
POST https://mmryai.com/oauth/revoke
Content-Type: application/json
{ "token": "<access_token or refresh_token>" }Revoking a refresh token cascades to every access token derived from it.
Discovery
The OIDC discovery document is at https://mmryai.com/.well-known/openid-configuration and lists the canonical endpoint URLs above.
The three operations
All three endpoints live under /v1/ and require the Authorization: Bearer <access_token> header.
Load memories
Returns the memories visible to the authenticated user. Optionally filter by scope:
GET /v1/memories?scope=payments HTTP/1.1
Authorization: Bearer <access_token>Response (200):
[
{
"id": 42,
"topic": "Refund Provider",
"content": "Use Stripe for all refund processing.",
"scope": "payments",
"category": "Decision",
"createdAt": "2026-02-22T10:00:00Z"
},
...
]Search memories
Keyword search across topic + content. The q parameter is required (1-200 chars). Optional scope filter.
GET /v1/memories/search?q=refund HTTP/1.1
Authorization: Bearer <access_token>Save a memory
POST /v1/memories HTTP/1.1
Authorization: Bearer <access_token>
Content-Type: application/json
{
"topic": "Refund Provider",
"content": "Use Stripe for all refund processing.",
"scope": "payments"
}Response (201):
{
"id": 42,
"topic": "Refund Provider",
"content": "Use Stripe for all refund processing.",
"scope": "payments",
"category": "Decision",
"createdAt": "2026-02-22T10:00:00Z"
}Fields:
topic(required, 1-200 chars) — short labelcontent(required, 1-8000 chars) — the memory itselfscope(optional, ≤100 chars) — context or project scope. Defaults to"general".
Category is determined by MMRY AI — your platform never has to think about it.
Errors & rate limiting
Error response shape
4xx and 5xx responses return either an OAuth-style error or an RFC 7807 problem document, always as JSON with a non-empty body:
{
"error": "invalid_grant",
"error_description": "Refresh token expired."
}or for validation failures:
{
"type": "https://tools.ietf.org/html/rfc7807",
"title": "One or more validation errors occurred.",
"status": 400,
"errors": { "content": ["Content must not exceed 8000 characters."] }
}Rate limits
Per-platform requests to /v1/* are limited to 200 requests per 60-second window by default. Specific platforms may have higher limits configured by MMRY AI.
When you exceed the limit you receive HTTP 429 with:
{ "error": "Too many requests", "retryAfterSeconds": 60 }The Retry-After response header carries the same value. Always respect it; back off and retry after the window elapses.
Registering a new platform
Platform registration is currently invite-only. To register your platform as an OAuth client:
- Email platforms@mmryai.com with: platform name, brief description of what users will use it for, and the redirect URI(s) your OAuth flow uses.
- We'll register your client and send you the
client_idandclient_secretthrough an out-of-band secure channel. - The
client_secretis shown exactly once. Store it in your platform's secret manager immediately; it cannot be retrieved later. If you lose it, request a rotation and we'll mint a new one (existing tokens will be revoked).
mmry-openapi-v1.json while signed in, then paste the JSON contents into the GPT builder's Actions dialog ("Import from URL" → "or paste schema here"). The GPT builder will import the three operations and detect the OAuth2 authorization-code flow automatically. Fill in client_id and client_secret when prompted.
FAQ
Do my users need a MMRY AI account?
Yes. The OAuth consent screen is the place where a new user can create an account inline; the flow lands them back at your platform with a working connection. If they cancel the consent screen, your platform receives error=access_denied at the redirect URI.
What memories can my platform see?
Only memories belonging to the authenticated user. Multi-tenant isolation is enforced by MMRY AI at every layer; cross-account leakage is impossible.
Can my platform classify memories?
No. Classification (category, scope semantics, retention) is handled internally and stays stable across MMRY AI releases. The intent is that your platform never has to manage memory lifecycle — just save what's worth remembering and read what's relevant.
What happens if a user revokes my platform's access?
The user can revoke at https://mmryai.com/account. Your existing access and refresh tokens are immediately invalidated. The next request returns 401; your platform should handle this by prompting the user to reconnect.
How do I rotate my client secret?
Email platforms@mmryai.com. We'll rotate and send you the new secret out-of-band. All existing tokens for your client are revoked at rotation time — plan for a brief reconnection window. (Note: automated webhooks on rotation are a roadmap item, not currently available.)
Where can I see what my platform is doing?
Each call to /v1/* is logged on the MMRY AI side with platform attribution, the user, the operation, and timestamp. Per-platform usage reports are available on request.