Arub is in open beta and free to use. Accounts need an invite code while we scale. Get one
Arub
Sign in Create account
Developers

Everything the app does,
your code can do too

The Shipping Hub screens are built on the same layer the API exposes. Orders, rates, labels, batches, customers, products, inventory and reports — all reachable with a key.

Request API access Browse endpoints
OpenAPI description MCP server included Every call logged
API reference
The built-in API reference page listing endpoints, parameters and example responses.
Authentication

One key, three ways to send it

API keys are issued per account from the Settings screen. There is no OAuth dance to implement and no session to keep alive — a key is the whole story.

List awaiting orders 
# Bearer token is the recommended form
curl -H "Authorization: Bearer $ARUB_KEY" \
     "https://ship.arub.com/v1/orders?status=awaiting_shipment&per_page=50"
Quote and buy a label 
# Rates first, then buy the one you want
curl -H "X-API-Key: $ARUB_KEY" \
     "https://ship.arub.com/v1/orders/501311/rates"

curl -X POST -H "X-API-Key: $ARUB_KEY" \
     -H "Content-Type: application/json" \
     -d '{"rate_id":"ups_ground_saver_02"}' \
     "https://ship.arub.com/v1/orders/501311/label"

Keys are scoped, not superuser

A key acts as an account, and every request is checked against the same per-feature permissions the web app uses. A key that cannot buy labels in the interface cannot buy them over the API either.

Endpoints

A shape you can guess

Collections page and filter the same way, single resources take an id, and actions that change something are POSTs on a named sub-path. A machine-readable description of the whole surface is served from your own instance.

GET/v1/orders — filter by status, channel, tag, search, date range
GET/v1/orders/{id} — the full order with items, address and history
POST/v1/orders — create a manual order
PUT/v1/orders/{id}/address — correct a destination
PUT/v1/orders/{id}/package — box, weight, dimensions, declared value
GET/v1/orders/{id}/rates — live quote across connected carriers
POST/v1/orders/{id}/label — buy, returning tracking and a label URL
POST/v1/orders/{id}/status — hold, release, cancel, mark shipped
POST/v1/batches — create, add orders, buy, close
GET/v1/shipments — labels bought, with tracking state
DELETE/v1/shipments/{id} — void a label with the carrier
GET/v1/customers, /v1/products, /v1/inventory, /v1/tags
GET/v1/reports/{report} — the same data behind the report screens
GET/v1/openapi.json — the description of everything above

Replace the host with your own instance address. The reference page inside the app documents every parameter and shows a live example response for your account.

MCP

Point an AI agent at your warehouse

Arub ships an MCP server in front of the same API, exposing the useful operations as typed tools. Connect it to an assistant and you can ask for the state of the queue, or have it work through exceptions, in words rather than requests.

  • Around thirty curated tools covering orders, rates, labels, batches, tracking, customers, products, inventory and reports.
  • Two transports. Run it locally over stdio, or host it and pass a key per request.
  • Same permissions. The agent is bound by the key it was given, so read-only really is read-only.
mcp config 
{
  "mcpServers": {
    "arub-ship": {
      "command": "php",
      "args": ["mcp-stdio.php"],
      "env": {
        "ARUB_SHIP_KEY": "your-api-key"
      }
    }
  }
}

Ask it things like what is stuck in the queue today or quote order 501311 and tell me the cheapest ground service.

Webhooks

Tracking that arrives instead of being polled

Carrier scan events come in over webhooks and are routed to the right shipment automatically, whether the label was bought on an Arub account or on your own.

Inbound from carriers

USPS, UPS and FedEx events are received, matched to the shipment and reflected on the order without a polling loop.

Your own endpoint

Bring your own carrier account and you get a private hook address of your own, so events land in your instance and nowhere else.

Buyer notifications

Shipment and tracking emails to your buyers are per-instance switches, branded with your logo and edited visually.

Operations

Keys, logs and limits

API behaviour
ItemHow it works
Issuing keysCreated by an account owner from Settings. Shown once, stored hashed, revocable at any time.
Sending a keyAuthorization: Bearer, X-API-Key, or an api_key query parameter for tools that cannot set headers.
PermissionsA key inherits the granular permission set of the account it belongs to. Read-only keys are a permission choice, not a separate key type.
Request logEvery call is recorded with its endpoint, status and timing, visible in the app so you can see what your integration actually did.
ErrorsJSON, always. A failure carries the carrier's or marketplace's own message rather than a generic code.
Rate limitsNo hard cap during beta. Carrier and marketplace quotas still apply upstream and are surfaced rather than hidden.
VersioningThe path carries the version. Breaking changes get a new one; additive fields do not.
SDKA PHP client is provided and the MCP server is built on it, so the two never drift apart.

Build against it

Beta accounts include API and MCP access. Tell us what you want to automate and we will point you at the right endpoints.

Request API access See the app