Manage repositories

mka1-repos is the platform’s repository service for model weights and datasets. Every repository is an ordinary git repository with Git LFS, owned by exactly one organization and identified by the pair <org>/<name> — for example meetkai/functionary. That identifier is the whole point. You push artifacts to the repository from your machine over git, and Compute workloads resolve the same <org>/<name> through the platform’s Hugging Face-compatible artifact endpoint to train on or serve them. This guide covers both halves: the management API for creating, listing, renaming and deleting repositories, and the two client tools — git and the Hugging Face CLI — that move bytes in and out.

Before you start

You need:

Requirement	Notes
API key	Send it as `Authorization: Bearer <mka1-api-key>` on every request.
Org owner or admin role	Every repository endpoint is restricted to owners and admins of the organization. There are no per-repository permissions; access is decided by your org role alone.
`git` and `git-lfs`	Model weights are large binaries; the git host stores them through Git LFS, so install and initialize `git lfs` before the first push.

Repositories always belong to the caller’s organization. You never choose the org at create time — it is derived from your API key — and you cannot reach another organization’s repositories at all.

Create a repository

Pick a name and optionally a description. The name must start with a letter or digit and be at most 100 characters of letters, digits, dots, underscores, and dashes (^[A-Za-z0-9][A-Za-z0-9._-]{0,99}$).

import { SDK } from '@meetkai/mka1';

const sdk = new SDK({
  bearerAuth: 'Bearer <mka1-api-key>',
});

const repo = await sdk.repos.create({
  createRepoRequest: {
    name: 'functionary',
    description: 'Fine-tuned weights for the MeetKai assistant.',
  },
});
console.log(repo.org, repo.name, repo.id);

curl https://apigw.mka1.com/api/v1/repos \
  --request POST \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --data '{
    "name": "functionary",
    "description": "Fine-tuned weights for the MeetKai assistant."
  }'

The response is 201 with the repository:

{
  "id": "rqz4h6k2m5n7p9r3t5v7w9x2",
  "org": "meetkai",
  "name": "functionary",
  "description": "Fine-tuned weights for the MeetKai assistant.",
  "created_at": "2026-07-30T09:15:00Z"
}

id is an opaque, stable identifier — the canonical key that survives renames. org and name are the user-facing labels that form the repository reference and its URLs. Creation provisions the backing git repository as part of the request. If that provisioning fails, the create returns 502 provision_failed and nothing is kept, so it is safe to retry. The request body rejects unknown fields, and a name that is already taken in your org returns 409.

The repository reference and git URL

Two values identify a repository everywhere else on the platform:

Value	Shape	Used for
Repository reference	`<org>/<name>`, e.g. `meetkai/functionary`	Hugging Face-compatible resolution inside Compute workloads, and tools like ms-swift and vLLM.
Git URL	`https://git.mka1.com/<org>/<name>.git`	`git clone`, `git push`, and Git LFS transfers from your own machines.

The git host authenticates with HTTP basic auth: the username must be your org slug and the password is an MKA1 API key. org:apikey is enforced — a username that does not match the organization is rejected. Both values are what you hand to a Compute workload as environment variables — see Run a fine-tune job and Deploy a model server.

List repositories

Returns every repository in your organization.

const { repos } = await sdk.repos.list({});
for (const repo of repos) {
  console.log(`${repo.org}/${repo.name}`, repo.description);
}

curl https://apigw.mka1.com/api/v1/repos \
  --header 'Authorization: Bearer <mka1-api-key>'

{
  "repos": [
    {
      "id": "rqz4h6k2m5n7p9r3t5v7w9x2",
      "org": "meetkai",
      "name": "functionary",
      "description": "Fine-tuned weights for the MeetKai assistant.",
      "created_at": "2026-07-30T09:15:00Z"
    },
    {
      "id": "rb8s2d4f6h8j1l3n5q7s9v2x",
      "org": "meetkai",
      "name": "support-conversations",
      "description": "Curated support transcripts for fine-tuning.",
      "created_at": "2026-07-28T16:40:00Z"
    }
  ]
}

Get a repository

Read a single repository by its reference.

const repo = await sdk.repos.get({
  org: 'meetkai',
  name: 'functionary',
});
console.log(repo.description);

curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \
  --header 'Authorization: Bearer <mka1-api-key>'

A repository that does not exist in your org returns 404 — including any repository that belongs to a different org.

Rename or update a repository

Updates are label-only: you can change name and description, and an omitted field is left unchanged.

const repo = await sdk.repos.update({
  org: 'meetkai',
  name: 'functionary',
  patchRepoRequest: {
    name: 'functionary-v2',
  },
});
console.log(repo.name);

curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \
  --request PATCH \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --data '{"name": "functionary-v2"}'

The repository id is stable, so a rename is a metadata update — the git history and stored artifacts are untouched. Renaming to a name that already exists in your org returns 409.

A rename changes the repository reference and the git URL.The old <org>/<name> stops resolving immediately. Update every git remote, every REPO/REPO_URL environment value in Compute create bodies, and every training or serving script that referenced the old name.

