> ## Documentation Index
> Fetch the complete documentation index at: https://docs.everabyte.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Partner integration

> How to build against a partner-managed Everabyte account, and which boundaries are enforced server-side.

If your product embeds Everabyte storage and your customers are managed through a partner relationship, this page covers the parts that differ from a direct account.

## What a partner-managed account is

A partner arrangement is contractual. Everabyte provisions the partner and the associated instances; there is no self-service partner signup, partner onboarding flow, or partner pricing page.

End customers of a partner:

* do not purchase Everabyte add-ons directly,
* are billed through the partner,
* still use the same storage API contract described in this documentation.

## Enforced boundaries

These are not UI conventions. They are enforced by the backend, and building around them will fail.

| Boundary | Effect |
| - | - |
| No self-service partner creation | Partner records are created by Everabyte only |
| Customer purchases restricted | A partner-managed customer cannot buy direct add-ons |
| Client-supplied partner identifiers ignored | Association is written by the backend, never taken from a request body |
| Remote instances are not independent | A partner or white-label instance applies configuration from Everabyte and is not administratively standalone |
| Per-instance credentials | Each instance has its own credential; there is no shared global token |

> [!WARNING]
>
> Do not attempt to set a partner identifier, create a partner record, or bypass the partner billing relationship through the API. Those paths are closed by design, and attempting to work around them is a support escalation, not an integration task.

## What you can build

The integration surface for a partner-managed account is the storage API:

| Capability | Available |
| - | - |
| Lists, uploads, downloads, moves, copies, deletes | Yes |
| Folder hierarchy and metadata | Yes |
| Version history, restore, retention | Yes, within plan |
| Bucket metadata and size reads | Yes |
| Bucket creation | Through the dashboard, not the API |
| Sharing and permission management | Dashboard only |
| Billing and plan changes | Through the partner |
| Tenant or instance administration | Not published |

## Credentials

The credential model is unchanged:

* `X-Public-Key` and `X-Secret-Key` per key.
* Scopes and optional bucket restriction.
* Keys created in the dashboard by a user with the right permissions and step-up authentication.

Per-instance credentials apply to the infrastructure that runs the deployment. They are not developer API credentials and must never be embedded in a customer-facing application.

## Multi-tenant design guidance

When one integration serves many end customers:

1. **Isolate by company workspace.** Do not share one workspace across unrelated customers.
2. **One key per tenant, restricted to that tenant's buckets.** This makes a leak containable.
3. **Never accept a bucket ID from an untrusted client without authorization.** Verify the bucket belongs to the tenant on your side before calling the API.
4. **Store the mapping** from your tenant identifier to bucket IDs in your own database. Do not derive it from user input at request time.
5. **Log key prefixes, not secrets.**

Even though Everabyte enforces bucket restriction, your application is the first line of defense for cross-tenant authorization. Treat a request for another tenant's `bucketId` as an authorization failure in your own code.

## Failure modes to expect

| Situation | Response |
| - | - |
| Attempting a direct add-on purchase for a partner customer | Rejected |
| Client-supplied partner identifier | Ignored or rejected; association is backend-controlled |
| Using a shared token across instances | Not supported |
| Requesting unpublished administrative routes | `403 API_KEY_SURFACE_DENIED` or not routable |

## Support path

Partner issues go through your partner contact first. Everabyte support is available for API behavior questions and can be reached at [support@everabyte.com](mailto:support@everabyte.com).

When escalating, include:

* the company workspace involved (not credentials),
* the request path and approximate timestamp,
* the full response envelope,
* the key prefix, never the secret.

## Related

> **[Enterprise overview](https://docs.everabyte.com/enterprise/overview.md)**
>
> Direct versus partner-managed accounts.

> **[Access control](https://docs.everabyte.com/security/access-control.md)**
>
> Scopes and bucket ceilings.

> **[Conventions](https://docs.everabyte.com/api-reference/conventions.md)**
>
> Request and response shapes.

> **[Troubleshooting](https://docs.everabyte.com/errors/troubleshooting.md)**
>
> Diagnosing failures.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.