My Jarvis LogoMy Jarvis
Developer access

API and webhook access for serious MyJarvis integrations

Request-gated, scoped, and measured.

The developer surface is intentionally controlled while MyJarvis proves Voice care operations and partner demand. Start with a review request before any keys, rate limits, or production callbacks are issued.

Platform gate

API readiness checklist

Scopes

Explicit permissions

Voice, reports, webhooks

Keys

Server-side only

No public secrets

Events

Idempotent callbacks

Retries and ownership

No browser-exposed service keys or provider credentials.
Every API client starts as requested or review before active access.
Rate limits, scopes, and webhook URLs are recorded server-side.
ACP callbacks stay protected and current ACP expansion remains deferred.

Access scope

What developer access can cover

These are platform directions, not automatic live entitlements. Each request is reviewed against demand, security, ownership, and support capacity.

Voice integration review

Request access for account-bound Voice workflows, callbacks, and operational handoffs after delivery capacity is confirmed.

Webhook integrations

Register callback expectations, idempotency keys, event ownership, and retry behavior.

Partner reporting

Review exports for partner-sourced accounts, wholesale credits, client status, and usage.

Security review

Confirm scopes, rate limits, owner contacts, webhook URLs, and support boundaries before activation.

Current boundary

Public API launch waits for real operational demand

For now, MyJarvis keeps the Next.js API routes under the existing Vercel app and uses Azure only for heavy/background workers. Separate api, developers, or partner subdomains should wait until demand or ownership boundaries justify them.

Request review

Describe the integration before keys exist

Submit expected volume, webhook URL ownership, data access needs, and support expectations from the customer workspace.