Build With Gobii
Gobii exposes several developer surfaces. Pick the one that matches how your product or workflow should interact with Gobiis.
Choose a surface
| Need | Use |
|---|---|
| Create, update, activate, message, or inspect persistent Gobiis from your application | Agent API |
| Let an external AI client create, manage, message, wait on, and attach files to Gobii agents | Remote MCP |
| Receive asynchronous task completion or event notifications | Webhooks And Events |
| Request machine-readable JSON output | Structured Data |
| Run one-off browser-use jobs through the older technical task API | Legacy Browser Tasks |
| Run Gobii in your own environment | Self-Hosting |
Recommended starting path
- Read Developer Basics for base URLs, authentication, environments, and conventions.
- Create a persistent agent through the Agent API.
- Send messages and inspect timelines instead of creating separate task abstractions when you want long-lived context.
- Add Webhooks And Events when your system needs callbacks.
- Use Remote MCP when an MCP-capable client should operate Gobii directly.
Stable public APIs versus product internals
Gobii has many authenticated console routes for the web app. Those routes are implementation APIs for the product UI unless the docs explicitly describe them as public developer surfaces.
For production integrations, prefer:
/api/v1/agents//api/v1/mcp/- documented browser-use task routes when you need the legacy task API
- documented webhook surfaces
If you need a console-only capability exposed as a stable API, treat that as a product/API request rather than depending on private UI routes.