Every partner who wants your data waits for a custom integration.

Your workflows, published as APIs partners can build on.

Give partners, customers and your own apps a proper API to build on, on your own address and with an OpenAPI document they can load into their tools. Each partner gets its own access and its own limits, and every call is logged against the workflow run that answered it. A new partner API is usually live within days, built from workflows your team already runs.

Request a demo → All features →
A partner's app calling a published STRAX API A reseller's app calls the Orders API on the company's own address with its own key. The gateway checks the key, the reseller's per-minute limit and daily quota, and the request against the published contract before anything runs. The customer orders workflow runs on production workers and answers with three orders and the caller's trace id. When the reseller retries with the same Idempotency-Key, it gets the first answer back and the workflow does not run a second time. Every call is written to the request log with the workflow run it started, with secrets masked. A reseller's app calls your own address, with its own key: GET /orders/v1/customers/1043/orders API key checked reseller-cape · subscribed to Orders v1 Within its limits per-minute limit and daily quota, on every server Matches the contract path, parameters and body checked first Workflow runs Customer orders · production workers running Answered 200 · 3 orders · with the caller's trace id Partner retries same Idempotency-Key · first answer, one run Request log every call, with its workflow run 10:12 200 · run 88103 10:14 200 · run 88121 10:14 retry · replayed 10:15 401 · unknown key refused calls are logged too secrets masked, trace ids kept A reseller's app calls your API with its key. Its limits and the contract are checked first. Your workflow runs and answers the reseller. Retries are safe, and every call is logged.

APIs your partners can build on

A reseller wants order status inside its own system, and a customer's finance team wants invoices in theirs. The workflows that already do that work in STRAX are published as a proper API: your own paths, such as /orders/v1/customers/{id}, on your own address or domain, with a version number and an OpenAPI document partners load into their tools. When a new version arrives, the old one carries a deprecation notice and a sunset date that every caller is told about well before it stops answering.

  • Your own paths and versions, on the console's address or on a hostname in your company's domain.
  • An OpenAPI document for every API, with its parameters, security and error responses described.
  • The same workflows serve partners, customers and your own apps.
  • Draft, published, deprecated and retired, with the dates announced to callers in every response.
Live APIs your partners can build on Your paths · a contract · versions
A versioned partner API with its own contract The Orders API is published on the company's own domain with its own paths, such as fetching a customer's orders. STRAX produces its OpenAPI document with the parameters, security and error responses. A reseller's developers load the document into their own tools and make a first call. Later, version 2 is published beside version 1, version 1 is marked deprecated with a sunset date that is sent with every answer, the reseller moves to version 2, and version 1 retires on the date. Orders API · v1 published on your own domain GET /orders/v1/customers/{id}/orders POST /orders/v1/orders OpenAPI document typed parameters for every route security: API key or OAuth2 error responses described A reseller's developers load the document into their own tools routes, types and sign-in read from the document first call against v1 · 200 Orders API · v2 published v2 answers beside v1, on the same address v1 deprecated · sunset on 31 March sunset date sent with every v1 answer the reseller moves to v2 before the date 31 March: v1 retired, callers told Your routes, on your own address, with a contract. Partners load the document into their own tools. Old versions retire on a date callers know.
Your own paths and versions with an OpenAPI document, and an old version that retires on a date every caller was told.

Each partner with its own access and limits

Every partner gets its own way in, so access can be granted, narrowed or withdrawn one partner at a time. Keys are issued per application, or partners sign in with tokens from your own identity provider. Limits are set per partner and hold even when the gateway runs on several servers, so one busy caller cannot use up another's share.

  • API keys per application, shown once, stored only as hashes, rotated with an overlap window and expiring on a date you set.
  • OAuth2 and OpenID Connect tokens from your identity provider, opaque tokens checked by introspection, and scopes per route.
  • Mutual TLS with each partner's client certificate pinned, plus address allowlists, blocked ranges and country rules.
  • Per-minute rate limits and daily or monthly quotas per partner, with usage reports per organisation that export to CSV.
Live Each partner with its own access and limits Keys · tokens · scopes · quotas
Three partner calls checked against their own access and limits The Orders API accepts API keys issued per application, tokens from the company's own identity provider and pinned client certificates, with a read scope on its GET routes and per-minute and daily limits. A reseller's key within its limits is answered. A partner's token without the write scope is refused. The same reseller, having used its daily quota, is told when to try again. Usage is then shown per partner organisation and exported as CSV for the account review. Orders API · access set per API and per partner API key per app, shown once tokens from your identity provider client certificate pinned scope orders.read on GET routes per-minute limit, daily quota limits hold on every gateway server reseller-cape · API key GET /orders/v1/customers/1043/orders 200 · within its limits partner-app · OAuth2 token POST /orders/v1/orders 403 · scope orders.write missing reseller-cape · late in the day GET /orders/v1/orders 429 · daily quota used · retry after midnight Usage by organisation by day, key and API, for any period Cape Resellers · Orders v1 Karoo Traders · Orders v1 Harbour Foods · Orders v2 exported as CSV ready for the account review Each partner calls with its own key or token. Scopes and quotas are checked on every call. Usage per partner, ready for the account review.
Keys, tokens and certificates per partner, scopes per route, and limits that hold on every gateway server.

