STRAXDocs
strax.pro

API Gateway

Publish your workflows as versioned, documented partner APIs, secured by keys, certificates or your own identity provider, with limits, safe retries, a searchable request log and alerts.

Workflows become products your partners can build on

Exposing a single workflow as an HTTP endpoint answers one request from one system. Partners need more than that. They need a stable, versioned API with a clear contract, predictable limits and a way to be told, well in advance, when something is going away. The STRAX API gateway provides exactly that, on top of the workflows you already run.

An API in STRAX is a versioned group of routes. Each route pairs a method and a path, such as fetching a customer's orders, with the workflow that answers it. The API carries its own name, version, base path, description and contact details, so the developers on the other side know what they are calling and whom to ask. Demo ISP publishes an orders API for its resellers: one version, a handful of routes, each answered by a workflow the operations team already trusts.

The gateway adds control rather than replacing anything. Workflows that were already callable keep their existing addresses, so nothing that works today has to change.

Production traffic stays on production

Every API states the environment it runs in, and a new API runs in production. Its routes use only the workflows deployed there, so a partner's call can never land on a test copy by accident. When a workflow is missing from that environment, the caller receives a clear "temporarily unavailable" answer.

An API can also be given its own dedicated workflow workers and a priority in the queue, so an important partner API keeps its capacity when the rest of the platform is busy. When its workers are saturated, new calls are asked to come back shortly, so the queue never grows out of hand.

Clean addresses, on your own hostname if you like

An API can answer under the console's own address, or on a dedicated hostname of your choosing, such as an api subdomain of your company's domain. A dedicated gateway hostname serves only its APIs, never the console, the application or a portal, so the public surface is exactly what you meant to publish. One hostname can carry several APIs side by side, and one API can answer on several hostnames. Certificates can be uploaded or issued and renewed automatically, in the same way as for portal custom addresses.

Routes use typed path parameters, so an address that expects a number only ever receives a number, and the route editor flags conflicting or overlapping routes while you design them, before a caller ever finds the ambiguity.

Secured with the identity you already run

Each API chooses how callers prove who they are.

For partners who expect it, an API can require mutual TLS. Each partner's client certificate is pinned to its subscription, so a stolen key alone is not enough to call the API, and an expired certificate is refused.

Access can be narrowed further. Routes can require specific scopes, tokens can be required to carry particular claims, and an API can be limited to registered clients, to known caller addresses, or to the countries you choose. A single subscription can be tied to its partner's own network ranges, and individual addresses can be blocked outright. HTTPS can be made mandatory, in which case plain-text calls are refused rather than redirected. The workflow receives the authenticated caller's identity with every request, so it can make its own decisions about who is asking.

Refused calls are not silent. A bad key, a missing scope or a blocked address is recorded in the tamper-evident audit trail, so an unexpected pattern of refusals is visible to the people who need to see it. Errors reach the caller as standard, machine-readable problem responses with a request reference, and a workflow's internal error details are never exposed to the outside.

Keys you can hand out with confidence

API keys are stored only as one-way hashes. A key is shown once, when it is issued, and it cannot be read back from the platform afterwards. When a key has to change, it is rotated with an overlap, so the old key keeps working while the partner switches over and there is no outage on either side. Keys can carry an expiry date, and the partner's technical contact is reminded before it arrives.

Each key can belong to a consumer organisation: the partner, customer or internal team behind it, with its contacts and notes. Usage reports show every organisation's calls by day, key and API over any period, and export to a spreadsheet for account reviews.

Built for partners who retry

Networks fail and partners retry. With idempotent retries, a call repeated with the same idempotency key receives the first answer again instead of running a second time, so a payment or an order is never recorded twice. A retry that arrives while the first call is still running is told to wait, and one that reuses a key for a different request is refused.

When request validation is on, every call is checked against the published contract before any work starts. A malformed request is refused with a precise list of what is wrong, so the partner's developers fix it on their side and your workflows never see bad input.

Long-running work does not have to hold a connection open. A caller can ask for an asynchronous operation, receive an immediate acknowledgement with an address to check, and collect the result when it is ready. Where you allow it, the result is posted to the partner's own callback address when the run ends, signed so the partner can prove it came from you. Frequently requested answers can be cached per caller for a short time, and standard entity tags let clients skip downloads they already hold.

Limits, quotas and a lifecycle partners can plan around

Every API can set how much it will accept: requests per minute, daily and monthly quotas per subscription, concurrent requests, the largest request body, the largest response and how long a caller will wait. Each partner's subscription can carry its own limits and a validity window, and it can be suspended or revoked in one step. A caller who goes over a limit is told so in standard headers, including when to try again. When the gateway runs on several nodes, limits and quotas are shared between them and hold consistently across the whole installation, and configuration changes reach every node almost at once.

APIs move through a clear lifecycle. A new API starts as a draft that callers cannot reach. Publishing makes it live. When a newer version arrives, the old one can be marked deprecated with a sunset date and a note, and every response then tells callers so in standard headers, giving partners time to move. Finally the version is retired, and callers receive a definite answer that it is gone.

A contract for every API

The gateway produces a standard OpenAPI document for each API, built from the routes and the contract each workflow already declares, including the parameter types, the security schemes and the error responses. Download it to share with a partner, or publish it alongside the API so developers can generate their client code directly from it.

See how every API is used

Metrics show request volumes by outcome, response times over time and a per-route breakdown of successes, errors, authentication failures and limited calls. The list of APIs gives an at-a-glance view of recent traffic, error rates and response times, and each subscription shows its partner's usage against its quotas.

A searchable request log records every call with its caller, organisation, outcome, response time and the workflow run it started. Each call carries a standard trace id from the partner's own tracing, or a new one, so a single request can be followed from the partner's system through the gateway and into the workflow. Sensitive headers are always masked, and bodies are kept only when you choose, with the fields you name masked. When a partner reports a problem, the conversation starts from shared facts.

Service-level alerts e-mail the people you name when an API's error rate, response times or authentication failures cross a threshold, when a partner approaches its quota, and again when things recover. A dedicated gateway screen in monitoring brings every API together: live traffic, errors, the busiest callers, recent failures, pending operations, keys about to expire and the state of each gateway node.

Governed like the rest of your configuration

An API is configuration, so it follows the same discipline as everything else in STRAX. Changes are kept in configuration history, and an API can travel in a marketplace package together with the workflows its routes call. APIs and their workflows are promoted from a staging installation to production with the rest of your environment changes, and the promoted workflows are deployed to production workers as part of the same step. Keys, subscriptions, consumer organisations, identity providers and hostnames stay with each installation and are never packaged or promoted.

The AI copilot, and the AI assistants your teams connect to STRAX, can read your APIs and their metrics and propose new ones. A proposed API always arrives as a draft, and a person decides when it is published.

Take the parts you need

The gateway is licensed in parts. The core covers publishing APIs, keys, limits and quotas, the contract, metrics and monitoring. Capabilities such as identity-provider tokens, dedicated hostnames, mutual TLS, idempotent retries, asynchronous operations, the request log and alerts can each be added on their own, so an installation carries only what its partners need.

Where this fits

The gateway builds on workflows and complements the incoming events described in real-time integration. The access controls sit within the wider security and governance model, and every workflow run behind an API is visible in monitoring. To discuss publishing APIs to your own partners, request a quote.