{
  "error": {
    "requestId": "3f2b8c1e-5a7d-4e9b-9c2a-1d6e8f0a4b7c",
    "message": "Invalid address submitted",
    "errorCode": "invalid_wallet_address",
    "docUrl": "https://docs.rootkey.ai/api-reference/errors#invalid-wallet-address",
    "timestamp": "2024-05-19T16:24:37.884Z"
  }
}

​

HTTP Status Codes

​

Retrying a failed request

​

ROOTKey Error Codes

​

Vaults, files and records

​

invalid_wallet_address

• Status: 400
• Problem: The vault or table address in the request is not a valid address.
• Solution: Send the address exactly as ROOTKey returned it when the vault or table was created: 42 characters, 0x followed by 40 hexadecimal characters. A well-formed address that matches no vault or table in your organization gets resource_not_found instead.

​

private_key_invalid

• Status: 400
• Problem: ROOTKey could not create the vault: the private key it generated for the new vault failed its own check. Despite the message (Invalid Private Key submitted), you never send a private key to the API, so nothing in your request caused this.
• Solution: Create the vault again. If it fails again, contact [email protected] quoting the requestId. ROOTKey generates and holds the keys that sign for your vaults; see Wallet.

​

resource_not_found

• Status: 404; 403 when it is your organization’s subscription that is missing
• Problem: Something the request refers to, such as a vault, table, file, record or recovery point, does not exist in your organization. With status 403 and the message Subscription not found, ROOTKey could not find your organization’s subscription.
• Solution: Check the identifier against the resources your organization owns, for example by listing the vault’s files. For a missing subscription, check your organization’s plan in the ROOTKey app, and contact [email protected] if it is active.

​

access_policy_denied

• Status: 403
• Problem: Your organization’s IP access rules (IP Access Control in the ROOTKey app) do not allow this request. Most endpoints are checked against these rules, which judge where the request comes from, such as its IP address, network range, country or continent; a rule can apply to reads, to writes or to both. Under an allow-list policy, a request that matches no rule is refused. The message is This request is not permitted by the organization's security policy. It never says which rule matched or why, and the status alone does not tell this error from the other 403s on this page. A personal access token gets the same answer when the user is not a member of the organization in X-RootKey-Organization, so the response never confirms that an organization exists.
• Solution: Send the request from a network the policy allows, such as your servers’ usual outbound IP address, or ask an organization administrator to review the rules in the ROOTKey app. A retry from the same network is refused again.

​

geofence_blocked

• Status: 403
• Problem: You tried to download a file from a vault classified Restricted, your organization limits access to its Restricted vaults to a list of countries, and the request came from outside that list or from a location ROOTKey could not determine. The message is This Restricted vault cannot be accessed from your current location. The location is judged from the IP address the request reaches ROOTKey from, so a VPN, a proxy or a cloud region in another country counts.
• Solution: Download from a location inside the allowed list. To change the list, ask an organization administrator, or contact [email protected].

​

resource_not_active

• Status: 400
• Problem: The vault (or table) you are writing to is deactivated, so ROOTKey refused to create the file, the new version or the record. The message is This vault is not active!
• Solution: Reactivate the vault in the ROOTKey app, then send the request again. Updating a deactivated vault gets resource_deactive instead; handle both codes the same way.

​

resource_deactive

• Status: 400
• Problem: The vault you tried to update is deactivated. The message is This vault is deactive!, spelled as the API sends it. It is the same condition as resource_not_active, which the endpoints that write files and records send.
• Solution: Reactivate the vault in the ROOTKey app, then send the update again.

​

invalid_record_data

• Status: 400
• Problem: The request to create a file or a record does not carry what it creates. The message starts with Invalid record data: and says what is missing: File is required for file type when a file or a version is created without a file part, and Record data is required for record type when a record is created without recordData. The code is named after records, but it covers files too.
• Solution: For a file, send the content in the file field of the multipart form. For a record, send recordData as a JSON object; see Records for what it can hold.

​

invalid_filters

