Test and mock an API contract from OpenAPI to client code

Use the same operation for documentation, request testing and client generation. This example uses integer minor units: 4900 means 49.00 EUR. It describes an example service; api.example.com is a placeholder, not a REST Test demo endpoint.

Save the following as openapi.json and import it into a workspace. Expected result: Documentation lists POST /payments with a required JSON body and a 201 response. This contract describes behavior; it does not implement a payment service.

{
  "openapi": "3.0.3",
  "info": {
    "title": "Payments API",
    "version": "1.0.0"
  },
  "servers": [
    {
      "url": "https://api.example.com"
    }
  ],
  "paths": {
    "/payments": {
      "post": {
        "operationId": "createPayment",
        "summary": "Create a payment",
        "requestBody": {
          "required": true,
          "content": {
            "application/json": {
              "schema": {
                "type": "object",
                "required": [
                  "amount",
                  "currency"
                ],
                "properties": {
                  "amount": {
                    "type": "integer",
                    "minimum": 1
                  },
                  "currency": {
                    "type": "string",
                    "example": "EUR"
                  }
                }
              }
            }
          }
        },
        "responses": {
          "201": {
            "description": "Payment created",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "properties": {
                    "id": {
                      "type": "string"
                    },
                    "amount": {
                      "type": "integer"
                    },
                    "currency": {
                      "type": "string"
                    }
                  }
                }
              }
            }
          },
          "422": {
            "description": "Invalid amount"
          }
        }
      }
    }
  }
}

Open POST /payments in Request Builder. Replace the example server URL with a service you control, choose JSON content type and add the authentication required by that service. The example schema does not prescribe an authentication scheme.

Choose Browser Runner to test browser connectivity; the target must allow your origin, method and headers through CORS. Choose Cloud Runner for backend execution, subject to server network protections. A Cloud Runner success does not prove a browser integration will work.

A service implementing this contract should return 201 with a payment object for valid input. Try amount: 0 and compare the actual result to the documented 422 response. A response with the wrong shape is a contract discrepancy even when its status is successful. A CORS failure or timeout is a transport problem, not a documented error response.

POST /payments
Content-Type: application/json

{ "amount": 4900, "currency": "EUR" }

In API Designer, add and enable a Card declined mock variant on POST /payments. Set status 422, Content-Type application/json and body { "code": "card_declined" }. Saving the variant defines a response; it does not execute it.

Create a workspace mock server key and copy the mock base URL from the dashboard or Integrations. Send POST to that base URL plus /payments with Authorization: Bearer <mock-server-key> and X-Rest-Test-Mock: Card declined. Expected configured result: 422 with the card_declined body. No live payment service is needed.

A missing enabled variant returns mock_not_found. A key for a different workspace is rejected with 403. Check the method and path, variant name, key scope and account quota before retrying. Do not put a workspace server key in publicly shipped client code.

curl -X POST "$MOCK_BASE_URL/payments" \
  -H "Authorization: Bearer $MOCK_SERVER_KEY" \
  -H "X-Rest-Test-Mock: Card declined"

Use Settings > Export OpenAPI to download the saved workspace definition as JSON. Invalid designs return validation errors; correct the indicated operation or schema and retry. Review export warnings, including any x-rest-test-export-warnings field, before passing the document to another tool. The exported contract does not include unsaved editor changes.

Generate TypeScript Fetch, Axios, RTK Query or React Query code, C# HttpClient or Refit, or Python httpx or requests code from the operation. Compare request and response types with the imported schema. Configure authentication and base URL in your application and run its tests; generated output is source code to review, not proof of server behavior.

In Settings > API Source, connect an authorized GitHub integration, select the repository, branch and specification file, then preview and save the source. Use a JSON or YAML OpenAPI document. Repository access depends on the GitHub App installation permissions.

After a repository change, check for updates and inspect the operation diff before applying it. Resolve conflicts rather than assuming every remote change is safe. Automatic checks use the account plan minimum interval and monthly source-check allowances shown on Pricing.

If the repository or branch is missing, check installation access and the selected branch. Invalid YAML, unsupported versions and broken source documents must be fixed before import. Synchronization imports the source definition; it does not promise to commit local designer changes back to GitHub.