Rivetport.
API COMPATIBILITY, BY CONTRACT

Keep your API contract.
Replace your backend.

Your backend can move on without taking every integration with it. Map the differences, review the evidence, and publish a deterministic bridge.

Build your bridge Read the documentation
INTERACTIVE EXAMPLECatalog / field mapping
01 / EXISTING CONTRACTGET

/v1/items/:id

{
  "id": "CAT-1042",
  "name": "Field notebook",
  "in_stock": true
}

The response your integrations expect.

02 / NEW BACKENDGET

/catalog/:product_id

{
  "product_id": "CAT-1042",
  "label": "Field notebook",
  "available": true
}

The same record. A different shape.

EXPLICIT FIELD RULES
product_id idlabel nameavailable in_stock

Run this local example to apply the three field rules.

One record. Two contracts. An explicit connection.Illustrative data · runs in your browser

THE WORKFLOW

Intelligence to propose.
Rules to execute.

Astra helps propose the mapping. You resolve the meaning and approve the rules. Published requests follow those rules, without a model in the request path.

  1. 01

    Connect the contracts.

    Import your existing and replacement OpenAPI specifications. Choose the GET operations you want to preserve.

  2. 02

    Review the differences.

    Inspect field rules, resolve unsupported changes, and test against expected responses. Schema checks and human approval have separate jobs.

  3. 03

    Publish with a way back.

    Deploy an approved version. Inspect failures, rotate access credentials, pause execution, or roll back to an earlier release.

A DELIBERATE SCOPE

A smaller surface.
A clearer promise.

For read-only catalog and reference-data APIs. One approved upstream GET per admitted request.

Read the supported contract

Built for

  • OpenAPI 3.0 and 3.1 JSON / YAML
  • Explicit route, query, and field mappings
  • Bounded arrays and approved value maps
  • Separate success and error responses

Outside the contract

  • Writes, transactions, or multi-request joins
  • Guessed units or pagination semantics
  • Per-user authorization migrations
  • Private-network APIs or arbitrary scripts
THE CLIENT BOUNDARY MATTERS

Keep the address.
Or choose a new one.

Your ingress Existing client boundary

Retain your hostname, routes, and authentication checks at an ingress you control. Route authorized requests through the bridge to preserve that client configuration.

Managed endpoint Client configuration changes

Connect directly to the bridge endpoint using a scoped credential. This requires updating your integration’s endpoint and authentication configuration.

Compatibility requires reviewed semantics, not just matching schemas. Existing clients remain unchanged only when the original boundary is preserved.

MAKE THE NEXT MOVE

New backend.
Familiar contract.

Open your workspace Plans & limits