• Status: 400
• Problem: A filter on a listing has a value ROOTKey cannot use. The message is Invalid filters. Please check the input data., and the details array lists each offending parameter as a field and a message, such as startDate with Invalid ISO date. It applies to the lists of files and records (startDate, endDate and status) and to the lists of deleted vaults, files and records (deletedFrom and deletedTo).
• Solution: Correct the parameters named in details. Dates are in ISO 8601 format, and status is pending, registered or error.

​

invalid_query_parameters

• Status: 400
• Problem: A parameter of List vaults, List tables or List the organizations a token can act in has a value ROOTKey cannot use, such as a limit outside its range or an order that is not asc or desc. The details array lists each offending parameter as a field and a message; it never repeats the value you sent.
• Solution: Correct the parameters named in details, then send the request again.

​

invalid_cursor

• Status: 400
• Problem: The cursor of a listing is not one ROOTKey issued. ROOTKey refuses it instead of starting again from the first page, so a damaged cursor never makes a client read the same rows twice.
• Solution: Send the pagination.nextCursor of the previous page exactly as you received it, or leave cursor out to start from the first page. Do not build or change a cursor.

​

parent_version_not_in_vault

• Status: 400
• Problem: You asked for a new version of a file (parentId), but that file is not in the vault named by ownerVault: a version has to live in the same vault as the file it versions. ROOTKey sends the same error when no file has that id. The message starts File '<parentId>' does not belong to the vault this version is being created in.
• Solution: Send ownerVault with the address of the vault that holds the file, and check that parentId is the id of one of its files by listing the vault’s files.

​

no_promotable_version

• Status: 409
• Problem: You asked for a new version of a file that is deleted and has no live version left to attach it to, in a plain request or in a direct upload. If a deleted file still has a live version, ROOTKey attaches the new version to the oldest live one; this error means every version is deleted. The message is File '<id>' is deleted and has no live version to attach a new version to. Restore it first, then retry.
• Solution: Restore the file, from the Deleted Items page (the Restore Center) of the ROOTKey app or with PATCH /files/{fileId}/restore, then create the version again. If you no longer need the deleted file, upload the content as a new file instead.

​

waiting_for_registration

• Status: 400
• Problem: You asked to validate a file that is not registered yet. A file can be validated only once its anchor is confirmed, and this file’s status is still PENDING, or its anchoring failed and the status is FAILED. The message is File is waiting for registration! followed by Please try again later.
• Solution: Check the file’s status with Fetch file until it is REGISTERED, waiting a little longer between checks because confirmation depends on the blockchain network, then validate again. A file whose status is FAILED was never anchored and cannot be validated: send it for anchoring again from the file’s actions menu in the ROOTKey app, or upload it again.

​

invalid_ownership

• Status: 403 when you delete or restore a record; 400 when you delete or restore a file
• Problem: The vault or table named in ownerAddress does not own the file or record. The message is This vault is not the owner of this file! or This vault is not the owner of this record!
• Solution: Send ownerAddress with the address of the vault that holds the file, or of the table that holds the record. The status differs between files and records, so branch on the errorCode.

​

MISSING_ARGUMENTS

• Status: 400
• Problem: You asked for a partial recovery point without naming the vaults to include. The message is When requiring a partial recovery point, at least one vault must be defined! The code is in upper case, exactly as the API sends it, so match that spelling in your code.
• Solution: Send vaults with the addresses of the vaults to include when scope is partial, or use the global scope to include all of your organization’s vaults.

​

INVALID_TIME_RANGE

• Status: 400
• Problem: The timeRange of the recovery point is not valid: start or end is in the future, or end is earlier than start. The message is The start date must be less than the end date. The code is in upper case, exactly as the API sends it, so match that spelling in your code.
• Solution: Send a timeRange in the past, with start earlier than end. end is optional and defaults to now.

​

wallet_not_deleted

• Status: 400
• Problem: You asked to restore a vault that is not deleted. The message is Wallet <address> is not deleted!: the code and the message call a vault a wallet.
• Solution: Nothing needs restoring, because the vault is not in the trash. Treat the response as a success.

​

file_not_deleted

