Use any programming language

Connect through HTTPS and JSON using your existing stack; the SDK is optional.

The integration boundary is HTTPS plus JSON, with an OpenAPI contract and JSON Schema. A TypeScript or Python SDK is a convenience; it is not an admission requirement. Use your existing server, script, automation tool or programming language.

The supplier access and validation operations are a preview pending application rollout. This page demonstrates sample validation, not ingestion. Verify the live OpenAPI and release status first. Buyer writes, recurring intake and email intake are not exposed by this contract.

Use your existing stack

Stack	Typical implementation
JavaScript / TypeScript	A server-side HTTP client or the starter SDK
Python	An HTTP client or the standard-library starter SDK
Java / Kotlin, C# / .NET, Go, Rust	The runtime’s HTTP client, or an OpenAPI-generated client compatible with 3.1
PHP, Ruby, Elixir, another language	A server-side HTTPS request with JSON serialization
Shell or PowerShell	A scheduled script using an HTTP client
Low-code automation	A scoped source connector, mapping step and HTTP request action

Choose a maintained client supported by your environment. Verify generated clients against the published schema and sample errors; generator support varies. No language-specific package is required. Do not embed a supplier key in public browser code or in a shared workbook cell.

The wire contract

Once the preview endpoints are released:

1. Call GET /api/v1/supplier/me with the company key. Confirm the expected company identity, scopes, schema version and capabilities.validate.
2. Map a small approved source sample to the record schema.
3. Send the JSON batch to POST /api/v1/supplier/validate with Content-Type: application/json and the same authorization header.
4. Interpret a valid result as validation only: persisted: false, admitted: false.

POST /api/v1/supplier/validate HTTP/1.1
Host: middlemantechnologies.com
Authorization: Bearer <value from your secret store>
Content-Type: application/json

<JSON batch matching the supplier schema>

This wire outline contains placeholders. Use the synthetic example to understand the complete body. Live samples require a new source read and truthful timestamps.

cURL

# Disable shell tracing; provision this variable through your secret store.
curl --fail-with-body --max-time 15 \
  'https://middlemantechnologies.com/api/v1/supplier/me' \
  -H "Authorization: Bearer $MIDDLEMAN_SUPPLIER_API_KEY"

# After confirming the expected company and validation capability:
curl --fail-with-body --max-time 15 \
  'https://middlemantechnologies.com/api/v1/supplier/validate' \
  -H "Authorization: Bearer $MIDDLEMAN_SUPPLIER_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @source-batch.json

Send keys only to your verified Middleman application origin. Reject redirects and never pass the key to a source connector, email recipient, documentation service or agent message. Protect process arguments and logs on a shared runner; prefer a client that reads secrets directly from the runner’s secret store.

Rules every client must preserve

• At most 50 records per preview validation request, within 256 KiB of encoded JSON. This is not a bulk ingestion limit or endpoint.
• Identifiers and exact decimal prices remain strings; do not round them through floating-point conversions.
• Follow schema-required fields, units, null handling and timestamp rules. Never alter stale timestamps to pass validation.
• Parse HTTP status and JSON content. A redirect, HTML login page or 404 does not prove receipt.
• On 422, correct field errors. Resolve 401/403 access failures before retrying. Honor Retry-After on 429; use bounded backoff for transient errors and timeouts.
• Keep local validation separate from recurring delivery. Future write APIs need their documented idempotency and receipt behavior; an arbitrary header does not create those guarantees.

Next, prepare the schedule and delivery checks that will run when an intake route is enabled.