Credentials
Ante issues several different secrets. They are not interchangeable. A typical browser storefront uses a publishable key plus a signing secret — not the secret API key.
Copy this page as a setup prompt for your coding assistant.
At a glance
| Credential | Prefix | Storefront checkout | Headless REST | Typical env var |
|---|---|---|---|---|
| Merchant ID | ante_merch_ | Yes — identifies your account in API calls | Yes | NEXT_PUBLIC_ANTE_MERCHANT_ID |
| Publishable key | ante_pk_test_ / ante_pk_live_ | Yes — browser SDK and signed session create | Optional — server can use publishable + signature instead | NEXT_PUBLIC_ANTE_PUBLISHABLE_KEY |
| Signing secret | ante_sign_ | Yes — server HMAC for cart signatures (required with publishable key) | No — not used when secret key skips signing | ANTE_SIGNING_SECRET |
| Secret API key | ante_sk_test_ / ante_sk_live_ | No — never in the browser | Yes — server automation, webhook admin, unsigned session create (when approved) | ANTE_SECRET_KEY |
| Webhook secret | whsec_ | Optional but recommended — verify dashboard webhook deliveries | Same | ANTE_WEBHOOK_SECRET |
The common mistake
Signing secret ≠ secret API key ≠ webhook secret. ANTE_SIGNING_SECRET (ante_sign_…) signs carts for the browser SDK. ANTE_SECRET_KEY (ante_sk_…) is a REST bearer token for backend-only calls. ANTE_WEBHOOK_SECRET (whsec_…) verifies inbound webhook deliveries only. Putting the wrong credential in ANTE_SIGNING_SECRET produces Invalid cart signature — even when the value is valid for another purpose.
What each integration uses
Hosted modal (CDN or npm) — most storefronts
This is the default path: shopper clicks Split with Ante, your server signs the cart, the SDK opens the modal on splitante.com.
| Step | Credential |
|---|---|
| Browser loads SDK | Publishable key + merchant ID |
| Shopper clicks Split with Ante → your POST /api/cart/sign | Signing secret (server only) |
| SDK calls POST /api/v1/sessions | Publishable key + X-Ante-Signature header |
| You fulfill the order | Webhook secret (whsec_…) on POST /api/webhooks/ante |
Secret API key is not used. See Getting started, JavaScript SDK, and Cart signing.
React storefront
Same credentials as the hosted modal path. @splitante/react-sdk is a thin wrapper around @splitante/sdk — it does not change which keys you need.
Headless REST (server-owned checkout)
Your backend calls POST /api/v1/sessions with a secret API key. When headless_api_enabled is true on your merchant, cart signing can be skipped. No browser SDK, no publishable key, no signing route — but also no hosted button; you build the UX yourself.
Request access from Developers → Headless REST (owners and admins). Our team reviews your use case and enables headless_api_enabled in Support Console. See the REST API docs.
Environment variables (copy-paste)
# Client — safe to expose in the browser bundle NEXT_PUBLIC_ANTE_MERCHANT_ID=ante_merch_… NEXT_PUBLIC_ANTE_PUBLISHABLE_KEY=ante_pk_test_… # Server only — never prefix with NEXT_PUBLIC_ ANTE_SIGNING_SECRET=ante_sign_… ANTE_WEBHOOK_SECRET=whsec_… # optional until you wire webhooks # NOT needed for browser checkout: # ANTE_SECRET_KEY=ante_sk_test_…
Where to get each value
| Credential | Dashboard location |
|---|---|
| Merchant ID | Business menu or Settings |
| Publishable + secret API keys | Developers → Credentials (shown once at create/rotate) |
| Signing secret | Developers → Signing (generate or reveal) |
| Webhook secret | Webhooks → add endpoint → whsec_ shown once |
Open the prefilled wizard at Developers for snippets with your merchant ID filled in.
Test vs live
Sandbox merchants use ante_pk_test_* and ante_sk_test_*. After you toggle live mode, rotate to ante_pk_live_* and ante_sk_live_*. The signing secret is per merchant (not per key prefix) — rotate it on Developers if you suspect a leak; then update ANTE_SIGNING_SECRET everywhere and redeploy.
Related
Security · Cart signing · Troubleshooting · Live demo store · plurel-company/ante-demo-store — a full Next.js reference (public clone; Plurel maintainers only push to main)