Migration guide

This page covers two different migrations. Read the section that applies to you.

​

Part 1 — Migrating from the previous API documentation

This site replaces the earlier API documentation. Some URLs have changed.

​

Redirected paths

Redirects are served by the platform, so existing bookmarks continue to resolve.

​

What changed in substance

The previous documentation included content that did not match the backend. This site publishes only endpoints verified against route registration and controller behavior.

​

If a page you used is gone

It was likely one of:

• an endpoint not reachable with API keys,
• an administrative or provisioning route,
• a capability that is gated or unstable.

Check the API reference index, or contact support@everabyte.com.

​

Updating code

The mechanical changes most integrations need:

1. Base URL: https://api.everabyte.io/api.
2. Auth headers: X-Public-Key and X-Secret-Key.
3. Error handling: read code when present, but do not require it. Controller errors may omit it.
4. Delete response: a successful file delete returns data: "".
5. Version responses: check data.status inside a 200 response.
6. Uploads: for multiple files, list the folder afterward; the response describes only the first file.
7. Retries: never retry 403, 402, or 401. Retry 429 and 5xx with backoff.

​

Part 2 — Migrating from another storage provider

​

1. Inventory

Before moving anything:

• count objects and total bytes,
• record average and maximum object size,
• list folders (directory structure does not always map one-to-one),
• identify objects with versions you must preserve,
• identify retention obligations,
• check for empty directories you still need.

​

2. Map the structure

​

3. Plan the transfer

1. Create target buckets in the required locations.
2. Create a key per migration job, restricted to the target buckets.
3. Copy in batches small enough to verify.
4. After each batch, list the folder and compare counts and sizes.
5. Record fileId and versionId in a mapping table if downstream systems reference them.
6. Keep the source untouched until verification passes.

​

4. Preserve what matters

​

5. Cut over

1. Stop writes on the source.
2. Run a final incremental transfer.
3. Verify counts and critical objects.
4. Switch reads to Everabyte.
5. Keep the source read-only for a defined rollback window.
6. Retire the source only after your own verification passes.

​

6. Common mistakes

• Assuming a successful upload response means the whole batch succeeded. It may describe only the first file.
• Assuming folders transfer automatically. They do not; create the structure.
• Assuming versions transfer. They do not.
• Testing only small files. Test your largest expected object too.
• Leaving the source writable during cutover.

​

Related