You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AS A Service-Module developer I WANT to formalize the existing endpoints database store and its contracts SO THAT the canvas and the future Teenused → APId page use one stable, well-defined source of truth (per #871)
Description
Use the existing DB-backed endpoints table as the canonical API endpoint store.
This task clarifies ownership, visibility, and CRUD semantics without introducing new endpoint behavior.
Acceptance Criteria
Database Source of Truth
All endpoint create/update/delete operations go exclusively through the endpoints table
(no embedded or parallel endpoint sources)
Database Field Semantics
endpoint_id → endpoint identity
is_common=true → public endpoint
is_common=false → private endpoint
service_id → owner service (required for private endpoints)
Defines which service owns an endpoint and whether it is public or restricted, ensuring endpoints are only visible and usable within their intended scope.
is_common=false requires service_id
Private endpoints are visible only to the owning service
Orphaned private endpoints are prevented (validation at create/update time)
CRUD Contract Normalization
Existing CRUD routes are reused (no reimplementation)
Success and error responses follow a consistent, documented response shape (no behavioral changes)
List/read operations support:
is_common
service_id
deleted=false
search by name
Backward Compatibility
Existing canvas flows work unchanged
No changes to runtime execution behavior
Notes
Out of scope: Test URL / verification, schema capture, lifecycle flags (active), LLM runtime execution, UI changes.
Schema validation and normalization are handled in Task 2 — Definitions Schema & Validation.
Definition of Done
Endpoint ownership and visibility rules are unambiguous
AS A Service-Module developer
I WANT to formalize the existing
endpointsdatabase store and its contractsSO THAT the canvas and the future Teenused → APId page use one stable, well-defined source of truth (per #871)
Description
Use the existing DB-backed
endpointstable as the canonical API endpoint store.This task clarifies ownership, visibility, and CRUD semantics without introducing new endpoint behavior.
Acceptance Criteria
Database Source of Truth
endpointstable(no embedded or parallel endpoint sources)
Database Field Semantics
endpoint_id→ endpoint identityis_common=true→ public endpointis_common=false→ private endpointservice_id→ owner service (required for private endpoints)definitions→ structured API definition (URL, method, params, headers, body, metadata)deleted→ soft delete flagOwnership & Visibility
Defines which service owns an endpoint and whether it is public or restricted, ensuring endpoints are only visible and usable within their intended scope.
is_common=falserequiresservice_idCRUD Contract Normalization
is_commonservice_iddeleted=falsenameBackward Compatibility
Notes
active), LLM runtime execution, UI changes.Definition of Done