Skip to main content
For an invoice integration, choose the key according to the resource you are protecting. warehouse_sync can group competing Jobs. invoice:invoice-1:issue:v1 identifies one effect even if that invoice is retried later. Keep those identities separate.

​
Explore the behavior

​
Capacity keys

A shared external warehouse account may require warehouse_sync on every related Job template. If each template chooses its own name, their limits add together at the external service. Job-template keys accept letters, numbers, underscores and hyphens. They are literal configured strings. Do not copy an expression such as event.data.customerId from a different workflow product into this field. For dynamic per-customer admission inside a bounded Component, derive a validated key in code and use explicit low-code concurrency. This controls the admitted section; it does not change the Job template’s dispatch bucket.

​
Idempotency keys

An invoice-issue operation needs a key tied to the invoice and operation version, such as invoice:invoice-1:issue:v1. A fresh random key for every retry defeats duplicate protection. A key shared by all invoices prevents unrelated work. Define how long a retry may arrive before choosing expiry. Keep durable business evidence after the admission key expires. See idempotency.

​
Cache keys

Include the customer scope, filters, relevant revision and time window when they affect the result. Avoid secret values and personal payloads in keys. Expiry means a cached answer may be absent; it does not mean a business effect has been reversed. See Database Cache for cache operations and retry recovery for uncertain outcomes.
Last modified on November 8, 2026