What causes "Project package project.json is invalid." in Budibase/budibase?

Re-export the project package from a healthy workspace.

Budibase/budibase · error · HTTPError

Project package project.json is invalid.

Error message

Project package project.json is invalid.

What it means

After manifest validation, the importer validates the project.json project document itself: it must be a record with string _id and string name. This 400 error means the core project document in the package is missing or malformed, so a workspace cannot be created from it. This usually indicates package corruption or an incompatible export.

Source

Thrown at packages/server/src/sdk/workspace/projects/backups/imports.ts:690

    if (
      !isRecord(unsupported) ||
      typeof unsupported.type !== "string" ||
      !Number.isInteger(unsupported.count) ||
      Number(unsupported.count) < 0 ||
      typeof unsupported.reason !== "string"
    ) {
      throw new HTTPError("Project package manifest is invalid.", 400)
    }
  }
}

const validateProject = (project: Project) => {
  if (
    !isRecord(project) ||
    typeof project._id !== "string" ||
    typeof project.name !== "string"
  ) {
    throw new HTTPError("Project package project.json is invalid.", 400)
  }
}

const validateUsedResource = (value: unknown) => {
  return (
    isRecord(value) &&
    typeof value.id === "string" &&
    typeof value.name === "string" &&
    isAllowedImportType(value.type) &&
    ALLOWED_IMPORT_TYPES.has(value.type)
  )
}

const validateDependencyIndexShape = (
  dependencyIndex: ProjectPackageDependencyIndex
) => {
  if (
    !isRecord(dependencyIndex) ||

View on GitHub (pinned to a81a902e9a)

Solutions

Re-export the project package from a healthy workspace.
Inspect project.json inside the archive and ensure the project object has string _id and name fields.
Re-download the export to rule out transfer corruption.
Verify the archive structure matches what Budibase exports (manifest + project.json + resources).

Example fix

// before: project.json
{ "name": 123 }
// after
{ "_id": "workspace_abc123", "name": "My Project" }

Defensive patterns

Strategy: type-guard

Validate before calling

const project = JSON.parse(await readFile("project.json", "utf8"))
if (typeof project !== "object" || project === null || typeof project._id !== "string" || typeof project.name !== "string")
  throw new Error("project.json must contain a project object with string _id and name")

Type guard

const isValidProjectDoc = (p: unknown): p is { _id: string; name: string } =>
  typeof p === "object" && p !== null &&
  typeof (p as { _id?: unknown })._id === "string" &&
  typeof (p as { name?: unknown }).name === "string"

Try / catch

try {
  await importProjectPackage(file)
} catch (err) {
  if (err instanceof HTTPError && err.status === 400 && err.message.includes("project.json is invalid")) {
    // inspect project.json in the archive for missing _id/name
  }
  throw err
}

Prevention

Verify project.json exists and contains _id and name before import
Avoid renaming or repacking archive files manually
Re-export if the source project document looks damaged

When it happens

Trigger: The package's project.json lacks the project doc, or its _id/name fields are absent, null, or non-string — e.g. an archive assembled incorrectly, a truncated export, or a doc exported in an unexpected shape.

Common situations: Packages unpacked and repacked with files renamed or dropped; exports from incompatible tooling; a project whose document was corrupted before export.

Related errors

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/d5b3e52609c70ca2. Report an issue: GitHub.