API

Availability

Planned: A public API is future scope. The supplied handoff does not establish a supported API contract, so these docs provide no endpoints, authentication examples, or request payloads.

Reported beta, not independently verified: The local MVP has public RFQ intake and manufacturer workspace workflows. The existence of a working application does not establish that its underlying requests are supported for external automation.

Prepare an Integration Requirement

Before asking for API access, describe the process you want to improve. Identify the information you need to exchange, the business reason, expected frequency, and how someone will resolve errors. Distinguish a need to read information from a need to change it.

Discuss those requirements through your existing beta onboarding contact. Do not send credentials or confidential customer data simply to illustrate the request; use non-sensitive examples.

Wait for a Verified Contract

Verification gaps: Authentication, authorization, resource schemas, versioning, limits, error behavior, and availability dates are not established. Do not build against guessed URLs, browser-internal requests, or examples from unrelated products.

A future implementation needs its own confirmed documentation and testing before it can be relied on for business workflows. Nothing here promises compatibility with an undocumented interface.

See webhooks for the corresponding event-delivery boundary and the roadmap for planned scope.