API access governance for REST, SOAP, GraphQL and gRPC
The credential problem does not stop at the database. A payment API, a partner SOAP endpoint and an internal gRPC service all end up with a shared token in a config file and no record of who called what. AccessFlow governs outbound API calls through the same checkpoint it uses for queries: a registered connector holds the credential, a parsed operation catalog says what may be called, and every call is scored, reviewed and audited.
Register the API, not the credential
An admin registers a connector: a name, a protocol — REST, SOAP, GraphQL or gRPC — a base URL, any default headers, a per-call timeout, and an auth method. Auth can be an API key, a bearer token, basic credentials, OAuth2, a custom header, or mTLS. Whatever the secret is, it is AES-256-GCM encrypted before storage and never returned by any endpoint; read views expose only which method is configured and whether a credential exists. From that point on nobody on the team needs the token, because nobody is the one making the call.
OAuth2 connectors go a step further and mint the token themselves rather than relying on one pasted in by hand. AccessFlow supports the client-credentials, refresh-token and resource-owner-password grants, caches the token until just before it expires, and refreshes it on expiry or on a single upstream 401. A test-connection probe checks reachability at setup time — and for OAuth2 connectors performs a live token fetch, so a wrong token endpoint surfaces during configuration rather than during an incident.
/api-connectors — the registry of governed API targets. Where a connector does carry a credential, it is stored encrypted and never returned by any endpoint.From a schema file to a governed operation catalog
Upload the API's contract and AccessFlow parses it into a normalized catalog of operations, each with an id, a verb, a path and a read/write classification — so the same review plans and permissions that work for SELECT and DELETE work here. Reads are the safe verbs and query-shaped operations; everything mutating is a write, and the ambiguous protocols default to write, which fails safe towards review.
Accepted formats are OpenAPI (2 or 3, JSON or YAML), WSDL, GraphQL SDL, gRPC .proto, and Postman collections — the last because for a great many teams the de-facto contract is a collection export rather than an OpenAPI document. Paste it, drag a file in, or fetch it from a URL. An optional import filter keeps operations you have no intention of governing out of the catalog by path glob, verb, operation id or tag; the effect is previewable before you commit and editable afterwards without re-uploading.
Calls are composed the way you would compose them in an API client — query parameters, custom headers, and raw, form-data, URL-encoded or binary file bodies — so the governed path is not a downgrade from the tool the team already uses.
The same review pipeline as a query
A submitted call takes the identical lifecycle to a database query: pending AI, pending review, approved, executed. Permission is checked first — a non-admin needs an active connector grant with the matching read or write capability, and their grant can be scoped to specific operations. If the connector has a schema, a named operation must exist in the catalog; free-form calls are accepted but always routed to review.
Then the AI analyzer scores the call, routing policies apply auto-approve, auto-reject, escalate or extra-approval rules, and the connector's review plan decides who signs off. As with queries, the submitter can never approve their own call, and decisions are idempotent. Approved calls execute with the connector's auth and headers injected, the response capped at a configured size, and the result stored as a snapshot you can download. Break-glass, scheduled execution, W3C trace-context propagation and natural-language text-to-API are all available on the same request.
For the team-level version of this — the integration and backend engineers whose problem this actually is — see the API access use case. The mechanics of routing, delegation and escalation are shared with database review workflows.
What comes back is governed too
Approving a call decides whether it happens; masking decides what the caller gets to read. A response field is not a column, so a masking policy targets it four ways: a field of a parsed schema operation, a JSON dot-path (descending through arrays, and masking every leaf beneath a sub-tree), an XPath into an XML or SOAP body, or a regular expression over whatever is left. Each policy carries a masking strategy and reveal lists by role, group or user, so the same call returns different bodies to different people. The body is masked once, before the snapshot is stored, so the raw value never persists.
Fields can also be tagged PII, PCI, PHI, GDPR, FINANCIAL or SENSITIVE. A tag derives a sensible masking policy automatically and raises the AI analyzer's risk score for calls to that operation — it can never lower the model's verdict, only strengthen it.
Values computed per call
Some vendor contracts require a value that cannot exist until the moment of the call: an HMAC request signature, a nonce, a timestamp, an idempotency key. A submitter cannot hand-compute a signature for a request a reviewer will approve hours later. Connectors can therefore declare named variables — constants, UUIDs, timestamps, random hex, hashes, HMACs and encodings — evaluated at execution time and substituted into headers, the path, query values or the body. They resolve after authentication, so a signature can cover the freshly minted OAuth2 token, and dependency cycles are caught when you save the variable rather than when the call fails. API connector docs →