Integration Reference

How Claim Core connects to your warehouse system, what it needs from you, and what happens automatically.

Integrations marked Beta are built and tested against the system's published API and are not yet running for a customer in production. Raise a support ticket before you connect a live account and we will watch the first days with you.

Helm

Claim Core is an app in the Helm app store. Helm gives Claim Core what it needs at install, so there are no API keys to create and no webhook addresses to copy.

1

Install Claim Core from the app store

Open the Claim Core listing in the Despatch Cloud partners app store, choose Install for Helm and enter your Helm company number (the number after /companies/ in your Helm address bar). You will be asked to allow the install while signed in to Helm.
2

Confirm the connection in Claim Core

Open Claim Core from the Helm menu and click Connect now. Sign in as an organisation administrator, or create a free account, and confirm which Claim Core organisation this Helm company belongs to. Claim Core then reads your company from Helm and sets up despatch updates on its own.
3

Map each brand to its sales channel

In Helm your clients are sales channels of one company. Under Settings → Integrations → Helm, tick the brands that ship through Helm, then open each brand and pick its channel from the list. A brand that is the only one on the connection needs no channel. This is what keeps every brand's orders and searches separate.
4

Check it is working

Use Test connection on the Helm integration page, then Send a test delivery to confirm despatch updates reach Claim Core. Despatched orders then appear in Claim Core within about a minute of leaving the warehouse.

Orders despatched before the connection was made are not sent by Helm. Ask support to import your recent history if you want to raise claims against those orders.

On a claim, Helm supplies the order and its lines, tracking with the carrier, the picker, packer and dispatcher, pack-station video, whether the order is on hold, the serial numbers scanned into the parcel, its picking jobs with totes and the picker, and the files held against the order. It does not report which lot or batch shipped, and its API has no return-label or file-upload endpoint yet, so return labels are uploaded by your team.

Helm Legacy

Earlier Helm systems run on a per-customer address such as yourcompany.myhelm.app and connect a little differently.

1

Install from your Helm app store

In your Helm control panel, open Apps, find Claim Core and install it. Helm sends you to Claim Core to confirm which organisation the install belongs to.
2

Give Claim Core an API user

Opening Claim Core inside Helm usually hands it an API token automatically. If order lookups do not work, create a Helm user for Claim Core with the Supervisor role and enter its email address and password on the integration page.
3

Add the despatch webhook in Helm

Copy the webhook address and secret from the integration page and add them to Helm's despatch notifications, sending the secret as the X-Webhook-Token header.
4

Map each brand to its fulfilment client

Open each brand and pick its Helm fulfilment client. Until a brand is mapped, live order searches for it are blocked so one brand can never see another's orders.

On a claim, Helm Legacy supplies the order and its lines, tracking with the carrier, the picker, packer and dispatcher from time tracking, and pack-station video. Its public API has no holds, serial numbers, lots, totes or order attachments, so the claim page marks those as not supported by Helm Legacy; return labels are uploaded by your team.

ShipHero Beta

ShipHero has no app store. The connection is a developer user you create in ShipHero, whose refresh token Claim Core keeps and renews its own access from. It works for a 3PL's ShipHero account, where each client is a customer account, and for a brand's own account.

1Create the developer user. In ShipHero open My Account, then Developer Users, and choose Add a 3rd Party Developer. ShipHero shows a bearer token and a refresh token once; copy the refresh token.
2Add the connection in Claim Core. Under Settings → Integrations choose ShipHero, paste the refresh token and save. Claim Core confirms the connection and lists your customer accounts.
3Map each brand to its customer account. Tick the brands that ship through ShipHero, then open each brand and pick its customer account. On a 3PL account every brand needs one, and the despatch webhook is registered per customer account; a brand on its own ShipHero account needs no mapping. This is what keeps every brand's orders and searches separate.
4Check it is working. Use Test connection, then fulfil an order in ShipHero: it appears in Claim Core within a minute. Claim Core registers a Shipment Update webhook per customer account and, because ShipHero does not guarantee every delivery, also reads recent fulfilled orders back every hour.

On a claim, ShipHero supplies the order, its lines with serial numbers and lots, tracking with the carrier's delivered and collected flags, the order's holds, its tote picks, its attachments, the order's history, and the shopper's contact details. It does not expose the picker, packer or dispatcher for an order, a proof-of-delivery image, or pack-station video; the claim page marks those as not supported by ShipHero rather than missing. Two switches on the connection: the carrier and service for free return labels, and whether claim evidence is sent to the ShipHero order as an attachment.

