Workspaces API

Manage workspaces, members, and invites. Workspaces are called teams in the API: endpoints live under /teams and requests carry team_id. Every API key belongs to a workspace, and apps, tasks, secrets, and billing are scoped to it.

Requires API key scopes teams:read (list, get, members, invites) or teams:write (create, update, delete, member changes, invite management). Create keys in settings → workspace → api keys.

→ Authentication · Entitlements: plan limits per workspace

Get current user

GET /me

Returns the authenticated user and the current workspace (team) resolved from the API key (or guest context). Requires a valid API key.

Response

1{2  "user": {3    "id": "usr_abc123",4    "email": "[email protected]",5    "name": "you",6    "full_name": "Alex Example",7    "default_team_id": "team_personal",8    "avatar_url": "https://...",9    "metadata": {10      "completed_onboarding": true,11      "use_case": "agents",12      "signup_source": "github",13      "terms_accepted_at": "2026-01-15T10:30:00Z",14      "terms_version": "2026-01"15    }16  },17  "team": {18    "id": "team_xyz",19    "type": "team",20    "name": "Acme",21    "username": "acme",22    "setup_completed": true,23    "status": "active"24  }25}

team is omitted when no workspace context is attached to the request.

The nested user.metadata object (UserMetadataDTO) tracks onboarding and consent state:

JavaScript SDK:

1const { user, team } = await client.teams.me();

Example:

1curl https://api.inference.sh/me \2  -H "Authorization: Bearer inf_your_key"

Survey

Customer-discovery and open feedback submitted from the CLI (belt feedback) or other clients.

List your responses

GET /me/survey

Returns survey answers for the authenticated user. The response lists every structured answer first (discovery, use_case, need, testimonial, and legacy feedback), then the most recent freeform open:* rows, up to 100 rows in total. Open feedback never pushes structured answers off the list. The CLI uses this list to decide which onboarding questions are still pending.

Response:

1{2  "responses": [3    {4      "id": "srv_abc123",5      "question_id": "discovery",6      "response": "github",7      "agent": "cursor",8      "source": "cli",9      "context": "belt login, belt app run, belt task get abc123"10    }11  ]12}

Submit a response

POST /me/survey

Structured question IDs (discovery, use_case, need, testimonial, feedback) are append-only — each submit creates a new response row. The CLI prompts for all four active questions (use_case, discovery, need, testimonial) in order; feedback is a legacy ID still accepted by the API. Open feedback (open) also creates a new entry each time (stored with a unique question_id suffix server-side).

Rewards: The response includes granted_amount (microcents). The first answer to each structured question earns $1 in credits when the trimmed response meets the minimum length (discovery: 2 characters; use_case, need, testimonial, feedback: 10 characters). Open feedback never earns credits. Rewards expire after 30 days.

When the answer is recorded but no credits are granted, reward_blocked_reason says why:

Fill-in placeholder text (for example your answer here or <your answer>, copied from CLI help) is rejected with 400 and nothing is stored, so it cannot use up the question's one rewarded answer.

Example:

1curl -X POST https://api.inference.sh/me/survey \2  -H "Authorization: Bearer inf_your_key" \3  -H "Content-Type: application/json" \4  -d '{5    "question_id": "discovery",6    "response": "github",7    "source": "cli",8    "context": "belt login, belt app run, belt task get abc123"9  }'

Response:

1{2  "response": {3    "id": "srv_abc123",4    "question_id": "discovery",5    "response": "github",6    "source": "cli",7    "context": "belt login, belt app run, belt task get abc123"8  },9  "granted_amount": 10000000010}

granted_amount is in microcents (100000000 = $1.00). Omitted or 0 when no reward was earned.

No-reward example (duplicate answer):

1{2  "response": {3    "id": "srv_def456",4    "question_id": "discovery",5    "response": "web dashboard",6    "source": "cli"7  },8  "reward_blocked_reason": "already_answered"9}

Errors (400):

→ CLI setup — Feedback

Bounties

Incentive programs that grant credits when you complete qualifying actions (for example, deploying a useful app or answering survey questions). Requires authentication.

List active programs

GET /bounties

