Skip to content
Gatewise

Developers

One call between proposing an action and taking it

Gatewise is agent framework agnostic. It sits between agent runtimes and the tools they use, so the integration is a single decision call in the path where your code would otherwise execute the action. The decision endpoint on this page is live and you can call it right now.

Request accessRun a live policy check

POST https://gatewise.lovable.app/api/public/v1/decisions

Integration pattern

Four steps in your execution path

  1. 01

    Agent proposes action

    Your agent builds the action instead of executing it.

  2. 02

    Gatewise evaluates

    Action, parameters and evidence are checked against policy rules in order.

  3. 03

    Gatewise returns a decision

    One of five outcomes, with a reason and a decision id.

  4. 04

    Application executes or stops

    Execute on ALLOW, hold on REQUIRE_APPROVAL, stop otherwise.

Live policy check

Send a real agent action and read the decision

This runs the public reference policy set on this site. The evaluation is deterministic: the same action with the same evidence always returns the same decision, with the rules it evaluated.

Example actions

POST /api/public/v1/decisions
editable

Edit the JSON and run it again. The endpoint is live on this site.

Decision
waiting

Pick an example action or edit the request, then run the decision.

Deterministic result. The same action and evidence always return the same decision.

API and clients

Call it with curl, or install the SDK

The reference endpoint answers a plain curl request. For application code, the TypeScript SDK adds the decision call, approval waiting, execution reporting and a wrapper that gates a single agent tool.

Decision API
shell
curl -sS https://gatewise.lovable.app/api/public/v1/decisions \
  -H "content-type: application/json" \
  -d '{
    "action": "refund.create",
    "agent": "support-agent-v3",
    "on_behalf_of": "user_8842",
    "parameters": { "amount": 349, "currency": "EUR", "order_id": "48211" },
    "evidence": {
      "invoice_status": "paid",
      "customer_verified": true,
      "existing_refunds": 0,
      "chargeback_open": false
    }
  }'

These calls work against the live reference endpoint on this site.

Supported actions
reference policy set
ActionParametersPolicy
refund.createamount, currency, order_idrefund-policy@7
discount.applypercent, account_iddiscount-policy@4
customer.deleteaccount_iddata-policy@3
email.campaign.sendrecipients, templatecommunication-policy@5
contract.updatefield, value, account_idcontract-policy@2
Handling decisions
client side
  • ALLOW

    Execute the action, then store the decision id with the result.

  • REQUIRE_APPROVAL

    Hold the action and open an approval for the required role.

  • BLOCK

    Do not execute. Return the reason to the agent or the user.

  • NO_ACTION

    Skip the action. Existing work already covers it.

  • INSUFFICIENT_EVIDENCE

    Load the missing evidence and evaluate again.

Uncovered actions
default-deny@1

An action with no matching policy is blocked, not guessed. Adding an action means adding a policy for it, so coverage stays explicit.

Actions without a policy return BLOCK.

Evidence

Gatewise reads the evidence, not the agent

A decision is only as trustworthy as the data behind it. For every evidence field you map to one of your systems, Gatewise calls that system at decision time. A value sent in the request body is used only for fields with no mapping, and each field carries its source in the record.

How a field is mapped
console: Evidence
  1. 01Connect a system in the console. Stripe, HubSpot and Salesforce have presets that create the connection and map their evidence fields in one step. Any other system is added with a base URL, how the call is authenticated, and a credential that is stored server side and is never readable from the browser.
  2. 02Map one evidence field: the request path with {parameter} placeholders, the path to the value in the response, and how to read it as a number, a yes or no, a count or the raw value.
  3. 03Run a test call from the console to confirm the value Gatewise will read.
  4. 04From then on, every decision for that action fetches the field from your system before the rules run.
  5. 05When a policy holds an action, Gatewise sends the approval request to the account approval channel, for example Slack, and reports the result in approval_delivery.
Evidence status on every decision
response field
  • collected

    Every mapped field was read from your systems.

  • partial

    At least one system did not answer. Fields that failed count as missing, which usually returns INSUFFICIENT_EVIDENCE.

  • caller_supplied

    No mapping applies to this action, so the evidence in the request body was used.

  • no_sources

    No system is connected for this account yet.

A field that cannot be read is treated as missing, never as the value the agent claimed.

Architecture

Framework agnostic by design

Gatewise does not replace your agent runtime, your tool layer or your systems of record. It is the decision point in front of them.

  1. Agent / copilot

    Any agent runtime or framework. Gatewise does not care which one.

    proposes

  2. Gatewise API / SDK / gateway

    Designed to sit between agent runtimes and the tools they use.

    intercepts

  3. Policy and evidence engine

    Deterministic rules, thresholds, duplicate checks and required evidence.

    decides

  4. Business systems

    CRM, support, payments, billing and internal tools.

    executes

Give your agents freedom without giving them a blank cheque.

Tell us what your agents are allowed to do today. We will review whether Gatewise fits your agent workflow.

Request accessSee how it works

Works with your agents and existing business tools