Skip to main content
A resource you add on the Worker tab — a key-value store, SQL database, object storage, queue or stateful object class — belongs to the API that created it. Sharing lets other APIs bind the same resource, so two listings can use one store or one pool of stateful objects instead of copying it or calling each other through the gateway.
Sharing is for APIs served by the edge gateway (the Worker tab). Everything happens in the Studio under Worker → Bindings, or through the Management API.

​
How it works

  • Grants are per API. You share one resource with one API at a time. Another API of the same account gets nothing automatically, and each grant can be revoked on its own.
  • Your own APIs: pick the API and a binding name; the resource is bound into it right away and that API gets a new deployment.
  • Another account’s API: type its API slug. The other account sees an invitation at the top of that API’s Bindings and accepts or declines it; after accepting, it binds the resource under a name of its own choice. There is no email: invitations live in the Studio only.
  • What each side sees. The other API sees your API’s name, your account name, the resource’s kind and name (and the class name of a stateful object) — never your variables, other resources or code. You see which APIs use the resource.

​
What the other API can do

Stateful objects: whoever binds a class can call every public method of it. Share a class whose public methods are exactly what the other API may do, and keep management methods in a class you do not share. For example, a class BasicSerp whose only method is serve(params) can use a private SessionPool class inside; the pool itself (add, update, remove, list) is never shared. Key-value stores, databases and object storage have no read-only binding: sharing gives full read and write access. Where only some operations should be allowed, share a stateful object in front of the store instead.

​
Share a resource

  1. Open the API that owns the resource: Worker → Bindings → Storage & queues.
  2. Click the share icon on the resource.
  3. Choose One of your APIs (pick it and a binding name) or Another account (type the API slug from its page address).
A stateful object class can be shared once it runs in your production deployment: the other API always calls the class as production runs it, so a class that exists only in a preview cannot be shared yet. Under the resource, Shared with lists each API with its state: Invitation pending, Not bound yet, In use or Declined.

​
Use a resource shared with your API

  1. If it comes from another account, Accept the invitation at the top of Worker → Bindings.
  2. Click Add binding → Shared with this API, pick the resource and choose the binding name your code uses.
  3. Deploy code that uses it, e.g. await env.BASIC_SERP.get(env.BASIC_SERP.idFromName("default")).serve(params) for a stateful object, or await env.CACHE.get(key) for a key-value store.
The binding shows Shared by … with the owner API and account. Removing it (Unbind) removes only your binding; the resource and its data stay with the owner, and you can bind it again while it is shared with you. Previews and pinned deployments of your API bind the same resource as your production.

​
Revoke, delete and deploy rules

  • Revoke (owner): the other API’s production and active deployments are re-released without the binding at once; within seconds, calls through it fail in the other API’s code and appear in its runtime errors. A pending invitation is simply withdrawn. If the re-release cannot finish right away, the grant shows Update failed with a Retry.
  • Delete: a resource other APIs use cannot be deleted; the Studio names them. Revoke those shares first.
  • Deploy: production keeps every stateful object class other APIs use. Promoting or rolling back to a deployment without such a class is refused with the APIs that use it; a save that would do it stays a preview.
  • Limits: a resource can be shared with up to 10 APIs (pending and active together). Shared bindings count toward the other API’s 10 resources. An API a resource is shared with cannot share it further.

​
Cost and metering

  • The resource’s usage — storage, operations, stateful object compute — stays with the owner and appears in the owner’s compute usage, which names the APIs using its resources. The other API carries its own Worker’s compute.
  • Consumers are billed per listing, as always: a request to the other API’s listing counts once, against its own subscription. Your listing sees nothing of it.

​
Management API

Every share, accept, decline and revoke is recorded in the account’s activity. See Management API.