Safe to retry, and checked before it runs

A partner's system retries when the network drops, and a retried refund must never be paid twice. A call sent again with the same Idempotency-Key gets the first answer back and does not run a second time. Every request is also checked against the published contract before any work starts, so a malformed call is refused with a list of what is wrong and your workflows only ever see clean input.

  • Long jobs answer at once with a status to poll, or with a signed callback when the run ends.
  • Answers to GET requests can be cached for a short time.
  • When the queue is deep, callers are told to come back shortly and are never left waiting for a timeout.
Live Safe to retry, and checked before it runs Idempotent retries · contract checks · long jobs
A retried refund, a refused request and a long job A reseller sends a refund with an Idempotency-Key and the refund is recorded. The reseller's connection drops, so it sends the same call again, and it gets the first answer back while the workflow does not run a second time. A new order that gives the quantity as a word instead of a number is refused against the published contract with the list of what is wrong, and no workflow starts. A long statement job answers at once with a status link, and a signed callback reaches the partner when the run ends. POST /payments/v1/refunds Idempotency-Key r-7781 · from reseller-cape the connection drops, so the reseller sends it again run 90211 · refund recorded retry: the first answer returned, no second run POST /orders/v1/orders quantity: "ten" · from partner-app refused: quantity must be a whole number checked against the contract · no workflow started POST /statements/v1/runs a long job, asked to answer straight away 202 · status link returned at once run finished · signed callback sent to the partner A retried refund is recorded only once. Bad requests are refused before any work starts. Long jobs answer at once and call back.
The same request never runs twice, a malformed one never reaches your workflow, and a long job never holds the caller's connection.

Every call traced to the run behind it

When a partner reports a failed call, your team finds it in the request log by time, partner or the partner's own trace id, and opens the workflow run that answered it. Sensitive headers and fields are masked in the log. E-mail alerts reach the people you name when error rates, response times, sign-in failures or quota use cross a threshold, and a live monitoring screen shows every API together.

  • A Try it console sends test calls to any route through the real gateway.
  • An API that targets production runs only on production workers.
  • APIs and their workflows move from staging to production with the rest of your configuration.

Request a quote for the API gateway →

Live Every call traced to the run behind it Alert · request log · run · Try it · promote
From an alert to the failing run, and a checked fix An e-mail alert reports that the Orders API's error rate crossed its threshold. The failed call is found in the request log by the reseller's own trace id, with the authorisation header masked, and it links to the workflow run that answered it, where the stock check step timed out. After the fix, a Try it call through the real gateway on staging creates an order. The API and its workflows are then promoted to production, where they run only on production workers, and the alert reports recovery. E-mail alert sent to the people you named Orders API · error rate over threshold since 10:40 · reseller-cape affected Request log search: the reseller's trace id 4bf92f 10:42 POST /orders/v1/orders · 502 Authorization: masked · run 90413 Workflow run 90413 opened from the log entry steps 1 to 3 finished step 4: the stock check timed out Try it · through the real gateway after the fix, on staging POST /orders/v1/orders · key reseller-test 201 · order created · run 90518 Staging to production the API moves with its workflows Orders API v1 and 3 workflows · production workers only promoted · the alert e-mails that errors are back to normal An alert, then the call found by trace id. The log opens the workflow run that failed. Tested through the gateway, then promoted.
An alert, the call found by the partner's own trace id, the run behind it, and a fix tested through the gateway before it goes live.

Keep exploring

More in Connect

One hub keeps every system on the same record.

Billing, CRM, provisioning and support all show the same customer, order and asset, updated automatically within seconds and with nothing re-keyed.

Integration engine →

Databases, APIs and a growing list of SaaS profiles.

SQL Server, MySQL and PostgreSQL with change capture, any REST or OpenAPI service, webhooks, and ready-made SaaS profiles from the marketplace.

Connectors →

A working integration, installed from a catalogue.

Ready-made bundles of systems, mappings, workflows, reports and portals, free and premium, each one screened by STRAX before it can run.

Feature Marketplace →

See it on your own systems.

A demo takes about an hour and runs against systems like yours, starting with the ones you would connect first.

Request a demo → Request a quote