Entity Gateway Commerce

Entity Gateway Commerce makes Drupal Commerce prices usable over JSON: a price stops being a raw decimal string and arrives as a number, a currency code and a ready-to-print formatted string.

If you are building a storefront, a mobile app or any front end that talks to Drupal over HTTP, Entity Gateway is what publishes your content as JSON REST resources under /api/... — you choose the entity types, the bundles, the HTTP methods and the
individual fields, and nothing is exposed until you say so.

Commerce prices are the one thing it cannot hand over usefully on its own. Drupal stores a price as two columns: a decimal string like 123.000000 and a currency code like USD. Serialize that as-is and every client you write has to reimplement currency formatting which symbol, where it goes. or , for decimals, digit grouping, how many fraction digits this particular currency uses, and all of it per language. That is how a store ends up showing R$123.00 or $1.234,50.

This module formats the price on the server, with Commerce's own formatter, in the request's own locale, so your front end prints a string instead of computing one.

Features

A price field becomes an object instead of a decimal string:

"price": {
    "number": 123.0,
    "currency_code": "USD",
    "formatted": "$123.00"
  }

• formatted is produced by Commerce itself (commerce_price.currency_formatter) in the request's locale the current language plus the resolved country. Symbol, placement, separators, grouping and per-currency fraction digits all come from Commerce's currency data, never from your client code.
• Every price field, not just products. A variation's price, an order's total_price, an order item's
  unit_price, a price field you added yourself — anything of type commerce_price, on any resource you expose.
• Zero configuration. It is the automatic format for that field type, so an exposed price field uses it the moment the module is enabled.
• It plays by Entity Gateway's rules, because it is a field output plugin and not a normalizer: a price field you did not make visible is not
  returned, field-level access is checked first, the JSON key follows the same camelCase convention as every other field, and you can switch one field back to the stored pair by picking Default in the admin UI.
• Correct caching. Responses carry the currency list cache tag and a language cache context, so editing a currency or switching language neverserves a stale price.
• Described in your API spec. With Entity Gateway's OpenAPI submodule, the shape above appears in the generated OpenAPI 3.1 document and in Swagger UI.
• Empty prices are null, never a half-filled object.

Typical uses: a decoupled storefront (React, Next.js, Vue, Nuxt, Astro), a mobile app, a product feed for another system, or a multilingual / multi-currency store where the same product has to read correctly in several locales.

Post-Installation

There is no configuration page, no new content type and no permission of its own this module only changes how one field type is serialized.

1. Enable it: drush en entity_gateway_commerce, or at /admin/modules.
2. Expose your Commerce resources in Entity Gateway, at Configuration → Web services → Entity Gateway → Resources
   (/admin/config/services/entity-gateway/resource-list). Those screens come from the Entity Gateway UI submodule; without it the same settings are written with drush config:set or a config import.
3. On the resource form, tick the price field as Visible, like any other field. Entity Gateway returns nothing it was not told to return.
4. Look at the Format column of that row: it already reads Price. There is no settings gear, because there is nothing to
   configure. Pick Default if you would rather receive the raw {number, currency_code} pair.

Two things worth knowing:

• Writing a price uses the two stored values — {"price": {"number": 123, "currency_code": "USD"}}. formatted is computed
  on read and is not accepted on write.
• If you configure resources outside the admin UI (drush config:set, a config import), run drush cr afterwards: Entity Gateway's API routes are generated from config, and only the admin forms rebuild the router on save.

Additional Requirements

• Entity Gateway 1.0 or newer — this is an add-on to it, not a standalone API.
• Commerce 3.x. Only its Commerce Price submodule is required, and Drupal enables it for
  you; Commerce Product is not needed, so an order-only or invoice-only API works just as well.
• Drupal 10.3 or newer, or Drupal 11.
• PHP 8.3 or newer.
• No libraries beyond what Commerce already installscommerceguys/intl supplies the currency and number formats.

Recommended modules/libraries

All three ship with Entity Gateway itself; enable what you need:

• Entity Gateway UI — the admin screens used in Post-Installation above.
• Entity Gateway OpenAPI — publishes an OpenAPI 3.1 document and a Swagger UI page for your generated API, this module's price shape included.
• Entity Gateway Media — a storefront usually wants product images as real image-style URLs; this submodule does that for media reference fields.

Similar projects

• JSON:API (Drupal core), with or without JSON:API Extras, serializes a price field as
  its stored properties: you receive number and currency_code and format them client-side. There is no server-formatted string, and the
  response follows the JSON:API document structure rather than a plain object.
• Commerce API builds a JSON:API-based API around the purchase flow — carts, order
  items, checkout. It answers a different question: use it to transact, use Entity Gateway plus this module to read and write Commerce entities as plain JSON
  resources.
• Views REST export can render a price through Commerce's own field formatter, but it is read-only and shaped by the view rather than by the entity.

The scope here is narrow on purpose: one field type, formatted server-side, inside an API whose field-by-field exposure you already control.

Community Documentation

• README — this page plus the JSON details.
• Entity Gateway's API guide — the client-side reference for the
  rest of the API: endpoints, response envelopes, filtering, sorting, pagination, writes and the error catalogue.