API gateway patterns

You design APIs in Development; they travel with a version to Acceptance and Production. Connections do not: you set them up per environment, with that environment's keys.

Under Connections you choose General HTTP API: base URL, key and what Flow may do with it. The key stays encrypted on the server and can never be read back. Read only means: Flow only does GET here.

Under Security you create a policy. One method suffices for a consumer: a partner with an API key, an application with OAuth 2.0 (client credentials) or a webhook that signs its message with a shared secret (HMAC, like GitHub and Stripe). Public is off: every call should be traceable.

Say in which header the sender puts its signature, with which prefix, and the shared secret. Flow recalculates the HMAC over the received body itself; if it does not match, the call does not get in.

The policy hangs on the API, not on every endpoint: all endpoints inherit it and may only tighten it (fewer methods, more permissions, a lower limit). Also switch on Public documentation: then anyone can read the OpenAPI description, but nobody can call the API without signing in.

Not every endpoint needs a workflow. Forward to connection passes the request on to the existing system, with the key from the connection. The consumer sees your address and your security, never the key or the address of the system behind it.

On the right under Try it you call the endpoint like a consumer. Without a key, token or signature the gateway answers 401; the stock system notices nothing.

A partner system calls the same endpoint and signs its message. Under Runs → Live traffic you see both calls: the 401 and the 200, with how the consumer signed in. IP addresses are stored truncated.

Because Public documentation is on, the OpenAPI link on the API opens for anyone, without a key: partners' developers build against it without you creating an account for them.