$app:example App-owned metaobjects with types like this (including those created via declarative definitions) can now be read and written by the owning app itself, without requesting additional access scopes. Permission consent at install time gets one step simpler.
$app:example types like this; including those created via declarative definitions) — to read and write them,the additional access scopes that used to be required are no longer needed.Even for app-only data, you couldn't read or write it without requesting metaobject access scopes. That adds to the permissions a merchant has to consent to at install time.
App-owned metaobjects can be used without additional scopes, as long as the request comes from the owning app itself.2026-04 Just use the Admin API from this version onward.
$app: type), no scope is needed; if it's merchant-owned, a scope is still required as before. The key point is that even for the same "metaobject," how it's handled changes depending on the owner.$app: Prefixed typesWhen the type name $app:example such as $app: begins with this, the metaobject is identified as app-owned.
Those created with declarative metaobject definitions are also included.
No scope is required when the app that owns the metaobject is the one using it.
| Item | Before | New (2026-04 and later) |
|---|---|---|
app-owned($app:) read/write |
Scope required Requires requesting additional scopes | No scope required No additional request for the owning app |
| Declarative metaobject definitions | Adopt with additional scopes in mind | Can adopt without a second thought |
| Reading/writing merchant-owned | read_metaobjects etc. required |
Still required Scope still required, as before |
| Required API version | — | 2026-04 and later |
| Friction for merchants | More permission-consent items | Reduced Unnecessary scope requests go away |
To read and write app-owned metaobjects without scopes, the Admin API version must be 2026-04 or later.
This applies to $app: metaobjects owned by that app, created via this type or via declarative definitions. It assumes the owning app itself is the one using them.
$app:example App-owned metaobjects with types like this, including those created with declarative metaobject definitions. No scope is required as long as the owning app reads and writes them.
When working with merchant-owned metaobject types,read_metaobjects or write_metaobject_definitions and other individual scopes still need to be granted.
$app: typesWhat no longer requires scopes: $app: -prefixed app-owned metaobjects. merchant-owned is excluded, and nothing changes in how it is handled.
The no-scope behavior takes effect from 2026-04 onward. If you stay pinned to an older version, scopes are still required as before, so check your version pin first.
App-owned metaobjects created with declarative metaobject definitions are also covered. When adopting the declarative approach, you no longer have to worry about requesting scopes.
read_metaobjects / write_metaobject_definitions and the like remain necessary as long as you touch merchant-owned types. Don't mix up the spots where they coexist with app-owned.
By consolidating app-only state and settings into app-owned metaobjects, you can reduce the very number of scopes you request. That said, there is no documented step-by-step migration procedure (how to remove existing scopes, whether re-authorization is needed), so it is safest to verify in a sandbox before removing anything.
$app: -type app-owned metaobjects, raise the Admin API to 2026-04 or later, and drop the corresponding extra scope requests.2026-04 and-later API.$app: from the outset.read_metaobjects and the like, but it may actually touch only app-owned data, meaning it holds excessive permissions.2026-04 and later → and remove the additional scope requests that are no longer needed.$app: types and declarative definitions included) metaobjectscan be read and written without additional scopes on Admin API 2026-04 and later.