UniLink API: Orders Endpoint (Access and Manage Customer Orders)

The /orders endpoint lets you read every customer order and update fulfilment status programmatically — the foundation for order management integrations and accounting exports.

Whether you are building an order fulfilment dashboard, pushing UniLink sales into your accounting software, or triggering a shipping label workflow after each purchase, the /orders endpoint gives you the structured access you need. Every sale made through your UniLink storefront creates an order record the moment payment is confirmed — accessible via API within seconds. The endpoint is read-heavy by design; you pull order data frequently and update status sparingly, which keeps the integration simple and the API calls predictable.

What the Orders Endpoint Does

The GET /orders endpoint returns a paginated list of all orders on your account, sorted by creation date descending by default. Each order object in the list response contains the complete transaction record: the order id, status, total (in cents), currency (ISO 4217 code), a customer object with name and email, an array of line_items, and a created_at timestamp in ISO 8601 format. The list endpoint supports multiple filters so you can slice the dataset to match exactly what your integration needs.

A single order fetch with GET /orders/{id} returns the same fields as the list but adds expanded line item detail. Each entry in line_items contains the product_id, a snapshot of the product_name and unit_price at the time of purchase, the quantity, and the subtotal. Product snapshots mean that even if you later change a product's price or name, the historical order record reflects the exact terms the customer agreed to — which is essential for accounting accuracy and dispute resolution.

Status updates via PUT /orders/{id} accept a status field with three possible values: pending (default after payment), fulfilled (order shipped or digital access granted), and refunded (payment reversed). Marking an order refunded via the API does not automatically trigger a payment reversal with your payment processor — the refund must be initiated separately in Stripe or your gateway. The API status field reflects the state you record, not a payment processor event. UniLink webhook events fire on status transitions, so downstream systems subscribed to order webhooks will receive the update.

How to Get Started

1. Log in to app.unilink.us and navigate to Settings → API. Generate an API key with write scope (needed to update order status) or read scope if you only need to pull data.
2. Fetch your first page of orders: curl -H "Authorization: Bearer YOUR_KEY" "https://unilink.us/api/v1/orders?per_page=10". Review the response structure to understand the field names and types.
3. Try a filtered request to confirm the filter parameters work with your data: GET /orders?status=pending&start_date=2026-01-01&end_date=2026-01-31.
4. Fetch a single order to inspect the full line items array: GET /orders/{id} using an ID from the list response. Confirm the line_items structure matches what your integration expects.
5. Test a status update on a test order: PUT /orders/{id} with body {"status": "fulfilled"}. Confirm the response returns the updated order object with the new status value.

How to Use the Orders Endpoint

1. List all orders: GET /orders?page=1&per_page=50 — page through results using page and per_page (max 100). The response includes a total count and has_more boolean for pagination logic.
2. Filter by status: GET /orders?status=pending — returns only orders awaiting fulfilment. Use fulfilled or refunded to pull completed or reversed orders.
3. Filter by date range: GET /orders?start_date=2026-01-01&end_date=2026-01-31 — both parameters accept ISO 8601 dates. Combine with the status filter for targeted reporting queries.
4. Filter by product: GET /orders?product_id={id} — returns all orders that include a specific product, useful for per-product sales reports.
5. Update order status: PUT /orders/{id} with JSON body {"status": "fulfilled"} or {"status": "refunded"}. The response is the full updated order object.

Key Settings

Get the Most Out Of the Orders Endpoint

Pair the orders endpoint with UniLink's order webhooks to build near-real-time fulfilment systems. Configure a webhook on the order.created event and your endpoint receives a POST within seconds of each purchase. Use the webhook payload to trigger your fulfilment logic immediately, then confirm completion by calling PUT /orders/{id} with status: "fulfilled". The API poll can then serve as a reconciliation check rather than the primary trigger, reducing latency and catch-up load.

When pushing orders into accounting software like QuickBooks or Xero, map UniLink's total (cents) to your accounting system's amount field after dividing by 100. Map currency directly — it is already ISO 4217. Store the UniLink id as an external reference in the accounting record so you can look up the original order quickly during audits or when a customer disputes a charge.

The customer object in each order contains name and email. If your CRM or email platform already has a record for this customer, use the email as the matching key to attach the order as a purchase event in the customer timeline. This creates a full purchase history in your CRM without manual data entry, and it enables post-purchase email sequences triggered by specific product purchases.

For refund workflows, the recommended sequence is: initiate the payment reversal in Stripe first, confirm the reversal succeeded, then call PUT /orders/{id} with status: "refunded" to update the UniLink record. Doing it in this order ensures your UniLink order status is only marked refunded when the actual money movement has occurred — preventing situations where the status says refunded but the customer has not received their money.

Troubleshooting

• Every completed purchase creates an order record accessible at https://unilink.us/api/v1/orders within seconds.
• Filter by status, start_date/end_date, and product_id to pull exactly the orders your integration needs.
• Order totals are in cents — divide by 100 before displaying or recording in external systems.
• Line items contain product snapshots that reflect purchase-time details, preserving accurate historical records even if products are later modified.
• Updating status to refunded records the state in UniLink but does not trigger a payment reversal — process the refund in your payment gateway first.