Authentication

ReceiptKit uses API keys to authenticate requests. Each key is scoped to an organization and determines what actions are allowed.

API Key Types

Short version: use rk_pub_ for app code, and use rk_live_ only in Receipt Bridge or trusted backend services that need privileged bridge management actions.

rk_live_Secret Key

Secret key for trusted environments only. Required for Receipt Bridge setup, bridge registration/sync, and other privileged bridge-management endpoints.

Permissions

Use in Receipt Bridge desktop/Pi software
Use in server-only bridge management integrations
Never expose in browser or client apps

rk_pub_Public Key

Browser-safe key for print flows and status reads from frontends, POS clients, or the shared JavaScript SDK in client-side contexts.

Permissions

Send print jobs
Subscribe to printer/bridge status
Works with frontend/browser SDK usage
Cannot perform privileged bridge-management actions

Which Key Should I Use?

In most integrations, your application code only needs a rk_pub_ key. Keep rk_live_ keys limited to Receipt Bridge and trusted backend services.

Use Case	Key Type	Why
Receipt Bridge desktop / Pi app	rk_live_	Required for bridge validation, registration, and sync
Privileged backend bridge management routes	rk_live_	Server-only use for protected operational actions
Browser/frontend app (including shared JS SDK)	rk_pub_	Safe for client-side code with restricted permissions
POS/browser print integrations	rk_pub_	Usually print + status only, no bridge management needed

Creating API Keys

API keys are created in the ReceiptKit dashboard:

Go to Settings → API Keys in the dashboard
Click Create API Key
Choose the key type (Secret or Public)
Give it a descriptive name (e.g., "Production POS", "Development Bridge")
Copy the key immediately — it won't be shown again

Important:API keys are shown only once when created. The key is stored as a SHA-256 hash in our database — we cannot retrieve the original key. If you lose a key, revoke it and create a new one.

Using API Keys

Include your API key in the Authorization header as a Bearer token. Use rk_pub_ for standard print/status calls, and rk_live_ only when an endpoint explicitly requires a secret key.

HTTP Header

Authorization: Bearer rk_pub_your_api_key_here

curl example

curl -X POST https://www.receiptkit.io/api/bridge/print \
  -H "Authorization: Bearer rk_pub_abc123..." \
  -H "Content-Type: application/json" \
  -d '{
    "printerEndpoint": "tcp:00:11:62:32:5a:2a",
    "templateId": "tmpl_abc123",
    "data": {"storeName": "My Store", "total": "$9.99"}
  }'

Node.js (fetch)

const response = await fetch("https://www.receiptkit.io/api/bridge/print", {
  method: "POST",
  headers: {
    "Authorization": "Bearer rk_pub_abc123...",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    printerEndpoint: "tcp:00:11:62:32:5a:2a",
    templateId: "tmpl_abc123",
    data: { storeName: "My Store", total: "$9.99" },
  }),
});

Optional: include bridgeIdif you already know it to skip printer-to-bridge lookup.

Security Best Practices

•Never expose rk_live_ keys in client-side code. Use rk_pub_ keys for browser-side integrations.
•Use environment variables to store API keys on your server. Never commit keys to version control.
•Rotate keys regularly. You can have multiple active keys per organization. Create a new key, update your integration, then revoke the old one.
•Revoke compromised keys immediatelyfrom the dashboard. Revocation is instant — the key will stop working on the next request.
•Org-scoped isolation.Each API key is tied to one organization. A key from one org cannot access another org's printers, templates, or data.

MQTT Authentication

If you're using the receiptkit JavaScript SDK, authentication is handled automatically. The library uses your API key to authenticate with the MQTT broker (AWS IoT Core) via a custom authorizer.

MQTT Parameter	Value
Username	Your organization ID
Password	Your API key (rk_live_ or rk_pub_)
Topics	receiptkit/org/{orgId}/*