Mintsoft Beta

Mintsoft has no app store. The connection is an API key for a Mintsoft user, set to never expire, which Claim Core keeps. It works for a 3PL's Mintsoft account, where an administrator's key sees every client and each brand is mapped to its client, and for a brand's own client login, whose key sees one client.

1Get the API key. Create a Mintsoft user for Claim Core (an administrator for a 3PL, a client user for a brand). On api.mintsoft.co.uk/swagger/ui/index expand Auth and post that user's username and password; the response is the key. Then in Mintsoft open Settings, then Client User Settings, find the user and choose Set API Key to Never Expire.
2Add the connection in Claim Core. Under Settings → Integrations choose Mintsoft, paste the key and save. Claim Core confirms the connection and says whether the key is an administrator's or a client user's.
3Map each brand to its client. Tick the brands that ship through Mintsoft, then open each brand and pick its client from the list. On an administrator's key every brand needs a client before its orders arrive; on a client user's key the connection's only brand needs none.
4Check it is working. Use Test connection, then despatch an order in Mintsoft: it appears in Claim Core on the next scheduled read (hourly on a standard deployment), and can be looked up live by its order number straight away. Mintsoft has no account-level webhooks, so nothing is registered there.

On a claim, Mintsoft supplies the order, its lines with the batches and serials scanned at packing, tracking with the courier service, each shipment's parcel numbers, the box packing list, who despatched and who packed the order, holds (pack and hold, awaiting payment, fraud, and a locked order), stock allocations as picking records, the documents held against the order, its notes, and the shopper's contact details. It does not expose the picker, a proof-of-delivery image, or pack-station video, so the claim page marks those as not supported by Mintsoft. Returns are recorded in Mintsoft and receipt is read back, but Mintsoft does not issue return labels, so the team uploads one. Documents are shown to your team through Claim Core (Mintsoft serves them through its API rather than by link), only for the order on the claim. Claim evidence can be sent to the order as a document, and a note is left on the order when a return is requested. Where Mintsoft has removed a shopper's personal details from an old order, the claim shows the order without them.

Clarus Beta

Clarus has no app store. The connection is a dedicated API user in your Clarus tenant, whose email and password Claim Core keeps and signs in with (an API token can be pasted instead). It works for a 3PL's tenant, where each client is an account, and for a brand's own tenant.

1Create the API user. In Clarus, under Settings then Users, create a user for Claim Core alone. Clarus allows one session per user, so nobody should sign in with it.
2Add the connection in Claim Core. Under Settings → Integrations choose Clarus, enter the subdomain and the user's details and save. Claim Core confirms the connection and lists the tenant's accounts.
3Map each brand to its account. Tick the brands that ship through Clarus, then open each brand and pick its account. A tenant with a single account needs no mapping for its only brand; a tenant with several needs one per brand. This is what keeps every brand's orders and searches separate.
4Register the despatch automation. Press Register in Clarus, or add an automation in Clarus yourself: when a sales order is completed, send a webhook (POST) to the address shown on the connection page. The address carries the secret Claim Core checks on every delivery. An hourly reconciliation also reads recently despatched orders back.

On a claim, Clarus supplies the order and its lines, the delivery address with the shopper's email and phone, the carrier with a tracking number and link per package, the despatch date, the picking record with the tote and bin, the serial numbers scanned at pick, and the picker, packer and dispatcher where the tenant exposes them. It does not expose the carrier's delivery status, proof of delivery, pack-station video, holds on an order, the lot that shipped, or files against an order, and it issues no return labels; the claim page marks those as not supported by Clarus.

Deposco Beta

Claim Core is an application in the Deposco Developer Portal. You install it in your Deposco environment from its install link; Deposco then issues a refresh token for the installation, which is copied into your Claim Core connection. It works for a 3PL's Deposco account, where the installation can see every tenant company (business unit) and each brand is mapped to its company, and for an installation restricted to one company, whose only brand needs no mapping.

1Add the connection in Claim Core. Under Settings → Integrations choose Deposco. The connection page shows the install link.
2Install Claim Core in Deposco. Open the install link, enter your Deposco tenant code, choose Production (or a sandbox) and your region, and log in as a Deposco user in a group with the API application admin permission. Choose the company the application may see (the primary company for every business unit, or one tenant company), tick the scopes and approve.
3Paste the refresh token. Deposco shows the installation's refresh token in the developer portal, not in Deposco itself; Claim Core support copies it into the connection, together with the region. Save, and Claim Core confirms the connection and lists the companies it can see.
4Map each brand to its company. Tick the brands that ship through Deposco, then open each brand and pick its company. An installation that sees every business unit needs a company on every brand before its orders arrive; one restricted to a single company needs none for its only brand.
5Check it is working. Use Test connection, then ship an order in Deposco: it appears in Claim Core on the next scheduled read (hourly on a standard deployment), and can be looked up live by its order number straight away. Deposco's API has no webhook endpoints, so nothing is registered there.

