The problem
An AI agent that can mutate a shared Airtable workspace or move real money through PayPal unattended is one bad inference away from corrupting a pipeline or sending a duplicate refund. Most teams solve this by keeping the API keys sealed and copying data by hand which defeats the purpose of automation. The RailCall platform offers a middle path: every action flows through a preview, approve, execute, signed-receipt loop called the Airlock. Two modules built for the RailCall Developer Challenge Round 2 put that loop around Airtable and PayPal.
Airtable Bridge - 37 governed commands
Airtable Bridge gives an AI operator 37 real Airtable commands across bases, tables, fields, views, records, webhooks, invites, and collaborators. Seventeen read commands run freely: list bases, get table schema, search records, count records, list webhooks, list collaborators. Twenty write commands stop at the Approval Airlock: create, update, or delete tables, fields, views, records, and webhooks; upsert records keyed by a merge field; invite users and manage their permissions.
Every write is bound to the exact approved payload hash. If someone edits the payload after approval, the hash no longer matches and the command refuses to run. Delete and update commands add an optimistic precondition: they verify the live record still matches what was approved before mutating, so a stale approval cannot overwrite a record that moved since you approved. Creates and upserts are idempotent with configurable conflict handling (error, ignore, update).
The module is free (license_required: false) and is verified by 221 offline contract tests covering manifest integrity, pure domain logic, handler integration, safety proof chain determinism, v2 signature readiness, and transport layer behavior.
Listing: https://railcall.ai/marketplace/muhamed/airtable-bridge/
PayPal Bridge - 33 governed commands
PayPal Bridge gives an AI operator 33 real PayPal commands across orders, refunds, payments, subscriptions, plans, products, invoices, and disputes. Fifteen read commands run freely: list orders, get a refund, retrieve a subscription, list invoices, list disputes. Eighteen write commands stop at the Approval Airlock: create, capture, authorize, or void orders; issue refunds; create, cancel, suspend, or activate subscriptions; create, update, or deactivate billing plans; create products; create, send, remind, or cancel invoices; accept dispute claims.
Refunds, subscription creations, plan creations, product creations, and invoice creations use PayPal-Request-Id idempotency tokens so a retried command cannot produce a duplicate financial effect. Capture, void, cancel, suspend, activate, update, send, remind, and accept commands all check the live provider state against the approved state before mutating if the order, subscription, plan, invoice, or dispute moved since you approved, the precondition fails and the command stops.
This is a paid module (license_required: true). Buyers purchase through Stripe Checkout on the marketplace listing; on completion, RailCall signs an Ed25519 license bound to the buyer's install pubkey. The loader gates access before the handler functions register if the license is missing, expired, or bound to a different install, the module stays in the rejected list and no handler functions register. The handler itself does not verify the license; enforcement is entirely loader-side. Subscriptions auto-renew via Stripe's invoice.paid webhook with a grace period for short-term outages.
The module is verified by 234 offline contract tests covering manifest integrity, pure domain logic, handler integration, safety proof chain determinism, v2 signature readiness, and transport layer behavior.
Listing: https://railcall.ai/marketplace/muhamed/paypal-bridge/
What both modules share
- Layer separation: pure domain planners are isolated from vault and I/O; a fixed-origin transport is the only network layer.
- Token isolation: the API token is read from RailCall's vault, never accepted as command input, never logged, never returned in any response.
- Deterministic receipts: every successful result carries a SHA-256 event chain from intent through live observation and decision to verified outcome, sealed inside an Ed25519-signed receipt.
- Network boundary: the manifest declares only the provider domains it needs, no subprocess use, and no filesystem writes.
- Fail-closed errors: malformed inputs, missing credentials, provider refusal, and ambiguous outcomes fail closed with the token excluded from the error text.
Evidence
455 offline contract tests pass across both modules (221 for Airtable, 234 for PayPal). Each module ships with a TESTING.md evidence boundary, a COMMANDS.md command reference, a README.md install guide, all based on real test runs, not mock claims.