# `PhoenixKitEcommerce.Shopify.Provider`
[🔗](https://github.com/BeamLabEU/phoenix_kit_ecommerce/blob/0.5.10/lib/phoenix_kit_ecommerce/shopify/provider.ex#L1)

`PhoenixKit.Integrations` provider definition for Shopify.

Registered via `PhoenixKitEcommerce.integration_providers/0`.

## Why a static access token instead of OAuth

Core's generic OAuth callback (`PhoenixKit.Integrations.OAuth`, the
`IntegrationForm` LiveView) does not verify Shopify's HMAC callback
parameter, so wiring Shopify through it would inherit a real security gap.
Shopify's own recommended path for a single-store integration avoids OAuth
entirely: the store owner creates a Custom App directly in Shopify Admin
(Settings → Apps and sales channels → Develop apps), grants it Admin API
scopes, installs it, and gets a static Admin API access token — no
handshake needed. This provider models that: `auth_type: :credentials`
(the same shape "Universal SMTP" and AWS SES use) with two fields,
`shop_domain` and `access_token`. The field must be named `access_token`
(not e.g. `api_key`) because `PhoenixKit.Integrations.Encryption`
auto-encrypts by a fixed field-name list.

## Known limitation: "Test Connection" is a no-op

The generic integrations page's "Test Connection" button only checks a
connection for providers that declare a `:validation` strategy — the
strategy dispatch in `PhoenixKit.Integrations.do_validate/2` is hardcoded
in core and not externally extensible. This provider deliberately omits
`:validation`, so "Test Connection" always reports success without
actually checking anything. The real connectivity check is the sync
feature itself (`PhoenixKitEcommerce.Shopify.Sync.check/2`), which either
fetches products successfully or surfaces a real error.

# `definition`

```elixir
@spec definition() :: map()
```

The Shopify provider definition.

---

*Consult [api-reference.md](api-reference.md) for complete listing*