Clients and SDKs
The three clients that talk to the platform (the browser editor, the CLI, and the app's own SDKs), what each calls, how it authenticates, and where the call lands.
Three clients talk to the platform on a builder's behalf: the editor in the browser, the CLI on a laptop, and the SDKs the app's own code is written against. This chapter describes them from the platform's side: what each calls, how it authenticates, and where the call lands.
#The Editor
The editor is the Remy console's development surface, served as a Cloudflare Worker and authenticated with the builder's platform session. It talks to four places:
| Channel | Where | What |
|---|---|---|
| Management API | The HTTP role, management routes | Releases, secrets, custom domains, files, data sources, audit, settings, the dashboard |
| Develop API | The HTTP role, develop routes | The coding agent, dev sessions, attachments, voice recordings, wireframes, workspace snapshots |
| Control channel | The sandbox-proxy role, authenticated origin | The dev box's files, shell, search, and agent actions over a WebSocket; the language server over a second WebSocket; logs and agent state |
| Realtime | The WS role | Build progress, dev-session events, app events, presence |
The editor also loads the app's preview from the dev box's public preview host, which is a different origin from the control channel by design. See Dev Boxes.
The coding agent runs inside the platform. The editor sends the conversation; the platform runs the agent loop, with the model service and the dev box as its tools, and streams back the result. Every agent call renews the dev session's lease.
#The CLI
The CLI authenticates with a workspace API key and offers two things the browser cannot.
Git. The app's repository is a standard git remote on the platform's git host, authenticated with the same key. Any git client works. See Git Hosting.
The tunnel. A developer can run their app's methods on their own machine. The CLI opens a tunnel session. The platform records a dev environment whose origin is the laptop, and routes that person's dev invocations to a queue the CLI drains. The methods run locally against the same dev database, through the same SDK, with a hook token whose environment is dev. External requests the tunnel proxies in, such as a webhook from a payment provider, carry a validated dev-session header so they land in the same environment.
The CLI also publishes files to an app's stores at build time and manages secrets.
#The SDKs
App code is written against two SDKs, one for methods and one for the web interface.
The backend SDK runs inside the sandbox. It exposes the app's tables, auth, files, events, models, data sources, and platform actions as functions. Every one of those is a call back to the platform on the callback origin, carrying the execution's hook token:
| SDK call | Platform endpoint | Handled by |
|---|---|---|
| Table reads and writes | The database query path | The app-db role, via the WS role |
| Role checks and user lookups | The auth context on the hook token, and the app-user routes | The HTTP role |
| File put, get, head, list, delete; upload grants | The brokered file and upload routes | The HTTP role, then S3 |
| Model calls: chat, embeddings, images, speech | The model service | The HTTP role, then the provider |
| Data source search and ingest | The data source serve routes | The HTTP role, then Qdrant |
| Realtime publish and grant | The app events routes | The HTTP role, then the event stream |
| Platform actions: scrape a URL, search, analyze an image, generate an image or chart, rehost a resource, concatenate audio, unzip | The platform-action hooks | The HTTP role, through the counterparty registry |
| Outbound email, SMS, voice calls | The email, notification, and voice routes | The HTTP role, then SES, the telephony provider, LiveKit |
| Tasks, progress, background stdout | The task and method routes | The HTTP role |
| Secrets | Already present as environment inside the sandbox | Nothing to call |
The SDK holds no vendor key and no platform credential. What it has is the hook token, and every endpoint it calls resolves that token to an app, a release, an environment, a user, and their roles before doing anything. That is why a sandbox can be denied every internal address and still have the whole platform available to it.
The frontend SDK runs in the browser inside the web interface. It calls the app's own origin under the internal prefix: methods, sign-in and session, file URLs, the event stream, agent chat. It never holds a credential beyond the app's session cookie.
#Build Services
Two more clients call the platform without a human. The job runners post build logs, completion callbacks, and upload requests to internal build endpoints, using short-lived build credentials. The voice worker registers with a standing token, then authenticates each session with a per-session credential.