Providers

Providers let your app plug directly into Stok.ly's fulfilment and finance workflows, for example, generating a shipping label through a carrier your app integrates with, syncing orders to an accounting platform, or connecting a custom sales channel.

Unlike extension points, which render your app's UI inside a Stok.ly page, providers work the other way around: Stok.ly calls out to your app to perform an action as part of a normal workflow, such as when a goods out note is dispatched or an order is invoiced.

🚧
Coming in a future phase
Providers aren't available yet — they're part of the next phase of platform integrations. This page is an early look at what's planned and will be filled in as each provider contract is finalized.

Provider types

Three categories of provider are planned:

Type	Description
Shipping providers	Generate shipping labels and rates through a custom carrier.
Channel providers	Connect a custom sales channel (e.g. a marketplace or storefront) to Stok.ly.
Accounting providers	Sync invoices, and other financial data to a custom accounting platform.

Declaring a provider in your manifest

Providers your app implements will need to be declared in your app's manifest, alongside a URI Stok.ly can call to invoke them. That URI is subject to the same validation as your webhook and OAuth redirect URIs, HTTPS only, no localhost or private/internal addresses, no loopback addresses, no internal hostnames, and no credentials embedded in the URI.

What's consistent across every provider

A few things apply regardless of which provider type you're implementing

Versioning. Provider contracts are versioned, so Stok.ly can evolve them over time without breaking apps already relying on an existing version.

Timeouts. Calls to your provider are time-limited. If your app doesn't respond in time, Stok.ly treats the call as failed and handles it accordingly rather than blocking the workflow indefinitely.

Error handling. If your provider fails, the person using Stok.ly needs to see something useful — including which app's provider failed — rather than a generic error with no attribution.

Request signing. Every request Stok.ly sends to your provider is signed, so your app can verify it genuinely came from Stok.ly rather than a third party impersonating the platform.