Publish any flow as a versioned API endpoint.

Put any flow behind a stable public endpoint at /v/your-org/your-endpoint, with its own contract, keys, and request log.

How a request flows

API endpoints for integrations, without building a service.

An endpoint replaces the bespoke API you would otherwise build and host for each partner. Each consumer gets its own key, idempotency is tracked per caller, and the endpoint answers inline or accepts the request and finishes asynchronously. When a carrier, 3PL, or ERP changes, publish a new version of the flow: every caller keeps the same URL, contract, and key.

Consumer

Client ERPfe_live_7Hq2…k29Key bound to one endpoint. Revoke it without touching other callers.

Endpoint

POST /v/your-org/create-orderAuthorization: Bearer fe_…Idempotency-Key: PO-88123Contract checked before the flow starts

Flow · v4 published

  1. transform.map
  2. orderly.order.ingest
  3. respond
Swap in v5 and the URL stays the same.

Response

200 OK · sync
{ "order_id": "ord_…",
  "external_id": "PO-88123" }
202 Accepted · asyncStatus URL, plus a signed callback when the flow finishes.

Contracts

Seven contracts: a unified API for orders, shipments, inventory, and invoices.

Requests are validated against one of seven contracts, from orders.create to invoices.list or your own, before a flow starts. A standard contract fixes the method and the request and response shapes, so every caller sees the same API whichever system answers behind it.

Orderly generates an OpenAPI 3.1 description of every active endpoint you can hand to callers or load into an API client to generate code.

  • orders.createPOSTCreate an order from an Orderly-shaped body
  • orders.getGETFetch one order by external id
  • shipments.getGETFetch one shipment by external id or tracking number
  • shipments.listGETList shipments, paged
  • inventory.listGETList inventory levels, paged
  • invoices.listGETList invoices, paged
  • customYour choiceYour own request and response JSON Schemas

Callers

Endpoint keys, idempotency, and rate limits for every caller.

A key for every consumer

Each consumer gets its own fe_ key that can only invoke, bound to one endpoint, with an optional expiry. It is shown once, and revoking it cuts that caller off from the next request without touching anyone else.

Safe to retry

A retried request with the same Idempotency-Key from the same caller returns the original result instead of starting a second run, so a nervous client cannot create the same order twice.

Rate limits per caller

Set how many requests each caller may make per minute, from 1 to 100,000. Callers over the limit get a 429 with Retry-After and rate-limit headers, not a silent drop.

Responses

Sync and async API responses with signed callbacks.

The flow's Respond step becomes the HTTP response. Test it before anyone calls: a dry test validates a sample payload against the contract, dry-runs the flow, and shows the response the endpoint would send, without creating a run.

Sync or async

A sync endpoint waits up to 25 seconds and answers with your Respond step. If the flow needs longer, the caller gets a 202 and a status URL. An async endpoint answers 202 right away.

Signed callbacks

Set a callback URL and the final result of every async or timed-out request is posted there, signed with a secret shown once, so the caller can verify it came from you.

Every request on record

Each request is logged with its caller, status, latency, and the run it started, and kept for 90 days. That record is the audit trail and the basis for metering.

What you build with it

Integration endpoints for 3PLs and fulfillment teams.

Endpoints pair naturally with partner templates: a key issued for a client works only on that client's endpoint.

3PLs

Claims intake endpoint for your clients

Publish one endpoint, /v/your-3pl/claims, and give each client its own key. A damage report is checked against the contract, mapped to the right shipment, and opened as a draft claim your team reviews before anything is filed.

  1. endpoint
  2. transform.map
  3. orderly.claim.create
  4. respond

Fulfillment operations

Check stock before you accept an order

A client posts an order to your endpoint. The flow reads on-hand, reserved, and available quantity for the SKU, answers with a clear rejection when stock is short, and ingests the order when it is not. A client flow only ever sees inventory synced from that client's own connections.

  1. endpoint
  2. orderly.inventory.lookup
  3. branch
  4. orderly.order.ingest
  5. respond

Virtual endpoints are $19/mo each, with 10 included on Flows Pro and 25 on Flows Dedicated. Calls draw on the plan's monthly pool of endpoint requests; see Flows pricing. Read the virtual endpoints docs ↗

Questions

API endpoints FAQ.

Do we have to replace our WMS, ERP, or store?

No. Flows calls your systems over HTTPS with Basic auth or OAuth 2.0 client credentials, exchanges files and EDI with trading partners over SFTP, FTPS, or AS2, and publishes endpoints your systems can call. It works with what you run today.

What happens when a request does not match the contract?

It is rejected with a 422 before any flow runs, and the request log records why. On the way out, a response that does not match the response schema is replaced with a 502, so callers can rely on the shape the contract promises.

Can we change the flow behind an endpoint without breaking callers?

Yes. The endpoint always answers with the flow's published version. Publish a new version and every caller keeps the same URL, contract, and key. Runs already in progress finish on the version they started with.

Publish your first endpoint

Stop building a bespoke API for every partner.

Tell us who needs to call you and what they send. We will show you the flow and the endpoint contract behind it.

Talk to us about API endpoints

We use these details to reply to you. Privacy notice