• Status: 400
• Problem: You asked to restore a file that is not deleted. The message is File <id> is not deleted!
• Solution: Nothing needs restoring, because the file is not in the trash. Treat the response as a success.

​

record_not_deleted

• Status: 400
• Problem: You asked to restore a record that is not deleted. The message is Record <id> is not deleted!
• Solution: Nothing needs restoring, because the record is not in the trash. Treat the response as a success.

​

vault_also_deleted

• Status: 400
• Problem: You asked to restore a file whose vault is deleted too. Restoring the file alone would leave it unreachable, so ROOTKey refuses. The message is File <id>'s owning vault is currently deleted. followed by the instruction to restore the vault first.
• Solution: Restore the vault first, from the Deleted Items page of the ROOTKey app or with PATCH /vaults/{vaultAddress}/restore, then restore the file again.

​

table_also_deleted

• Status: 400
• Problem: You asked to restore a record whose table is deleted too. Restoring the record alone would leave it unreachable, so ROOTKey refuses. The message is Record <id>'s owning table is currently deleted. followed by the instruction to restore the table first.
• Solution: Restore the table from the Deleted Items page of the ROOTKey app (an agent cannot restore a table, and the API has no endpoint for it), then restore the record again.

​

retention_deadline_expired

• Status: 400
• Problem: The vault, file or record was deleted so long ago that its retention period has run out, so ROOTKey no longer allows it to be restored, although its content may still be held. The message gives the date: This item passed its retention deadline on <date> and can no longer be restored. The lists of deleted items show each item’s purgeDeadline.
• Solution: Restore deleted items before their purgeDeadline. For an item that is already past it, an organization administrator can assign a longer retention policy to the vault or table that held it, or pause its retention, in the ROOTKey app; the item can be restored after that, as long as its content has not been removed meanwhile. See Data Retention.

​

wallet_already_purged

• Status: 410
• Problem: You asked to restore a vault that was deleted and then permanently removed once its retention period ended, so it cannot be restored. The message is Wallet <address> was already purged and cannot be restored: the code and the message call a vault a wallet.
• Solution: Nothing can bring the vault back. Create a new one if you still need it. See Data Retention for what is removed when the period ends.

​

file_already_purged

• Status: 410
• Problem: You asked to restore a file whose content was permanently removed once its retention period ended, so it cannot be restored. The message is File <id> was already purged and cannot be restored.
• Solution: Nothing can bring the file back. Upload it again as a new file if you still have it.

​

record_already_purged

• Status: 410
• Problem: You asked to restore a record whose content was permanently removed once its retention period ended, so it cannot be restored. The message is Record <id> was already purged and cannot be restored.
• Solution: Nothing can bring the record back. Create it again if you still have its data.

​

file_permanently_deleted

• Status: 410
• Problem: You asked to download a file that was deleted and then permanently removed once its retention period ended, so there is no content left to download. The message is File <id> was permanently deleted per retention policy.
• Solution: The content cannot be recovered. Upload your own copy as a new file if you still need it in ROOTKey.

​

unauthorized_access

• Status: 403 when you create a recovery point; 400 on other endpoints
• Problem: Your organization’s plan does not include a feature the request needs. For example, creating a recovery point needs Bulk Recovery, which not every plan includes. The message names your plan and the feature, and the plan that unlocks it when there is one: Your <plan> plan does not include <feature>. Upgrade to <plan> to unlock it. The error’s details object is the one described under usage_limit_exceeded, with limit and current set to null and required_plan naming the cheapest plan that includes the feature.
• Solution: Move to a plan that includes the feature: upgrade_url links to the upgrade page, and [email protected] can define a plan for your needs. Repeating the request does not help until the plan changes. Other 403 errors share this status, so branch on errorCode: access_policy_denied, for instance, depends on where the request comes from, not on your plan.

​

feature_not_found

