rpc-api-contract
RPC / API contract
How to write a business action that any channel — web, WhatsApp agent, MCP, cron, third party — can call without surprises. The same operation, one definition.
Why this exists (canon): the blocker to exposing our logic to agents was never "Postgres vs TypeScript" — it was the lack of a uniform contract (inconsistent naming, heterogeneous return types, no envelope, uneven idempotency). This skill is the operating procedure; the full rationale and the LaPyme benchmark live in the company brain page
estrategia/caso-lapyme+productos/profundizacion-tecnica/rpc-contract. We assemble public conventions: Google AIP (resource-oriented + custom methods), RFC 7807/9457 (errors), Stripe / IETF Idempotency-Key, PostgREST api-schema.
When to apply
- Creating a new business action (a mutation or a non-trivial read meant to be called by a channel).
- Exposing an existing function to a new channel (web → agent/MCP/third party).
- Reviewing a migration that adds/changes a callable function.
Forward-only: applies to functions created from 2026-06-16. Legacy rpc_* / unprefixed / fn_ callables stay as they are until deliberately migrated. No mass retrofit — strangler fig (wrap on demand when a function gets exposed to a new channel).