Skip to main content

Overview

Jinba Toolbox exposes a REST API built on Hono.js. Every resource — organizations, toolsets, tools, versions, runs, webhooks, and API keys — is accessible through conventional HTTP endpoints under the /v1 prefix. Base URL:

Authentication

All API requests (except explore routes) require authentication via a Bearer token. API keys are scoped to an organization, act with Member-level permissions, and follow the jtb_ prefix convention. The web console authenticates with a JinbaAuth session token instead. Include the key in the Authorization header:
A few endpoints need a signed-in user rather than an API key and return 401 when called with a key: GET /v1/orgs, GET /v1/orgs/:orgId, GET /v1/orgs/:orgId/members, the .../test endpoint, and creating, revealing or deleting API keys. Publishing a version with an API key fails with 400 (“User context required”).
1

Create an API key

Navigate to your organization settings and create a new API key. Give it a descriptive name such as production or ci-cd.
2

Store the key securely

Copy the key immediately after creation — it will not be displayed again. Store it in an environment variable or secrets manager.
3

Include the key in requests

Pass the key as a Bearer token in every API request.

Endpoint Reference

Organization Routes

These endpoints require organization membership. The authenticated API key must belong to the target organization. :orgId accepts the organization ID (or its slug). Organizations are created, updated and deleted in JinbaAuth; POST, PATCH and DELETE on these paths return 403 (POST returns 401 when called with an API key).

ToolSet Routes

Tool Routes

inputSchema and outputSchema are not request fields: whenever code is created or updated, the API extracts both schemas from the code’s input / output definitions and rejects the request (400) if they cannot be extracted.

Execution Routes

Version Routes

Run History Routes

Other Organization Routes

Public Routes

Public routes allow external consumers to execute tools using an API key, without requiring organization membership context. :orgId must be the provider organization’s canonical ID (slugs are not accepted). Any valid API key can call a public ToolSet; a private ToolSet is only accessible with its own organization’s key. Credits are charged to the caller’s organization.

Explore Routes

Explore routes are unauthenticated and allow browsing public toolsets.

Request & Response Examples

Execute a Tool

Request:
Response (always 200; check success):
When the tool fails, success is false and error ({ name, message, traceback? }) is set instead of output.

Execute via Public Endpoint

The public response has the same shape but omits logs.

Create a ToolSet

visibility is private or public; resources.timeout is in milliseconds (max 3600000, default 15 minutes when omitted).

Publish a Version

The new version becomes the active version of the default environment unless you pass "setAsPublished": false or another environmentSlug. Publishing requires a signed-in session.

Error Handling

The API uses RFC 9457 Problem Details format for errors:

Common Status Codes

Best Practices

  • Store API keys in environment variables — never hard-code them in source code or commit them to version control.
  • Implement retry logic with exponential backoff for transient failures.
  • Use the public endpoint (/v1/public/...) when integrating external systems that only need to execute tools.
  • Pin a specific version in the run request body when reproducibility matters.
  • SDK — Type-safe client library wrapping these endpoints
  • MCP Integration — Model Context Protocol endpoints
  • Webhooks — Receive event notifications for tool runs and more