• Status: 403 when you request an audit report; 400 on other endpoints
• Problem: The feature the request needs is not part of your organization’s plan at all. The message is Feature with key "<key>" was not found on the current plan. For an audit report the key is complianceReports: your plan does not include compliance reports. On other endpoints it means the plan has no entry for a feature ROOTKey meters, which points to how the plan was set up. When details is present, it is the object described under usage_limit_exceeded.
• Solution: For an audit report, move to a plan that includes compliance reports, or contact [email protected]. On other endpoints, contact [email protected] quoting the requestId: the plan has to be corrected, and nothing in the request needs to change.

​

usage_not_initialized

• Status: 400
• Problem: ROOTKey could not check a plan limit because your subscription has no usage counter for that feature. The message is Usage for feature "<key>" is not initialized in the subscription. This is a problem with how the subscription was set up, not with the request.
• Solution: Contact [email protected] quoting the requestId, so the subscription can be corrected. Repeating the request does not help until then.

​

usage_limit_exceeded

• Status: 400
• Problem: The request would take your organization over one of its plan’s limits, such as the number of API requests, files, records or vaults.
• Solution: The error’s details object names the limit: feature, limit, current and plan, with an upgrade_url where you can move to a larger plan. To define a plan for your needs, contact [email protected].

​

rate_limit_exceeded

• Status: 429
• Problem: The request went over a rate limit: your plan’s API rate limit, or the limit of an operation that has its own, such as listing deleted vaults, files and records and restoring them. The Retry-After header, and retryAfter in the error, give the number of seconds to wait. Unlike most errors, this response carries no docUrl.
• Solution: Wait that many seconds, then send the request again. ROOTKey refused it before doing anything, so sending it again is safe. Rate Limits has the limits and how to stay under them.

​

service_unavailable

• Status: 503
• Problem: ROOTKey is too busy to take the request for a moment. Nothing was wrong with the request. The Retry-After header, and retryAfterSeconds in the error, give the number of seconds to wait. Unlike most errors, this response carries no docUrl.
• Solution: Wait that many seconds, then send the request again, with a little random delay added so that clients refused together do not all come back together, and stop after a few attempts if your integration retries automatically. ROOTKey normally refuses the request before it has done anything, so sending it again is safe, with one exception: an upload. If the busy moment came after ROOTKey had sent the file for anchoring, the file may be anchored already, so before sending it again, check the vault as described under creation_outcome_unknown. If the 503 keeps coming back, contact [email protected], quoting the requestId when the error carries one.

​

creation_outcome_unknown

• Status: 500
• Problem: ROOTKey sent the file for anchoring but got no answer back, so it cannot tell whether the file was anchored. ROOTKey does not retry automatically: anchoring is not idempotent, and a repeat could anchor the same file twice.
• Solution: Do not simply resend the same upload, and if your integration retries 500 responses automatically, exclude this errorCode from those retries. Check whether the file is already in the vault by listing the vault’s files filtered by name (for a new version, list the file’s versions); if it is there, do not upload it again.
  A file that is not listed may still have been anchored, so before uploading it again, contact [email protected] quoting the requestId from the error response.

​

internal_error

• Status: 500, or another 5xx when a step that ROOTKey runs on your behalf, such as anchoring a file on the blockchain, fails with one
• Problem: ROOTKey could not complete the request and has no more specific code for the failure.
• Solution: Retry later, and if it keeps failing, contact [email protected] quoting the requestId. An upload that failed with a 500 may still have been anchored, so before sending it again, check the vault as described under creation_outcome_unknown. A 500 without an errorCode means the same as internal_error.

​

request_rejected

• Status: The 4xx status of the step that refused the request, usually 400
• Problem: A step that ROOTKey runs on your behalf, such as anchoring a file on the blockchain, refused the request. The message is that step’s explanation, for example Expiration date is invalid for an expirationDate that is not a date and time.
• Solution: Correct what the message describes, then send the request again. If the message gives you nothing to correct, contact [email protected] quoting the requestId.

​

Personal access tokens and agents

​

organization_header_required

• Status: 400
• Problem: A personal access token belongs to a user, not to an organization, so every request that works inside an organization has to say which one. The request carried no X-RootKey-Organization header. The message is Send the organization this request acts for in the X-RootKey-Organization header.
• Solution: Send the id of the organization in the X-RootKey-Organization header. List the organizations a token can act in to see the ids. The header is the only place the organization is read from: a query string or a body field does not count.

