mym Authentication for mym API
An authentication model built for an API for mym.
The security model behind mym API: creator-controlled authorization, encrypted tokens, and scoped access, so no team ever sees more than it needs.
mym API never requests or stores mym passwords, and no scraping or browser-session automation is involved.
What does the authentication model include?
Creator-controlled connection, scoped keys, and a full audit trail. mym API never asks for or stores a mym password.
Creator-controlled authorization
Each connection is initiated and approved by the creator, who decides what a workspace can access.
Encrypted tokens
Connection tokens are encrypted at rest and in transit, and never exposed in plain text after creation.
Scoped API keys
Keys are scoped to a project, a creator, and a set of resources, limiting the blast radius of any single key.
Key rotation and revocation
Keys can be rotated on a schedule or revoked instantly from one workspace view.
Team permissions
Roles for agency staff so managers, chatters, and developers only reach the data their role requires.
Audit logs
Every authorization change, key event, and permission edit is recorded with an actor and a timestamp.
Multi-account controls
One workspace holds multiple connected creators, each with independent scopes and revocation.
Secret masking
Keys and tokens are masked in the interface after creation, shown in full only once.
Webhook signature verification
Each webhook payload carries a signature so your endpoint can verify it came from mym API.
mym API never requests or stores mym passwords, and no scraping or browser-session automation is involved.
How is a signed webhook verified?
Signature verification across three common clients, using the shared secret from your workspace.
# Send a test delivery to your endpoint
curl -X POST https://your-app.example.com/webhooks/mym-api \
-H "X-MymApi-Signature: t=1738656000,v1=5f9c2b..." \
-d @payload.jsonVerify the signature header before trusting the payload.
What does a signed webhook request look like?
Every delivery includes a signature header your endpoint can check against a shared secret before trusting the payload.
POST /your-endpoint HTTP/1.1
Content-Type: application/json
X-MymApi-Signature: t=1738656000,v1=5f9c2b...
{
"event": "subscription.created",
"creator_id": "cr_1042",
"fan_id": "fan_88213"
}How do team access and multi-account controls work?
Agencies manage more than one creator and more than one role. The model keeps both separated by scope.
Per-creator scopes
A team member can be granted access to specific creators only, not the full roster by default.
Role-based permissions
Read-only, operator, and admin roles map to what each team member can view or change.
Session-independent keys
API keys do not depend on a logged-in browser session, so automation keeps running independently of staff turnover.
Frequently asked questions
- The model uses creator-controlled authorization, encrypted tokens, and scoped API keys with rotation and revocation.
- The connection is designed to work alongside a creator's existing account security, including two-factor authentication, without mym API ever requesting or storing a password.
- A key can be scoped to more than one creator inside the same workspace, but each creator's data remains separated by scope and by audit trail.
- The connection method is creator-controlled and credential-free: mym API never asks for a mym password or login session.
- Each webhook delivery includes a signature header, so your endpoint can confirm the payload came from mym API before processing it.
- A compromised key can be revoked instantly from the workspace, immediately cutting off access, with the revocation recorded in the audit log.
Build on mym today
Request early access to mym API and tell us what you want to build for your creators.