API & External System Integration

The challenge

A multi-tenant ERP platform had two problems:

Tenant databases could be reached across tenants through RPC endpoints.
The internal API between the control plane and each tenant had no replay protection or payload validation. A captured request could be re-sent.

I wrote an attack harness first: a real database plus a real HTTP server, with each test attempting one exploit.
I ran it against the original code to prove every weakness existed (18 failures), and only then changed the code.

Signed agent protocol v2: HMAC-SHA256 signatures over a body hash and timestamp, a timestamp-skew window, nonce replay protection, payload validation and default-deny entitlements.
Host-to-database policy applied to RPC services and to the cron database list, so a request for one tenant cannot reach another tenant's database.
REST API keys stored as SHA-256 hashes and compared with hmac.compare_digest, with rate limits.

I contributed to the development of an e-invoicing integration and a payment-provider integration. These patterns come from that work:

Outbound job queue: cron-drained, with idempotency keys and back-off of 1, 5, 15 and 60 minutes. Only network and rate-limit errors are retried; configuration errors fail immediately.
HTTP client discipline: TLS verification, timeouts, a correlation id, an API request log, and separate handling for 429 and 5xx.
Payment webhooks: constant-time secret checks; the webhook body is never trusted and the payment is re-fetched from the provider API. A FOR UPDATE NOWAIT row lock stops the webhook and the return handler from racing each other.

Original code: 18 harness failures. After the fix: 27/27 harness tests and 79/79 platform tests passing.
Not claimed: production rollout of this platform is not covered by the evidence. The e-invoicing and payment-provider integrations were team work; I was a contributor, not the sole author.