​

conflicting_credentials

• Status: 400
• Problem: The request carried both an x-api-key header and an Authorization: Bearer rk_... token. ROOTKey refuses it without saying whether either one is valid.
• Solution: Send one credential per request: either the x-api-key header or the bearer token.

​

email_verification_required

• Status: 403
• Problem: The email address of the user the token acts as has not been verified, and the time allowed to verify it has run out. The message is Verify your email address to continue using the platform.
• Solution: Verify the email address with the message ROOTKey sent when the account was created.

​

agent_org_not_allowed

• Status: 403
• Problem: The token was created for specific organizations, and the organization in X-RootKey-Organization is not one of them. The message is This token is not allowed to act in this organization.
• Solution: Send the id of an organization the token covers (GET /me lists them), or create a new token that includes this organization or all of your organizations.

​

agent_user_blocked

• Status: 403
• Problem: An administrator of the organization blocked this user from using agents there. The user’s own access in the ROOTKey app is not affected. GET /organizations shows blocked: true for it.
• Solution: Ask an administrator of the organization to unblock your agents in the organization’s AI agents settings.

​

agent_two_factor_required

• Status: 403
• Problem: The organization requires two-factor authentication of the members who use agents, and the user has not turned it on.
• Solution: Turn on two-factor authentication in your account security settings in the ROOTKey app, then send the request again.

​

agent_access_disabled

• Status: 403
• Problem: The organization turned agent access off, so it serves no personal access token request, whoever the user is. GET /organizations shows mode: DISABLED for it.
• Solution: Ask an administrator of the organization to change the access mode in the AI agents settings. Until then, use the ROOTKey app, or an organization API key if your organization issues them.

​

agent_write_not_allowed

• Status: 403
• Problem: The organization lets agents read only, which is the setting until an administrator chooses another, and the request creates, changes or deletes something. GET /organizations shows mode: READ_ONLY for it.
• Solution: Ask an administrator of the organization to allow full access for agents in the AI agents settings. Reads keep working in the meantime.

​

agent_personal_tokens_disabled

• Status: 403
• Problem: The organization does not allow personal access tokens, so a token cannot act in it.
• Solution: Ask an administrator of the organization to allow personal access tokens in the AI agents settings.

​

agent_client_not_allowed

• Status: 403
• Problem: The organization allows only certain apps to act in it, and the app that made the request, one a member connected through the hosted connector, is not on its list. The message is This app is not allowed to act in this organization. Personal access tokens are not affected by the list of allowed apps.
• Solution: Ask an administrator of the organization to add the app under Organization Settings → AI agents → Allowed apps, or to allow any app. The app’s connection is not removed, and it works in the organization again once it is allowed. Do not retry the request, and do not try the same request in another organization on your own.

​

agent_approval_required

• Status: 403
• Problem: The organization asks the member to approve every delete an agent makes (Delete approval), and the request deletes a file or a vault. Nothing was deleted. The error carries the actionId of the request, the status PENDING and expiresAt: the request stays open for 24 hours.
• Solution: Tell the member. They approve it in the ROOTKey app under Pending approvals, with a fresh two-factor check. Then send the same request again: it runs once, and the approval can be used for about 10 minutes. Sending it again while it waits answers the same request. Wait for the member, and do not retry in a loop. See Delete approvals.

​

agent_approval_denied

• Status: 403
• Problem: The member denied the request to delete. Nothing was deleted. The error carries the same actionId and the status DENIED.
• Solution: Do not send the delete again. Tell the member that it was denied and ask what they want to do.

​

agent_approval_limit_reached

• Status: 403
• Problem: Too many delete requests of this member are waiting for approval, so a new one cannot be opened.
• Solution: Ask the member to approve or deny the requests that are waiting under Pending approvals in the ROOTKey app, then try again.

​

insufficient_scope

