Fulfillment API and Ecommerce Integrations

This page covers the platforms Supera connects to, how a client integration is built and authenticated, the order payload Supera accepts, and the fulfillment data sent back when a kit ships.

Platforms And Carriers Supera Connects To

If you run a storefront on Shopify or WooCommerce, Supera configures the connection on our end. If you run a custom cart, an LIS, or an internal ordering tool, our development team builds the connection directly rather than routing it through an outside integration platform.

How Supera Integrations Work

Supera takes a hands-on approach to every client integration. A large part of the order process is standardized, but every program carries needs specific to its workflow: custom ordering fields, custom kit data, third-party services in the middle of the process.

Rather than force every client through one rigid schema, Supera builds a new client-facing API for each integration on top of a flexible backend. Our development team works directly with yours during the build phase. Each integration is provisioned with its own base URL, delivered alongside its own authentication credentials.

What clients use the API for

• Order intake. Orders post from your system to Supera automatically.
• Shipment updates. Status and ship dates sent back as they happen.
• Fulfillment data retrieval. Tracking numbers and individual kit IDs.
• Reporting hooks and data metrics. Program data pushed to your endpoint or pulled on demand.

Authentication

Each integration receives a dedicated base URL and its own credentials, typically a bearer token issued by Supera during the build phase. Credentials are scoped to your integration alone. No client can read or write another client's order data.

Placing Orders

Placing orders is the primary function of most client integrations. When an order is received, Supera stores it with a unique record ID. You can query that ID later for order details, or quote it back to us when you have a question about a specific shipment.

A common set of keys captures the minimum data Supera needs to process an order. Beyond that, every program gets custom fields at both the order level and the individual kit level.

{
  orderDate: string (yyyy-mm-dd, used to schedule day of shipment),
  recipientName: string,
  address: {
    street1: string,
    street2: string (optional),
    city: string,
    stateOrRegion: string (two letter code),
    postalCode: string,
    country: string (two letter code)
  },
  service: string (ex: fedex_2_day),
  lineItems: [
    {
      sku: string,
      quantity: number,
      data: {
        (custom per-kit order information)
      }
    }
  ],
  data: {
    (custom per-order information)
  }
}

Why kit-level custom data matters

For a regulated program, the data that travels with an order is as important as the shipment itself. Requisition detail, provider information, panel selection, and lot requirements ride along with the order instead of arriving by email after the fact. That is what keeps the kit, the paperwork, and the recipient aligned.

Fulfillment Webhooks And Queries

Supera stores tracking numbers and kit IDs for clients to access online, and that same data can be pushed automatically to your endpoint as orders ship. Most programs use webhooks rather than polling.

An example payload sent on order fulfillment:

{
  orderRecordId: string,
  status: string,
  shipmentDate: string (yyyy-mm-dd),
  recipientName: string,
  address: {
    street1: string,
    street2: string,
    city: string,
    stateOrRegion: string (two letter code),
    postalCode: string,
    country: string (two letter code)
  },
  service: string (ex: fedex_2_day),
  parcels: [
    {
      sku: string,
      quantity: number,
      outboundTracking: string,
      returnTracking: string (if applicable),
      lineItems: [
        {
          sku: string,
          kitId: string,
          returnTracking: string (per-kit, if applicable),
          data: { }
        }
      ]
    }
  ]
}

Kit-level tracking is the difference

General fulfillment providers tell you that an order shipped. Supera tells you which specific kit went to which recipient, and which return label will bring that specimen back.

Every line item returns its own kit ID and, where a return label applies, its own return tracking number. For a diagnostics or at-home testing program, that is what makes accessioning, specimen reconciliation, and recipient support work without a manual matching step on your side.

Documents And Reporting

Order data can be exported or retrieved in CSV format at any time, whether or not your program uses the API.

Supera also runs a document generation service. Provide a PDF or Word template and your order data is imposed onto it, then delivered to an endpoint or an inbox you choose. Clients use this for requisitions, packing documents, chain of custody paperwork, and recurring program reporting.

Bi-Directional And Complex Workflows

Not every program runs in a straight line from cart to shipment. Some place Supera in the middle of a larger workflow.

Supera has built integrations that take in data from one system, deliver it to another, then reverse the flow later in the program. If your kit program sits between a laboratory, a provider network, and a patient-facing application, that is a build we have already done.

Built And Supported In House

Supera's IT and development team is on staff. When you need a new field, a new endpoint, or a report that does not exist yet, it is scoped and built by the same people who built your integration. Nothing goes into a software vendor's queue and waits for a release cycle.

That team also owns the internal order management system your program runs on, so the integration and the operation behind it are not two separate vendors pointing at each other.

Frequently Asked Questions