Logistics and transport
Partners connected by contract, events that are not lost.
Every partner calls a declared API and authenticates with a certificate or a key; shipment updates leave as events and signed webhooks; existing systems stay behind, gRPC included.
What Flexway decides, on your infrastructure
Who calls, what Flexway decides, what is called: each route is a use case of your sector. Dashed: what is coming.
Architecture for logistics and transport: shippers, carriers and tracking apps go through Flexway, on your infrastructure. Flexway identifies each partner by its key or certificate, publishes to the broker a status received over HTTP, sends signed webhooks from the broker to partner systems, translates REST to gRPC and holds a deadline per operation, in front of your TMS and warehouses, Kafka or AMQP and your gRPC services. An upstream called that does not answer in time gives a 504, then the circuit breaker opens.
- Shippers
- The shippers: identified by an API key or a client certificate bound to a tenant, they call your TMS and warehouses through Flexway.
- Carriers
- The carriers: their updates get a 202 at once; the status is published on your broker, then delivered as signed webhooks.
- Tracking apps
- The tracking apps: their REST calls reach your gRPC services, translated by Protobuf descriptors.
- Broker events
- A broker whose messages Flexway consumes to deliver them to your partners as signed webhooks.
- Partner key or certificate
- Flexway checks who is calling (OIDC token, API key or client certificate) and reads the tenant from the identity; no valid identity: 401.
- Sync to async boundary
- Flexway answers 202 at once and publishes what follows on your broker: the boundary between synchronous and asynchronous.
- Signed webhooks
- Flexway delivers your events to your partners as signed, replayable webhooks.
- Deadline per operation
- Each operation has its own deadline budget, with a circuit breaker and retries limited to idempotent methods.
- REST to gRPC
- A REST call is translated into gRPC by the Protobuf descriptors: your gRPC service becomes callable over REST.
- TMS and warehouses
- Your TMS and warehouses: called under deadline budget and circuit breaker, with safe retries.
- Kafka, AMQP
- Your Kafka, AMQP, MQTT and NATS brokers: Flexway publishes on them under an AsyncAPI contract, in a CloudEvents envelope.
- gRPC services
- Your gRPC services: served over gRPC, gRPC-Web and REST translated by Protobuf descriptors.
- Partner systems
- Your partners' systems: they receive your events as signed, replayable webhooks.
- Line: one route
- Interchange: shared decision
- Request
- Event
- Refusal
- Your infrastructure
- Partner key or certificatebound to a tenant
- Sync to async boundarystatus published, 202 reply
- Signed webhooksreplayable, to partners
- Deadline per operationcircuit breaker, safe retries
- REST to gRPCvia Protobuf descriptors
1A carrier sends a delivery status
What Flexway decidesThe gateway publishes the status to the broker and replies 202; then, from the broker, the shipper receives a signed webhook.
What is protectedNo status lost: the webhook is replayed on failure.
2A tracking app queries a gRPC service
What Flexway decidesThe REST request is translated to gRPC through Protobuf descriptors.
What is protectedExisting systems stay in place, with no rewrite.
3A partner slows down
What Flexway decidesThe upstream is called but does not answer within its deadline: 504 upstream_timeout; past the failure threshold, the circuit breaker opens (503); only idempotent methods are retried.
What is protectedA slow partner does not block the others.
Shippers
The shippers: identified by an API key or a client certificate bound to a tenant, they call your TMS and warehouses through Flexway.
Routes through here
Carriers
The carriers: their updates get a 202 at once; the status is published on your broker, then delivered as signed webhooks.
Routes through here
Tracking apps
The tracking apps: their REST calls reach your gRPC services, translated by Protobuf descriptors.
Routes through here
Broker events
A broker whose messages Flexway consumes to deliver them to your partners as signed webhooks.
Routes through here
Partner key or certificate
Flexway checks who is calling (OIDC token, API key or client certificate) and reads the tenant from the identity; no valid identity: 401.
- Decision
- bound to a tenant
- Catalogue features
- API keys and client mTLS as first-class identities ; An OpenAPI 3.1 contract loaded; what is served is derived from it
Routes through here
Sync to async boundary
Flexway answers 202 at once and publishes what follows on your broker: the boundary between synchronous and asynchronous.
- Decision
- status published, 202 reply
- Catalogue features
- Mediation of the synchronous to asynchronous boundary
Routes through here
Signed webhooks
Flexway delivers your events to your partners as signed, replayable webhooks.
- Decision
- replayable, to partners
- Catalogue features
- Signed, replayable outgoing webhooks
Routes through here
Deadline per operation
Each operation has its own deadline budget, with a circuit breaker and retries limited to idempotent methods.
- Decision
- circuit breaker, safe retries
- Catalogue features
- Timeout budget per operation ; Circuit breaker with half-open state ; Retries limited to idempotent methods
Routes through here
REST to gRPC
A REST call is translated into gRPC by the Protobuf descriptors: your gRPC service becomes callable over REST.
- Decision
- via Protobuf descriptors
- Catalogue features
- REST to gRPC translation through Protobuf descriptors
Routes through here
TMS and warehouses
Your TMS and warehouses: called under deadline budget and circuit breaker, with safe retries.
Routes through here
Kafka, AMQP
Your Kafka, AMQP, MQTT and NATS brokers: Flexway publishes on them under an AsyncAPI contract, in a CloudEvents envelope.
- Catalogue features
- Kafka publishing under contract, CloudEvents envelope ; AMQP(S) and MQTT
Routes through here
gRPC services
Your gRPC services: served over gRPC, gRPC-Web and REST translated by Protobuf descriptors.
- Catalogue features
- REST to gRPC translation through Protobuf descriptors
Routes through here
Partner systems
Your partners' systems: they receive your events as signed, replayable webhooks.
- Catalogue features
- Signed, replayable outgoing webhooks
Routes through here
What the sector requires
- EDI · partner APIsPartner APIs under contract
- Only declared operations are served; each partner has its key or certificate, bound to a tenant.
- TrackingStatuses that arrive
- The gateway handles the synchronous to asynchronous boundary; partners receive signed, replayable webhooks.
- Existing systemsThe existing stack behind, without a rewrite
- REST to gRPC translation, takeover of an existing gateway configuration.
- ContinuityA slow partner does not block the others
- Timeout budget per operation, circuit breaker, retries limited to idempotent methods.
How Flexway answers
Partner APIs under contract
- API keys and client mTLS as first-class identitiesDelivered · v0.1.0
- An OpenAPI 3.1 contract loaded; what is served is derived from itDelivered · v0.1.0
Statuses that arrive
- Mediation of the synchronous to asynchronous boundaryDelivered · v1.5.0
- Signed, replayable outgoing webhooksDelivered · v1.5.0
The existing stack behind, without a rewrite
- REST to gRPC translation through Protobuf descriptorsDelivered · v0.2.0
- Import of an existing gateway's configuration, with a coverage reportDelivered · v1.1.0
A slow partner does not block the others
- Timeout budget per operationDelivered · v0.1.0
- Circuit breaker with half-open stateDelivered · v0.1.0
- Retries limited to idempotent methodsDelivered · v0.1.0
State in Flexway's latest published release; a feature is marked delivered only with its release.
What Flexway does not do
- Flexway does not convert EDI formats: it exposes and protects the APIs that replace or wrap them.
Let's talk about your gateway
Flexwiz is a young company: you talk directly with the person who founds it. Tell us what you want to run through Flexway. We talk about your infrastructure and your digital sovereignty requirements.
Online booking is coming soon; until then, an e-mail is enough.