• Status: 403
• Problem: The token does not carry the scope the endpoint needs: rootkey.read to read, rootkey.write to create or change, rootkey.delete to delete. The message is This token does not carry the scope this endpoint needs.
• Solution: Create a new personal access token that carries the scope. A token’s scopes are fixed when it is created. GET /me lists the scopes of the token you are using.

​

insufficient_permission

• Status: 403
• Problem: The user’s role in the organization does not grant what the request does. A personal access token never has more access than its user has in the ROOTKey app. The message is Your organization role does not grant permission to perform this action.
• Solution: Ask an administrator of the organization to change the user’s role, or use an account whose role allows it.

​

agent_restricted_data_denied

• Status: 403
• Problem: The vault or table is classified Restricted, and the organization does not let an agent reach it. With the option that lets members open Restricted data to their own agents turned off, which is the default, no agent reaches Restricted data, in any mode. With it turned on, a read or a write needs the member’s approval (agent_step_up_required), but deleting and restoring Restricted data, or anything in it, is always refused, even with an approval. The listings still show Restricted vaults and tables, with agentAccessible: false, so that an agent can tell the user they exist.
• Solution: Open it in the ROOTKey app. If the organization allows approvals, ask the member to approve access to the vault or table, as described under agent_step_up_required.

​

agent_step_up_required

• Status: 403
• Problem: The vault or table is classified Restricted, and the organization lets members open Restricted data to their own agents. The request reads or writes it without an approval.
• Solution: Call POST /agent-step-ups with the vault or table address, give the url it returns to the member, and wait for them to approve it with a fresh two-factor check. Then check the request once with GET /agent-step-ups/{stepUpId} and send the request again. See Restricted data and agents.

​

agent_step_up_not_required

• Status: 400
• Problem: You asked for an approval for a vault or table that is not Restricted, so it needs none.
• Solution: Send the request you meant to make, without asking for an approval.

​

agent_step_up_limit_reached

• Status: 403
• Problem: Too many approval requests of this connection are waiting for the member.
• Solution: Wait for the member to answer the requests that are open, or for them to expire, then ask again.

​

invalid_agent_step_up_request

• Status: 400
• Problem: The body of the approval request has no usable vaultAddress.
• Solution: Send the address of the vault or table in vaultAddress, in the body.

​

conflicting_request_identifiers

• Status: 400
• Problem: The same identifier, such as a vault address or an id, was given different values in the query and in the body of the request. The error lists the fields in conflict.
• Solution: Give each identifier once, in the place the endpoint documents.

​

agent_classification_change_not_allowed

• Status: 403
• Problem: A request to update a vault carried a dataClassification and came from a personal access token. How a vault’s data is treated stays with a person, so the request is refused even for the value the vault already has, and nothing else in it is applied.
• Solution: Change the classification in the ROOTKey app, or send the update without dataClassification.

​

agent_route_not_available

• Status: 403
• Problem: The endpoint is never available to a personal access token, whatever the organization allows. Deleting a record, and fetching, downloading, creating or deleting a recovery point, are in this group. An agent can list recovery points, list and restore what is in the trash, queue a file audit report and list its open direct uploads. The message is This endpoint is not available to agents.
• Solution: Use the ROOTKey app, or an organization API key, for these.

​

Direct file uploads

​

file_too_large

• Status: 413
• Problem: The file is larger than a direct upload accepts: 5 GiB.
• Solution: Nothing was created. A file this large cannot be uploaded through the API; split it into smaller files if your use case allows it, or contact [email protected].

​

too_many_open_file_uploads

• Status: 429
• Problem: Your organization already has the most uploads open at once: 10,000. This is not a plan limit, and starting an upload consumes nothing.
• Solution: Nothing was created. List the open uploads and complete or abort the ones that are no longer needed, or wait for them to expire, then start the upload again.

​

too_many_open_file_upload_bytes

• Status: 429
• Problem: The uploads your organization has open already hold the bytes it may have in flight, so this file would not fit beside them. The limit is 128 GiB, or what your plan’s storage has left if that is less. Your plan refusing the file by itself is usage_limit_exceeded instead.
• Solution: Nothing was created. Complete or abort open uploads, or wait for them to expire, then start the upload again. The metadata.organization block of List open uploads shows what is open.

