Skip to main content
Run the integration against a dedicated test customer in your workspace first. Keep test events and payment-provider test mode separate from real customer activity. Tick each item only after you have seen it work.

​
Keys and setup

  • Secret keys (sk_) are only on your server and read from the environment. The browser only has a publishable key (pk_), which can read the plan catalog and nothing else. See authentication.
  • You use the latest Node.js, Python, Go and React SDK releases. See each SDK’s installation page for the current versions.
  • The feature, plan, customer and active subscription exist before events are sent. The event name equals the feature code exactly.
  • Customer identity comes from your authenticated backend, never from the browser.
  • If a customer can hold more than one active subscription, you pass the subscription explicitly.

​
Events

  • Each business event has a stored transaction ID, timestamp and payload. A retry sends all three unchanged; a new ID creates a new event. See idempotency.
  • You send an event, then read usage back and see the expected count. Acceptance of a request is separate from asynchronous usage processing, so read after a few seconds.
  • Batches have at most 100 events, and you resend a whole batch after an unreadable failure. See events.
  • You tested a wrong event name: it is accepted but never counted.

​
Decisions and credits

  • can() is treated as a point-in-time decision, not a quota reservation. A 503 (usage_unavailable) is handled as an unavailable decision, never as permission or zero usage, with a bounded retry. You keep the request ID for support. Entitlement changes can take about a minute to refresh.
  • Credit-backed work uses usage.track with a stable idempotency key per unit of work, and a denial (allowed=false) stops the work.
  • Initial subscription credit grants are asynchronous: you wait for the expected balance before admitting credit-backed work.

​
Errors and retries

  • Your code retries only network errors, timeouts, 5xx and 503 with Retry-After, always with the same key and payload. It does not retry 4xx. See errors.
  • You forced each of these once and saw the right behaviour: a bad key (401), a pk_ key on a protected call (403), an unknown customer (404), the same idempotency key with a different request (409), and a network failure mid-request.
  • A retry from a new process passes an explicit timestamp for usage.track, because the SDK only remembers the time it filled in for the client that sent it.

​
Webhooks

  • Your receiver verifies the signature on the raw body, deduplicates on X-Nozle-Unique-Key, answers 2xx within 30 seconds and returns 200 for events it does not handle. See receive webhooks.
  • You do not rely on delivery order, and you read the object from the API when you need its latest state.

​
Cost rating

  • The Cost Rules and composition for the usage you price are configured and published.
  • A test transaction shows its rated amount. An event with uncosted status is recorded but has no rated cost yet: review its reason before it reaches financial reports.

​
Payments

  • Your payment provider is connected and the flows your product exposes work: successful checkout, decline and retry, subscription changes, cancellation, renewal, refunds and authentication challenges. A free subscription or a rendered billing component does not test payment settlement.
  • Checkout return URLs are on the allowlist of both Core and the Engine. See create checkout.

​
Operations

  • You monitor your request errors, processing lag and reconciliation differences, and you have tested email delivery, any SSO provider you enable, and your own backup and restore.
  • You measured your own workload before promising a capacity or latency SLA. Request acceptance throughput alone does not establish processing capacity.