Returns active bounty programs sorted by notice_priority (ascending). Each program includes its stable name (used as bounty_id when claiming), reward amount, proof requirements, and CLI notice configuration.

The belt CLI calls this endpoint to populate stderr bounty notices. Responses are cached locally for 6 hours (~/.belt/cache/bounty-programs.json); admin edits to notice fields propagate on the next cache refresh without a CLI release.

Response — array of BountyProgramDTO objects:

Claim a bounty

POST /me/bounty

For proof_type: app, proof_id must be an app you own that has been deployed (version_id set). The server records proof_ref as namespace/name and resource_id as the app ID (same value as proof_id for app proofs).

Response:

1{2  "submission": {3    "id": "bsm_abc123",4    "bounty_id": "app-builder",5    "resource_id": "01abc123def456",6    "proof_id": "01abc123def456",7    "proof_ref": "you/my-app",8    "agent": "cursor",9    "source": "cli"10  },11  "granted_amount": 50000000012}

granted_amount is in microcents (500000000 = $5.00). Omitted or 0 when no credits were granted (for example, duplicate claim).

submission.resource_id is the app ID resolved from proof_id when the program's proof_type is app — omitted for other proof types.

Errors (400):

When the team has no saved payment method, the API may return 402 with code payment_method_required and meta.billing_page set to /settings/team/billing/payments (add a card under team billing settings before credits are granted).

Example:

1curl -X POST https://api.inference.sh/me/bounty \2  -H "Authorization: Bearer inf_your_key" \3  -H "Content-Type: application/json" \4  -d '{5    "bounty_id": "app-builder",6    "proof_id": "01abc123def456",7    "source": "cli"8  }'

Survey rewards use the same bounty system internally (bounty_id = survey-<question_id>) but are claimed automatically via POST /me/survey — see Survey above.

Bounty program administration (creating programs, pausing, viewing claims) is internal and not exposed on the public REST API.

SDKs: No client.bounties namespace yet in either SDK. Import BountyProgramDTO, SubmitBountyRequest, and SubmitBountyResponse from inferencesh.types (Python) or @inferencesh/sdk (JavaScript) when calling these endpoints directly — see Python SDK — generated bounty types and JavaScript SDK — generated bounty types.

→ CLI setup — App bounties · Billing — credit grants

Data export

Request a ZIP archive of your account and workspace data (GDPR Articles 15 and 20: right of access and data portability). Requires authentication as the account owner (session token or API key).

Request export

POST /me/export

Starts an asynchronous export job. Returns 202 Accepted with the export ID and initial status.

Response:

1{2  "id": "uex_abc123",3  "status": "pending"4}

If you already have a pending or processing export from the last 24 hours, the API returns that existing job instead of starting a duplicate.

Get export status

GET /me/export/{id}

Poll until status is completed or failed. When complete, the response includes a presigned download_url (valid for one hour).

Example:

1# Start export2curl -X POST https://api.inference.sh/me/export \3  -H "Authorization: Bearer $(belt auth token)"45# Poll for download URL6curl https://api.inference.sh/me/export/uex_abc123 \7  -H "Authorization: Bearer $(belt auth token)"

The ZIP contains JSON files for your user profile, sessions (tokens redacted), API keys (masked), workspace resources (apps, agents, flows, knowledge, projects, chats, tasks, files, secrets, integrations, triggers), billing, notifications, and survey responses. Processing may take several minutes; the server enforces a 10-minute timeout per job.

List workspaces

GET /teams

Returns all workspaces the authenticated user belongs to (personal workspace, shared workspaces, and organization workspaces you administer).

Requires teams:read.

Response

Array of workspace objects:

Workspace types

Example:

1curl https://api.inference.sh/teams \2  -H "Authorization: Bearer inf_your_key"

JavaScript SDK: client.teams.list()

Get workspace

GET /teams/{id}

Returns a single workspace by ID. Requires teams:read and membership (or admin access).

JavaScript SDK: client.teams.get(teamId)

Create workspace

POST /teams

Requires teams:write.

Request

1{2  "name": "Acme Engineering",3  "username": "acme-eng",4  "email": "[email protected]"5}

Returns the created workspace object. New workspaces may need Complete setup before all features are available.

