qURL 2.0: September Platform Release Notes

qURL™ 2.0 is our name for the September 2026 platform launch. It brings months of work across resource identity, access control, network hiding, and developer tools into the production platform. Individual packages keep their own version numbers; there is no single “2.0” version to install across every component.

For the broader story, start with Infrastructure Without Exposure. This page summarizes the capabilities available with the launch and the client releases that accompany it.

Stable resource identity with CRIDs#

Resources receive a Cryptographic Resource ID derived from their public key. Use the returned crid to identify and manage a resource through the API. The name grants no access and stays stable across location changes that preserve the resource key. Deleted identities are not reassigned to new resources.

CRIDs also let clients compare a delivered public key with a previously trusted resource name. This check establishes a name-to-key match. It does not, by itself, authenticate response content or grant network access.

See the CRID explainer and API reference. Read the returned field rather than attempting to extract a resource identity from an access link. Older resource records can omit the field; follow the API's documented response contract.

Signed qURLs and separate access grants#

The platform separates the resource from the links that grant access to it. A resource can have multiple qURLs, each with its own identity, expiration, and supported access rules. The qURL v2 format carries signed claims that clients verify against the trusted issuer.

The resource's CRID, the qURL issuer signature, and the application's response serve different purposes. CRID verification checks the resource key. Issuer verification checks who issued the access claims. Neither is a producer signature over the bytes an application returns.

The resource-oriented API makes these operations explicit:

• Register a resource: POST /v1/resources.
• Create a link with chosen access rules: POST /v1/resources/{id}/qurls.
• List its links: GET /v1/resources/{id}/qurls.
• Update or revoke one link: PATCH or DELETE /v1/resources/{id}/qurls/{qurl_id}.
• Revoke the resource and its links: DELETE /v1/resources/{id}.

Use the CRID in {id}. Keep qurl_id when you need to manage an individual link. Treat the returned access link as a secret.

The convenience route POST /v1/resources/{id}/share creates a link using resource defaults. The caller must own the resource and hold the qurl:resolve scope. Use the /qurls route when you need to choose access rules. The API quickstart covers registration, sharing, and revocation with complete requests.

Temporary access with explicit lifetime controls#

Link expiration and session duration are separate controls. A link's lifetime defines when it can be used; session duration controls the access established through it. Revoking a link and revoking the whole resource are also distinct actions.

Use the effective lifetimes returned by the API. Do not assume that link expiration destroys downloaded copies or that every already-open connection ends at the same instant. The API reference documents timing precision and connection behavior under CreateQurlRequest.session_duration.

Connector-based publishing for private resources#

A Connector provides the path from LayerV to a resource that remains in your environment. The CLI supports local publishing on macOS, Linux, and Windows. Follow the quickstart for installation, sign-in, publishing, and sharing; use the CLI reference for publishing and lifecycle commands.

Network hiding requires the resource's alternate public paths to be closed. Adding a Connector does not make an independently exposed origin disappear. Retain the application's own authentication and authorization where required.

Access for browsers and automation#

Recipients use qURL links through the browser flow and the verification selected by the owner. Programmatic clients can use the API and supported native tools. MCP exposes qURL tools to compatible agent clients; SDKs support application integrations.

These paths share the same central distinction: a CRID names a resource; an authorized grant enables access. A CRID is not an API credential, and an agent must not treat possession of the name as permission to connect.

Scoped credentials for automation#

Automation can use API keys with explicit scopes. Credential management requires explicit automation authority; an ordinary access key does not automatically gain the right to create more credentials. Child account keys require an unlimited plan, cannot exceed the parent scopes, and expire within 24 hours or earlier with the parent. Revoking a parent does not revoke its children; manage those separately. Enrollment tokens and device credentials have separate, restricted purposes.

The platform also provides delegated batch creation for integrations: an authorized capability fixes the resource and destination path, while the batch creates independent recipient grants. This is an asynchronous API operation; follow the returned status URL and the documented retry rules. See the API reference's API Keys and delegated qURL batch operations before integrating.

Client releases accompanying the launch#

The following are published package releases as of September 19. Their version numbers are independent of the qURL 2.0 launch name.

• qURL CLI 2.6.0 adds support for external supervision, one-shot enrollment token files, runtime request headers, and changing a local share's loopback target on restart. See the CLI 2.6.0 changelog.
• qurl-go 0.17.0 includes production issuer, cell, and Hub defaults. Production clients no longer need a separate deployment settings file. Sandbox and private deployments must keep an explicit deployment override. Unknown issuers and invalid signatures are still rejected. See the Go SDK release.
• qurl-connector 0.14.0 adds runtime request headers for group routes. For Go consumers, LocalHTTPRoute is no longer comparable because it contains a map; use the route Equal methods. See the Connector release.

Coming soon: response-content verification#

We are working on a way to verify producer-signed response content against the identity anchored by a CRID. This capability will arrive in a future release. Current CRID key verification and qURL issuer verification do not establish the authenticity of application response bytes. See the launch announcement for the direction and its purpose.

Upgrade and verify your integration#

1. Update through the documented CLI or SDK installation path. Package releases and hosted platform deployments have separate lifecycles.
2. Keep explicit sandbox or private-deployment settings where needed. In qurl-go 0.17.0, absent configuration selects production.
3. Update older resource-sharing integrations to POST /v1/resources/{id}/share; the former resource-level resolution route has been removed. This is distinct from POST /v1/resolve, which redeems an access token.
4. Store resource identity separately from individual link IDs and access links. Use API responses rather than parsing or constructing qURLs.
5. Test the recipient's full path: create access, complete verification, reach the resource, and revoke the intended grant. Check the other links still behave as expected.

Start with a private app, read the API reference, or contact us for help with your deployment.