Delete a repository

await sdk.repos.delete({
  org: 'meetkai',
  name: 'functionary',
});

curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \
  --request DELETE \
  --header 'Authorization: Bearer <mka1-api-key>'

The response is 204 with no body. The repository record is removed immediately — that delete is authoritative — while teardown of the backing git storage is best-effort cleanup. A repeated delete of the same reference returns 404.

Deleting a repository removes the repository, its git history, and every stored artifact. This cannot be undone — there is no soft delete and no recovery window.

Push and pull with git

Clone the repository, or add it as a remote of an existing local repository:

git clone https://git.mka1.com/meetkai/functionary-train-data.git
cd support-conversations

# In an existing local repository instead:
git remote add mka1 https://git.mka1.com/meetkai/functionary-train-data.git

Track large binaries with Git LFS before committing them. Weight files must go through LFS; small text files such as configs, tokenizer definitions, and JSONL datasets can stay in plain git.

git lfs install
git lfs track "*.safetensors" "*.bin" "*.gguf"
git add .gitattributes

Then commit and push as usual:

git add .
git commit -m "Add curated support transcripts"
git push origin main   # or: git push mka1 main

Git authenticates the push with HTTP basic auth. The username must be your org slug and the password is an MKA1 API key — org:apikey is enforced, so a username that does not match the organization is rejected:

Username for 'https://git.mka1.com': meetkai
Password for 'https://meetkai@git.mka1.com': <mka1-api-key>

For non-interactive pushes (CI, a training box), export the API key as MK_API_KEY in the environment (for example from a CI secret) and supply it through a git credential helper, instead of embedding the key in the remote URL, where it would be written to .git/config:

git config credential.helper '!f() { echo "username=meetkai"; echo "password=$MK_API_KEY"; }; f'

Lay out the repository however your training or serving stack expects. The examples in this guide use two repositories: meetkai/functionary-train-data, a dataset repository holding JSONL transcripts, and meetkai/functionary, a weights repository in the usual Hugging Face layout (config.json, tokenizer files, *.safetensors).

Push and pull with the Hugging Face CLI

The same repository is reachable over the Hugging Face Hub API. Two environment variables are all the configuration there is — HF_ENDPOINT for where, HF_TOKEN for who:

export HF_ENDPOINT=https://hf.mka1.com
export HF_TOKEN=<mka1-api-key>

With those set, the ordinary Hugging Face commands operate on your repositories instead of the public hub:

hf download meetkai/functionary --local-dir ./base
hf download meetkai/functionary-train-data --repo-type dataset --local-dir ./data
hf upload meetkai/functionary ./merged .

The same two variables work from Python, because huggingface_hub reads them by name:

from huggingface_hub import snapshot_download

path = snapshot_download(repo_id="meetkai/functionary")

hf is the current CLI; older environments ship the same commands as huggingface-cli. Unlike git, this path does not need your org slug as a username — the token carries the identity.

This is the part that carries over to Compute. A training or serving container sets the same two variables, and ms-swift or vLLM resolves <org>/<name> with no code changes — see Run a fine-tune job and Deploy a model server.

Errors

Repository endpoints return a uniform envelope with a stable machine-readable code and the request’s correlation id:

{
  "error": "not_found",
  "correlation_id": "c0a8f3d2-4b6e-4f1a-9c7d-2e5b8a1f6d3c"
}

Status	Code	Meaning
`400`	`invalid_name`, `invalid_body`	A name that violates the pattern, or a malformed body or unknown field (bodies reject unknown properties).
`401`	`unauthorized`	Missing or incomplete org-scoped identity on the request.
`403`	`forbidden`	The caller is not an owner or admin of the organization.
`404`	`not_found`	No such repository in your org — a repository in another org is reported as `404`, never `403`, so existence never leaks.
`409`	`name_taken`	The name is already taken in your org (create or rename).
`500`	`internal`	An unexpected server-side error.
`502`	`provision_failed`	The backing git repository could not be created; the repository was not kept, so retry the create.
`503`	`org_unresolved`	The gateway could not resolve your organization; retry, and contact support if it persists.

API reference

For the full request and response schemas, open the Repositories groups in the API Reference.

Getting started

Responses

Features

Compute

CLI

Recipes

Benchmarks

Infrastructure

Manage repositories

Before you start

Create a repository

The repository reference and git URL

List repositories

Get a repository

Rename or update a repository

Delete a repository

Push and pull with git

Push and pull with the Hugging Face CLI

Errors

API reference

See also

​Before you start

​Create a repository

​The repository reference and git URL

​List repositories

​Get a repository

​Rename or update a repository

​Delete a repository

​Push and pull with git

​Push and pull with the Hugging Face CLI

​Errors

​API reference

​See also

Before you start

Create a repository

The repository reference and git URL

List repositories

Get a repository

Rename or update a repository

Delete a repository

Push and pull with git

Push and pull with the Hugging Face CLI

Errors

API reference

See also