MultiVibe Cloud

Developers

← Back to dashboard

API & limitations

This reference describes the lower-level API clients. For the native chat UI, managed sign-in, foreground tools and shared history, see the iOS chat SDK.

Choose an authentication path first

  • Server: supply a project key through your secret manager or environment. Never ship it in browser or mobile code.
  • User pays: register an app in My apps and follow Authorization Code + PKCE. The user consents and selects the paying project. Web exchange and refresh require a backend-for-frontend; do not expose refresh tokens to JavaScript. Native apps own OS-secure storage. Token callbacks in the snippets must return valid authorized access tokens, not an app ID.
  • Publisher pays in a client app: ten-minute application sessions, registered IdP verification, application/user quotas, CORS configuration and App Attest/Play Integrity server verification are not implemented. There is no supported backendless publisher-funded setup yet. An authenticated publisher backend can use its server key, but must implement its own user authorization and limits.

TypeScript includes PKCE and in-memory single-flight token helpers. Other clients accept externally maintained token providers. Serialize refreshes, save replacement tokens atomically, and reconnect after an uncertain refresh response instead of replaying a token. New scopes require new consent.

Operations, streaming and usage

The generated route manifest is sdk/contract/v1.json. Request/response schemas and error taxonomies are not yet fully generated or unified. Use the language's convenience methods or generic call API with the model's native payload. Tool requests are returned as data; the SDK never executes tools automatically.

  • models, generate and chat target /v1/models, /v1/responses and /v1/chat/completions.
  • catalog, embeddings, rerank, images, transcribe, translate, speech and realtime describe declared capabilities, not guarantees of active production routes. Rerank uses /mistral/v1/rerank.
  • The production-safe entrypoint does not currently admit all declared modalities or catalog. Audio transcription/translation payloads here are JSON, not multipart. Speech returns binary data. Realtime is declared as HTTP POST streaming, not WebSocket or WebRTC.
  • Streaming is incremental SSE. Cancel through the platform API and dispose owned streams. Never retry billable inference automatically after a timeout or partial output; cancellation and buffering guarantees are not yet uniform across clients.
  • Read authorized request usage through /v1/inference/requests/{requestId}/usage. Preserve decimal cost strings; missing or provisional usage is not a zero bill. Normalized usage states and project aggregates are not fully implemented. Local execution does not provide Cloud cost or invented token counts.

Local execution and explicit fallback

Swift exposes AppleLocalEngine through the optional MultiVibeLocal product. Kotlin exposes AndroidLocalEngine through android-local with the experimental ML Kit Prompt dependency. React Native, Flutter and Ionic do not yet bridge these engines. No third-party model runtime or weights are distributed.

Check availability at runtime; iOS version alone is not proof of system-model availability. The Apple modules compiled against the installed iOS 27 SDK, but neither Apple nor Android local inference has been verified on a physical device in this delivery.

  • cloud: use the specified Cloud model.
  • local: no Cloud inference; fail explicitly when unavailable.
  • auto: provide a fallback Cloud model and explicit permission to transfer. Current routing falls back only on preflight unavailability. Generation failures and safety refusals propagate, with no Cloud retry after partial output.

Single-generation routing exists in TypeScript, Swift and Kotlin; unified routed streaming and capability-based multimodal routing are unfinished. Results expose execution and fallback information where routing is implemented. There is no promise of image, audio or realtime parity with local models.

Validation and release status

The current Android source validation records 61 passing JVM tests and a successful debug AAR build. Earlier cross-language validation recorded passing TypeScript, Python, Java, Rust, Swift and Go tests plus Cloud compilation. React Native and Ionic TypeScript re-exports compiled, but were not exercised in native apps. These are local source checks, not a live CI indicator or device acceptance.

No physical-device acceptance, authenticated live Cloud validation, package publication or SDK deployment was performed. Shared SSE fixtures currently cover TypeScript, Python, Go, Java and Rust, not all eleven targets. Consult sdk/README.md and sdk/VALIDATION.md in the checkout for gaps and exact commands. Do not treat this preview as a completed mobile security product.