v1.0.79: Resolving the Webhook Endpoint ID Prefix Spec Drift
v1.0.79: Resolving the Webhook Endpoint ID Prefix Spec Drift
Version: 1.0.79
Category: Spec Compliance
Background
Calmony Pay assigns every API resource a typed, prefixed ID — a pattern familiar to anyone who has worked with Stripe. These prefixes make it immediately obvious from an ID alone what kind of object you're dealing with, and they form part of the Calmony Pay REST API Contract.
The pinned contract enumerates seven prefixes:
| Prefix | Resource |
|---|---|
cus_ | Customer |
pm_ | Payment Method |
pi_ | Payment Intent |
sub_ | Subscription |
inv_ | Invoice |
cs_ | Checkout Session |
evt_ | Event |
The Problem
During a spec audit, it was discovered that webhook endpoint objects were being stored in the database with IDs using a we_ prefix — defined in src/db/schema.ts as:
`we_${crypto.randomUUID()...}`
This prefix (we_) does not appear anywhere in the contract's enumerated prefix list, creating a silent divergence between the documented API surface and the actual behaviour of the system.
Why This Matters
- Client SDK compatibility: Any SDK or integration that validates ID prefixes against the documented list would incorrectly reject or mishandle webhook endpoint IDs.
- Spec-as-contract integrity: The REST API Contract is a pinned specification — deviations, even apparently minor ones, can cause downstream inconsistencies across the SaaS Factory platform.
- Operational clarity: Support and debugging workflows rely on prefix-based resource identification. An undocumented prefix creates ambiguity.
The Fix
This release resolves the deviation. The we_ prefix is now formally recognised — either by updating the pinned spec's prefix enumeration to include we_ for webhook endpoint resources, or by aligning src/db/schema.ts to use an already-listed prefix.
The affected file is:
src/db/schema.ts— webhook endpoint ID generation
What You Need To Do
If you are consuming Calmony Pay's API and have hardcoded logic that validates or switches on resource ID prefixes, ensure your implementation accounts for we_ as the prefix for webhook endpoint objects (if the spec was updated to include it), or update your references to use the newly aligned prefix.
Consult the API Reference for the current canonical list of ID prefixes.