JavaScript SDK: client.teams.create({ name, username, email })

Update workspace

POST /teams/{id}

Updates workspace metadata. Requires teams:write and appropriate role (owner or admin).

JavaScript SDK: client.teams.update(teamId, { name, username, email })

Delete workspace

DELETE /teams/{id}

Permanently deletes a workspace. Requires teams:write and owner role. Personal workspaces cannot be deleted.

JavaScript SDK: client.teams.delete(teamId)

Check username availability

GET /teams/check-username?username={name}

Returns an AvailabilityResponse, the same shape used by page slug availability checks. Use before create or rename.

Requires teams:read.

Response:

Use reason for user-facing messages instead of maintaining a client-side reserved-name list — the server owns the full reserved namespace.

1{2  "value": "acme-eng",3  "available": false,4  "reason": "taken"5}

JavaScript SDK: client.teams.checkUsername('acme-eng')

Complete setup

POST /teams/{id}/complete-setup

Chooses the workspace username during onboarding.

Request

1{2  "username": "acme"3}

Requires teams:write.

Members

List members

GET /teams/{id}/members

Returns workspace members with roles. Requires teams:read.

These fields mirror the same checks enforced by POST /teams/{id}/members/{userId}/role and DELETE /teams/{id}/members/{userId}.

Use them to drive member-management UIs without reimplementing server rules:

• Only owners may grant the owner role; admins cannot demote an existing owner.
• A team must keep at least one owner (the last owner cannot be demoted or removed).
• The organization workspace team accepts owner and admin only — member is not assignable there.

Mutations still enforce the same rules and return 403 or validation errors when a change is not allowed.

JavaScript SDK: client.teams.getMembers(teamId) — typed as TeamMemberDTO with assignable_roles and removable.

Python SDK: import TeamMemberDTO from inferencesh.types when calling this endpoint with httpx or requests (no client.teams namespace yet).

Add member

POST /teams/{id}/members

1{2  "email": "[email protected]",3  "role": "member"4}

Requires teams:write. Adds an existing platform user by email, or creates a pending invite when the email is not registered.

JavaScript SDK: client.teams.addMember(teamId, { email, role })

Remove member

DELETE /teams/{id}/members/{userId}

Requires teams:write.

JavaScript SDK: client.teams.removeMember(teamId, userId)

Update member role

POST /teams/{id}/members/{userId}/role

1{2  "role": "admin"3}

Requires teams:write.

JavaScript SDK: client.teams.updateMemberRole(teamId, userId, 'admin')

Invites

List workspace invites

GET /teams/{id}/invites

Returns pending invites for a workspace. Requires teams:read.

JavaScript SDK: client.teams.listInvites(teamId)

Create invite

POST /teams/{id}/invites

1{2  "email": "[email protected]",3  "role": "member"4}

Requires teams:write.

JavaScript SDK: client.teams.createInvite(teamId, { email, role })

Revoke invite

DELETE /teams/{id}/invites/{inviteId}

Requires teams:write.

JavaScript SDK: client.teams.revokeInvite(teamId, inviteId)

List my pending invites

GET /invites/me

Returns invites addressed to the authenticated user's email. Requires teams:read.

Get invite info (public)

GET /invites/info?token={token}

Returns a TeamInviteInfoDTO for the accept page. No API key required — the invite token is the credential.

Response is a TeamInviteInfoDTO:

Only 404 means the link does not work; other failures say nothing about whether the invite stands, so the workspace invite page offers try again for them.

Accept invite

POST /invites/accept

Requires authentication. Pass the invite token in the JSON body or token query parameter:

1{2  "token": "invite_token_from_email"3}

Returns the new TeamMemberDTO.

Decline invite

POST /invites/decline

Pass the same token shape. Does not require the invitee to be logged in.

Roles

Owners and admins can list and manage other members' private resources, for example after a member leaves. Pass include_private: true on cursor-list requests, or access an individual resource by ID. Both paths are audited. See REST overview: Workspace admin visibility.

Related

• REST overview: authentication and response format
• Entitlements: per-workspace plan limits
• Billing · Subscription: workspace balance and plans
• SDK overview: client.teams namespace (JavaScript)