Budibase/budibase · error · HTTPError

Unsupported Project package format version '${manifest.forma

Error message

Unsupported Project package format version '${manifest.formatVersion}'.

What it means

Project packages are versioned by manifest.formatVersion, which must exactly equal the server's PROJECT_EXPORT_FORMAT_VERSION constant. This 400 error is thrown when the version differs, protecting the importer from format changes it cannot safely parse. Both older and newer package formats are rejected.

Source

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

    case ResourceType.SCREEN:
      return generateScreenID()
    default:
      throw new HTTPError(
        `Project import does not support resource type '${resourceType}'.`,
        400
      )
  }
}

const validateManifest = (manifest: ProjectPackageManifest) => {
  if (!isRecord(manifest)) {
    throw new HTTPError("Project package manifest is invalid.", 400)
  }
  if (manifest.artifactType !== "project") {
    throw new HTTPError("Supplied file is not a Project package.", 400)
  }
  if (manifest.formatVersion !== PROJECT_EXPORT_FORMAT_VERSION) {
    throw new HTTPError(
      `Unsupported Project package format version '${manifest.formatVersion}'.`,
      400
    )
  }
  if (
    !isRecord(manifest.sourceWorkspace) ||
    typeof manifest.sourceWorkspace.id !== "string" ||
    !isRecord(manifest.resourcesByType) ||
    !Array.isArray(manifest.unsupportedContent)
  ) {
    throw new HTTPError("Project package manifest is invalid.", 400)
  }
  for (const count of Object.values(manifest.resourcesByType)) {
    if (!Number.isInteger(count) || Number(count) < 0) {
      throw new HTTPError("Project package manifest is invalid.", 400)
    }
  }
  for (const unsupported of manifest.unsupportedContent) {

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Upgrade the server to match the formatVersion used by the exporting version.
  2. Re-export the project from a workspace running a compatible version.
  3. Check the exported formatVersion against the server's PROJECT_EXPORT_FORMAT_VERSION constant.
  4. If hand-authoring packages, set formatVersion to the exact constant value the server expects.

Example fix

// before
{ "artifactType": "project", "formatVersion": 99 }
// after (matching PROJECT_EXPORT_FORMAT_VERSION)
{ "artifactType": "project", "formatVersion": 1 }
Defensive patterns

Strategy: validation

Validate before calling

if (manifest.formatVersion !== PROJECT_EXPORT_FORMAT_VERSION)
  throw new Error(`Package formatVersion ${manifest.formatVersion} != supported ${PROJECT_EXPORT_FORMAT_VERSION}`)

Try / catch

try {
  await importProjectPackage(file)
} catch (err) {
  if (err instanceof HTTPError && err.status === 400 && err.message.includes("format version")) {
    // upgrade server or re-export from a compatible version
  }
  throw err
}

Prevention

When it happens

Trigger: Importing a package exported by a newer Budibase version with a bumped formatVersion; importing a very old export whose formatVersion predates the current constant; a package whose formatVersion field is missing or mis-typed.

Common situations: Server rollback then import of recent exports; packages generated by third-party tools guessing the version; partially deployed clusters where server versions differ.

Related errors


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