On a claim, Deposco supplies the order, its lines with unit price, cost, lot and expiry, each shipment with its carrier, service, tracking number, packages and weight, each shipped package with its own tracking number, size, weight, contents, lots, serial numbers and any quantity recorded damaged at packing, the order's notes, the user who created the shipment, whether the order is on hold, and the shopper's contact details. It does not expose picks, the picker or packer, a proof-of-delivery image, pack-station video, or files against the order, so the claim page marks those as not supported by Deposco. Returns are opened in Deposco as customer returns and receipt is read back, but Deposco does not issue return labels, so the team uploads one. Claim evidence is sent to the order as a note carrying the file's link.

A refresh token stops working if the Claim Core application is edited in the Deposco Developer Portal; every customer then reinstalls it. Deposco also rate-limits the application, at four requests a second on its lower platform tiers, so the claim page reads the details of at most three shipments per order.

Linnworks Beta

Claim Core is an application in the Linnworks Developer Portal. You install it into your Linnworks account from an install link Claim Core makes for the connection; Linnworks then sends the installation's token to Claim Core, so there is nothing to paste. One installation is one Linnworks account. A brand that is the only one on its connection needs no mapping; a 3PL running several brands through one account pins each brand to its sales channel.

1Add the connection in Claim Core. Under Settings → Integrations choose Linnworks. The connection page shows its install link, which stays valid for seven days; a new one can be made at any time.
2Install Claim Core in Linnworks. Open the install link, log in to Linnworks as a user who can see processed orders, order details and returns, and approve the application. Linnworks sends the token to Claim Core and the connection confirms itself. If Linnworks shows you the token instead, paste it on the connection page and save.
3Map brands. Tick the brands that ship through Linnworks. A single brand needs nothing more. With several brands, open each brand and pick its sales channel from the list Linnworks reports; a brand without a channel gets no orders, since two brands on one account cannot be told apart otherwise.
4Check it is working. Use Test connection, then process an order in Linnworks: it appears in Claim Core on the next scheduled read (hourly on a standard deployment), and can be looked up live by its reference straight away. Linnworks has no webhooks, so nothing is registered there.

On a claim, Linnworks supplies the order and its lines with unit price and cost, batch numbers with expiry and the serial numbers scanned out, the courier, service and tracking number, each parcel of a split order with its own tracking number and contents, the order's audit trail (who processed it and when, read as the dispatcher), its notes, whether it is on hold or parked, and the shopper's contact details and address. It does not expose picks, the picker or packer, a proof-of-delivery image, pack-station video, or files against the order, so the claim page marks those as not supported by Linnworks. Returns are booked in Linnworks as RMAs and accepted, with a return label PDF from the courier where it can print one; receipt is read back. Claim evidence is sent to the order as an internal note carrying the file's link.

A token stops working when Claim Core is uninstalled from the Linnworks account; reinstalling from the install link issues a new one. Linnworks rate-limits each endpoint at 150 calls a minute, and a session lasts 20 minutes of inactivity, which Claim Core renews by itself.

Which Helm do I have?

If you sign in at helmwms.app and your address bar shows /companies/ followed by a number, you are on Helm. If you sign in at an address ending .myhelm.app, you are on Helm Legacy. The integration page in Claim Core shows which one it is connected to.

Security

Every despatch update is authenticated. On Helm the signature uses a secret Claim Core generates and registers with Helm for you; on Helm Legacy it is the secret shown on the integration page; on ShipHero it is the secret ShipHero issues to Claim Core when the webhook is registered; on Clarus, which signs nothing, it is the secret inside the registered address, and when Clarus names its tenant in the delivery it must be this connection's subdomain. Mintsoft, Deposco and Linnworks send no despatch updates, so there is nothing to sign: Claim Core reads recent despatches from each of them itself with its own credential. Updates that fail these checks are rejected, and a redelivered ShipHero or Clarus message is acknowledged once.

API keys, passwords and tokens are encrypted before they are stored, and are only decrypted when Claim Core uses them. Disconnecting deletes them from Claim Core immediately and, on ShipHero and Clarus, removes the despatch webhook Claim Core registered; your claims and order history are kept.