API reference · Hubtask API 0.1.0
ai
GET /ai-provider
The workspace's AI provider, and whether it may be used
Which provider this workspace would ask, under which models, and whether AI processing is allowed here at all. Needs the permission that manages structure, or the auditor's read-only configuration permission: where a workspace's content may be sent is exactly what an auditor reads. The API key is never a member of this answer. It is sealed at configuration time and opened only by the adapter that makes the call.
Responses
200The configuration AiProvider4XXAn error per RFC 9457 Problem
curl -X GET "$HUBTASK_URL/ai-provider" \ -H "Authorization: Bearer $HUBTASK_TOKEN" PUT /ai-provider
Configure the workspace's AI provider
Sets the provider whole - the kind, the endpoint, the models, the jurisdiction it operates in, the key, and whether AI processing is allowed here. A provider whose jurisdiction is THIRD_COUNTRY is refused unless the operator of this installation has confirmed third-country transfers (HUBTASK_AI_ALLOW_THIRD_COUNTRY_TRANSFER). The confirmation is the installation's rather than the workspace's on purpose: it is the operator who signs the processing agreement and who owes the transfer impact assessment, and a workspace administrator cannot take that on for them. Refused as 403 forbidden, detail code ai.third_country_not_confirmed. The key is sealed on the way in and appears in no answer afterwards. Auditable - the entry names the provider, the jurisdiction and the models, and never the key.
Request body application/json — AiProviderConfiguration
Responses
200Configured AiProvider4XXAn error per RFC 9457 Problem
Codes this operation names
curl -X PUT "$HUBTASK_URL/ai-provider" \ -H "Authorization: Bearer $HUBTASK_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "kind": "NOOP", "base_url": "https://example.org", "completion_model": "string", "embedding_model": "string", "api_key": "string", "jurisdiction": "SELF_HOSTED", "processing_allowed": false}' DELETE /ai-provider
Remove the workspace's AI provider
The configuration and its sealed key go, and the workspace is back to the installation's default, which calls nothing. Nothing else is affected: no suggestion already accepted is undone, because accepting one was a person's own write. Auditable.
Responses
204Removed4XXAn error per RFC 9457 Problem
curl -X DELETE "$HUBTASK_URL/ai-provider" \ -H "Authorization: Bearer $HUBTASK_TOKEN" GET /ai-source
Which AI answers this workspace, and what it may use
The workspace's own model, a model the installation offers, or none - with what the installation allows, whether that is locked and by whom, and the least a workspace's own model must declare. An offered model is answered by its name, its processor and its jurisdiction only. With nothing offered and nothing decided, sources is OWN and offered is empty: the workspace's own model, as always.
curl -X GET "$HUBTASK_URL/ai-source" \ -H "Authorization: Bearer $HUBTASK_TOKEN" PUT /ai-source
Choose which AI answers this workspace
Choosing an offered model is this workspace's consent to send its content to it, and choosing its own model or none withdraws that consent. NONE is always allowed; a source the installation does not allow is refused with 403, ai.source_not_allowed. A narrowing wider than the installation allows is refused with auth.policy_loosens, one under a lock with auth.policy_locked - except NONE, which is the workspace's own always. Auditable.
Request body application/json — AiSourceChoice
Codes this operation names
curl -X PUT "$HUBTASK_URL/ai-source" \ -H "Authorization: Bearer $HUBTASK_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "source": "OWN", "offered_model_id": "018f6e2a-2b7c-7c1e-9b1a-3d5e6f7a8b9c", "sources": "NONE"}' PUT /ai-person-opt-out
Whether each person may keep their own content out of AI
OFFERED, the default, lets each person keep what they authored out of every prompt. NOT_OFFERED makes AI part of everybody's work: it needs a legal basis that does not rest on each person's agreement - EMPLOYMENT_CONTRACT, WORKS_AGREEMENT or LEGAL_OBLIGATION - and is refused without one (ai.opt_out_basis_required). People then see the basis and whom to ask instead of the switch; an objection recorded earlier stops taking effect, and each person it affects is told once. Where the installation or a plan holds the workspace at OFFERED, NOT_OFFERED is refused with auth.policy_locked. Going back to OFFERED is always allowed. Auditable.
Request body application/json — AiPersonOptOutChoice
Codes this operation names
curl -X PUT "$HUBTASK_URL/ai-person-opt-out" \ -H "Authorization: Bearer $HUBTASK_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "person_opt_out": "OFFERED", "basis": "EMPLOYMENT_CONTRACT", "contact": "string"}' PUT /ai-budget
Set the daily budget of this workspace's own AI model
How many tokens a day this workspace's own model may spend, counted in the workspace's own time zone; null lets it spend without a budget, the default. The installation's budget (ai_tokens_per_day) bounds only the models the installation offers - this one is the workspace's alone. A number below 1 is refused with 422, ai.budget_invalid. Answers the two AI rows of the workspace's quota standing, offered and own. Auditable.
Request body application/json — OwnAiBudget
Responses
200The two AI standings after the write4XXAn error per RFC 9457 Problem
Codes this operation names
curl -X PUT "$HUBTASK_URL/ai-budget" \ -H "Authorization: Bearer $HUBTASK_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "own_tokens_per_day": 1}'