access.grant(slug: string, memberId: string, options?: RequestScope): Promise<GrantedProductAccessResource>Grants one workspace member access to a product. The two path values are the whole input, there is no request body, and the call is idempotent: re-granting an existing grant succeeds and still resolves granted: true.
memberId is a workspace member id, the value on access.list entries and on the members list, not a user id. Passing a user id reports a missing member, which is the most common failure here. Granting on a public product is allowed and only records the row, which starts affecting reads if the product is later made private.
Example
const granted = await envless.products.access.grant('billing', '8f1c0e42-9b7a-4d21-9d0e-3a41c7f5b210')
console.log(granted.granted, granted.user?.email)Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
slug | string | Yes | Product slug, or the product uniqueId when the value is UUID shaped. |
memberId | string | Yes | Workspace member id, the same id space the members endpoints use. |
options.signal | AbortSignal | No | Cancels the request. |
Returns
GrantedProductAccessResource with the member id, a user summary and granted.
Worth knowing
- The row is upserted, so the API answers 200 rather than 201 even on a first grant.
- A product beyond the plan allowance refuses grants with the same locked error that blocks updates.
Required scopes
product-access:write
Underlying endpoint
PUT /products/{slug}/access/{memberId}
Request and response schema, every error code, and a live playground.
In Python
envless.products.access.grant()
The same method in envless-sdk, the Python SDK, with the same request, retries and errors.
In Ruby
Envless.products.access.grant
The same method in envless-sdk, the Ruby gem, with the same request, retries and errors.
In PHP
$envless->products->access->grant()
The same method in envless/sdk, the PHP SDK, with the same request, retries and errors.