MAI · Authentication Profile
Mai Authentication
Authentication
MAI declares 0 security scheme(s) across its OpenAPI definitions.
CompanyAIArtificial IntelligenceMarketingAdvertisingPerformance MarketingAI AgentsDigital AdvertisingMarTechGoogle AdsShopifyE-CommerceAttributionAnalyticsEvent Tracking
Methods:
Schemes: 0
OAuth flows:
API key in:
Security Schemes
Source
Authentication Profile
generated: '2026-08-12'
method: derived
source: >-
npm @mai-co/pixel@1.0.5 — dist/mai-pixel.es.js (transport + config modules),
dist/types.d.ts, dist/config.d.ts, and the published README integration guide
docs: https://www.npmjs.com/package/@mai-co/pixel
summary: >-
MAI's one publicly reachable API — the Pixel Event Collection endpoint at
POST https://pixel.mai.co/api/collect — is UNAUTHENTICATED. There is no API
key, no bearer token, no signature and no securityScheme of any kind. The
request carries no credential; the tenant is named in the body as a plaintext
Shopify store domain, and the visitor is identified by a first-party cookie
the SDK itself mints. Every other MAI surface (the Shopify embedded app, the
web application) sits behind Shopify OAuth or an application login that is not
publicly documented.
security_scheme_count: 0
schemes: []
model:
authenticated: false
credential: none
transport_security: TLS 1.3 (HTTPS enforced)
tenant_identification:
field: shop.myshopifyDomain
location: request body
source: MaiConfig.storeDomain, supplied by the embedding site
secret: false
note: >-
The store domain is configuration, not a credential. It is visible in page
source on every storefront that installs the pixel, so it identifies the
tenant but does not authenticate it.
subject_identification:
field: client_id
location: request body
source: '_mai_cid cookie — UUID v4 minted client-side, 2-year max-age'
note: >-
Anonymous pseudonymous identifier. Upgraded to a named identity only when
the merchant calls MaiPixel('setCustomer', ...) with an email or phone.
consent_gate:
mechanism: MaiPixel('consent', ...)
aligned_with: Shopify CustomerPrivacy API
fields:
- analytics_processing_allowed
- marketing_allowed
- preferences_processing_allowed
- sale_of_data_allowed
default: >-
Tracking is ALLOWED by default. If consent() is never called the SDK sends
events. Setting analytics_processing_allowed to false halts all sends.
note: >-
This is the only client-side gate on the endpoint, and it is enforced in
the browser by the SDK — not by the server.
observations:
- >-
Because the endpoint is unauthenticated and accepts a caller-supplied store
domain, nothing in the published contract prevents a third party from
posting events attributed to another merchant's store. MAI may apply
server-side validation that is not visible from the client bundle; none is
documented.
- >-
The SDK sends the body with Content-Type text/plain (both the
navigator.sendBeacon Blob and the XHR fallback), which keeps the request a
CORS simple request and avoids a preflight. A consequence is that no
Authorization header could be added without changing that property.
- >-
MaiConfig exposes an apiEndpoint override documented as "for debug/staging
only", so the collection host is configurable by the embedding site.
gaps:
- No published authentication documentation for any MAI API.
- No OAuth 2.0 / OpenID Connect metadata on any host (all /.well-known/ probes miss).
- No API key issuance, rotation, or revocation story is published.