​

file_upload_not_found

• Status: 404
• Problem: No upload with that uploadId exists in your organization. An upload that belongs to another organization gets the same answer.
• Solution: Check the uploadId against the one Start an upload returned. Finished uploads are removed after a few days, so an old uploadId may no longer exist.

​

file_upload_expired

• Status: 410
• Problem: The upload was not completed before it expired.
• Solution: Start a new upload. What was uploaded for the expired one is deleted.

​

file_upload_incomplete

• Status: 409
• Problem: You completed the upload before all of its bytes were stored: nothing was uploaded yet, or some parts are missing.
• Solution: Send the missing bytes, using the signed URL (or the part URLs) with exactly the headers returned, then complete the upload again.

​

file_upload_finalizing

• Status: 409
• Problem: The upload is already being completed, by an earlier call that is still running or that did not return an answer. ROOTKey does not anchor it a second time, because a repeat could anchor the same file twice.
• Solution: Get the upload’s status and try again later. Once the upload is COMPLETED, completing it answers with its file.

​

file_upload_not_open

• Status: 409
• Problem: The upload is in a state that the request does not apply to: it is finished, failed, expired or aborted, or, for an abort, it is already being completed.
• Solution: Get the upload’s status. For FAILED, its failureCode says why. Start a new upload if you still need the file.

​

file_upload_checksum_mismatch

• Status: 422 when you complete a single upload; for a multipart upload it is the failureCode of the upload when it is FAILED
• Problem: What was stored does not hash to the SHA-256 you declared, for example because the file changed after you hashed it, or a part was corrupted on the way. The upload fails and what was stored is deleted. Nothing was anchored.
• Solution: Hash the file again and start a new upload.

​

file_upload_size_mismatch

• Status: 422
• Problem: What was stored is not as long as the size you declared. The upload fails and what was stored is deleted. Nothing was anchored.
• Solution: Start a new upload, declaring the file’s exact size in bytes.

​

file_upload_not_multipart

• Status: 400
• Problem: You asked for part URLs for an upload whose mode is single, which has no parts.
• Solution: Send the file with one PUT to the upload.url that Start an upload returned.

​

file_upload_part_out_of_range

• Status: 400
• Problem: A partNumber is outside the upload’s plan: it is below 1, or above the partCount that Start an upload returned.
• Solution: Ask only for part numbers from 1 to partCount.

​

file_upload_part_checksum_required

• Status: 400
• Problem: The storage checks each part against its SHA-256 as it arrives, and the request did not name one for a part.
• Solution: Send the sha256 of every part, as 64 hexadecimal characters. Sending it is always allowed, so a client that always does works on every deployment.

​

file_upload_vault_paused

• Status: none: it is the failureCode of a multipart upload that is FAILED
• Problem: The upload was completed, but the vault stayed paused for the whole time that ROOTKey waits for it to become active. The upload was discarded.
• Solution: Make sure the vault is active, then start a new upload.

​

presigned_file_upload_disabled

• Status: 404
• Problem: Direct uploads are not available on this deployment.
• Solution: Upload the file with Create file instead.

​

legacy_file_upload_disabled

• Status: 410
• Problem: Create file and Create file version, which send the file in the request itself, are turned off on this deployment.
• Solution: Upload the file with a direct upload.

​

Accounts and shared links

​

invalid_email

• Status: 400
• Problem: The email address is not valid.
• Solution: Check that the address is properly formatted, is at most 200 characters long, and only uses allowed characters.

​

inactive_account

• Status: 400
• Problem: The account’s email address has not been verified, so ROOTKey refused the sign-in.
• Solution: Verify the email address using the verification email ROOTKey sent when the account was created, then sign in again.

​

invalid_credentials

• Status: 400
• Problem: The email address or the password is incorrect.
• Solution: Sign in with the email address and password of an existing ROOTKey account.

​

invalid_password

• Status: 400
• Problem: The shareable link is protected by a password, and the request carried no password or the wrong one.
• Solution: Ask whoever shared the link for its password, then open the link again and enter it.