Credentials checklist

Extentos itself needs no provider keys. The MCP server, simulator, and code generation work for free with no signup at all (the auth flow handles linking later).

AI shows up in an Extentos app two distinct ways, and only one of them needs a key in your code:

• The Phase-4 voice assistant runs on the managed AI gateway by default — no key in your app. glasses.assistant.start(...) routes through Extentos's gateway on Extentos's provider key; you supply nothing. The opt-out is BYOK in the dashboard: upload your OpenAI key in the project's Credentials section and the gateway swaps it in server-side (your app still never holds it). Either way, no provider key lives in your handler for the assistant path. See the gateway page.
• Handler-code calls to your own AI provider need your key. If your handler calls Anthropic / OpenAI / DeepL / etc. directly (e.g., to run a vision model on a captured photo or summarize a transcript outside the assistant), that key lives in the developer's process. Extentos never sees it. The rest of this page is the checklist for this path.

Plus one non-AI credential set:

• Real Meta Ray-Ban hardware — testing or shipping on physical glasses (not just the browser simulator) requires the developer's own Meta Developer Center registration.

Surface the relevant entries from this page while writing the handler, not at deploy time. If a developer is writing a translation handler, mention DeepL or Google Translate in the same exchange — not three days later when they try to ship.

Quick decision table

The simulator and managed-assistant paths intentionally need zero credentials — that's the point of Extentos's anonymous-first model and the managed gateway. Provider keys come up only for direct handler-code AI calls, and Meta credentials only when the developer leaves the simulator for real hardware.

LLM providers

Only one is required, pick whichever the developer prefers. All have free tiers usable for development.

Anthropic (Claude)

• Portal: console.anthropic.com/settings/keys
• Env var convention: ANTHROPIC_API_KEY
• Free tier: $5 of credit on signup; pay-as-you-go after.
• Best for: Long-context reasoning, tool use, code generation in handlers.

OpenAI

• Portal: platform.openai.com/api-keys
• Env var convention: OPENAI_API_KEY
• Free tier: Limited free credits on signup; pay-as-you-go after. Multi-modal (text + vision + speech) under one key.
• Best for: Vision through GPT-4 Vision, transcription via Whisper, generic chat.

Google Gemini

• Portal: aistudio.google.com/app/apikey
• Env var convention: GEMINI_API_KEY
• Free tier: Generous free quota (1500 requests/day on Flash, lower on Pro). Best free option for prototyping.
• Best for: Cost-sensitive prototyping, multi-modal, fast iteration before committing to a paid provider.

Vision APIs

If your app captures photos and the handler needs to interpret them, pick one:

For most apps, just reuse the LLM provider's key — GPT-4o, Claude, and Gemini all do vision under the same key. Separate vision-only providers only matter when you need their specific capabilities (Google's high-accuracy OCR, Azure's domain models).

Translation

For multilingual apps:

DeepL is generally higher quality for European languages; Google Translate has wider language coverage. HuggingFace Inference works for self-hosted or community models.

OCR

If the handler reads text out of camera frames:

Most LLMs with vision (GPT-4o, Claude, Gemini) can do OCR-style tasks under their existing key — separate OCR services matter for high-volume document workflows.

Premium voice synthesis (production)

Optional. Production apps use phone-native TTS by default (TextToSpeech on Android, AVSpeechSynthesizer on iOS) at zero cost. If the developer wants higher-quality voices:

Wire premium voice via ExtentosConfig.premiumVoice in the library config — see the configuration reference. Extentos doesn't sit in the runtime path; the library calls the provider directly from the phone.

Meta Developer Center (real hardware)

Skip this until the developer is ready to test on physical Meta Ray-Ban glasses. The browser simulator and LocalSimTransport don't need any of it.

When real hardware comes into play:

1. Create a Meta Developer account at developers.meta.com.

2. Register a Wearables app under the developer's account.

3. Bind the app to platform-specific identifiers:

   • Android: package name + release signing SHA-256.
   • iOS: Bundle ID + Team ID + a custom URL scheme of the developer's choosing.

4. Retrieve the Meta App ID and Client Token from the Meta Developer Center dashboard.

5. Set your Meta credentials in the AndroidManifest <meta-data> (Android) / Info.plist MWDAT dict (iOS) — the MWDAT SDK reads them from there at init (Wearables.initialize(applicationContext) takes only the context). There is no runtime credential-injection path through ExtentosConfig.

   <application>
       <meta-data android:name="com.meta.wearable.app_id"
                  android:value="@string/meta_app_id" />
       <meta-data android:name="com.meta.wearable.client_token"
                  android:value="@string/meta_client_token" />
   </application>

   <key>MWDAT</key>
   <dict>
       <key>MetaAppID</key><string>$(META_APP_ID)</string>
       <key>ClientToken</key><string>$(META_CLIENT_TOKEN)</string>
       <key>TeamID</key><string>$(DEVELOPMENT_TEAM)</string>
   </dict>

6. Source the values from local.properties → string resource (Android dev) or an .xcconfig substitution into Info.plist (iOS) — never hardcode them in source. The MCP getCredentialGuide tool emits the exact manifest/Info.plist entries and the local.properties-first wiring for the developer's platform.

The MCP getCredentialGuide tool walks through this interactively with the developer when they call it — that's the agent-facing entry point if step-by-step is preferred over this static reference.

Voice in the simulator (no keys needed)

The browser simulator's STT and TTS run on Extentos-managed infrastructure (the voice proxy described in accounts and pricing). Developers don't sign up for Whisper, OpenAI, or any voice provider to use voice in the simulator — that's deliberate, so the first speak/listen experience works out of the box.

Voice in the simulator is unmetered for linked accounts (the browser simulator itself requires sign-in — see pricing) — there's no separate voice quota. On real hardware, voice runs entirely on the phone (zero Extentos cost, zero provider keys).

Where to put keys

Never check provider keys into source control.

• Android: local.properties for dev (read at Gradle config time, deterministic across IDE-launch + daemon-reuse), with System.getenv(...) as the CI/release fallback baked into the same snippet. The getCredentialGuide response embeds the exact Properties().apply { ... } block to paste into app/build.gradle.kts. Keys surface at runtime via context.getString(R.string.<keyname>) (NOT BuildConfig.X — that path inlines stale keys across rotations).
• iOS: .xcconfig files (gitignored) or environment variables on the build runner. Read at runtime via Bundle.main.object(forInfoDictionaryKey:).
• Local dev: for the dev-machine path, local.properties (Android) / Secrets.local.xcconfig (iOS) — both gitignored by default. .env files work for non-build runtime use.

For real production deployments, prefer build-time secret injection over runtime env vars where possible — it keeps the keys out of the running app's process memory.

When to surface this

If you're an AI agent scaffolding an integration for a developer:

• At handler-scaffolding time, look at which BYOK providers the handler will call. Surface the matching rows from the Quick decision table inline so the developer knows what they'll need before they get deep into handler code.
• At code-generation time, call getCredentialGuide(services, platform) and apply the returned build.gradle.kts snippet directly — the canonical local.properties-first pattern is already baked in.
• Before the first real-hardware test, surface the Meta Developer Center section as a separate setup step — it's a longer process (~15-30 min) and the developer wants to do it once, not interleaved with handler code.

Don't dump the full table on a developer who's still in the simulator; it adds noise. The simulator path is meant to need no keys at all.

Related

• Auth — Extentos account auth, separate from provider keys
• Configuration — env vars and config-file settings
• Production tools — getCredentialGuide, getProductionChecklist
• Pricing — what the free tier covers

Related