Outborn Agent Platform · Technical reference
Product API boundaries
Understand which interface is documented for external clients and which product routes need a deployment-specific contract.
Applied guidance
Best practices for product api boundaries
Recommended
- Use the documented MCP surface for the external capabilities covered here.
- Obtain a deployment-specific contract before integrating directly with a product domain route.
- Check authentication, response schema, rate limits, and versioning for that contract.
Avoid
- Do not infer that an internal backend route or model gateway is a supported public API.
01
Documented external entry point
For the capabilities described in this reference, use the authenticated MCP resource at /mcp/v1. It has discoverable tools and resources, a protected-resource metadata endpoint, and a defined JSON-RPC request and response shape. Start with the quickstart and discover current tool schemas before calling them.
02
Product domain routes
The backend also has routes for workspaces, agents, conversations, connections, data, reports, and governance. Their existence in the repository is not a public API stability promise. Before integrating directly with one, obtain the contract and availability for your deployment, including authentication, version, permissions, rate limits, and response schema.
03
Model gateway boundary
The private model gateway includes an OpenAI-compatible chat completion route for authenticated internal or virtual-key consumers. The customer-facing product API does not expose a generic public model proxy. Do not direct an external integration at private gateway routes based only on repository names.
04
External systems
Connecting Gmail, a database, or another provider is a separate application or MCP connection workflow in the product. Provider authentication and grants remain in force. The platform MCP tools documented here do not create a blanket provider-connection API.
Related documentation