Skip to main content
Developers create agents to run autonomous Payments workflows. An agent can pay on behalf of its creator, or on behalf of its creator’s customers who have connected a wallet to it. A developer can register many agents, and each agent can act for many parties. Every agent-customer pair carries its own permissions and limits: the developer requests them, the customer approves, and either side can update or revoke the relationship later through the dashboard or API.

​
Agent customer model

Kendall (Developer) invites his customer to one of his agents with specific permissions and limits. Eric (Customer) reviews and approves the agent-customer relationship:
Each relationship carries the permissions the customer granted and a per-transaction limit. A payment over the limit isn’t rejected; it holds as an Approval for the party’s owners or admins to approve or deny. This invite-and-approve flow is Natural Connect. Start with Invite a customer.

​
Agent authentication

Agents authenticate via our SDKs using credentials the developer owns. There are two ways to establish agent identity:
  • Agent keys (ak_ntl_…) — A credential bound to one agent. Requests resolve as that agent automatically. The same verified binding applies to agent-scoped MCP OAuth grants.
  • API keys (sk_ntl_…) — A party credential for user/party actions. It cannot act as an agent; see Authentication.
See Authentication for the full credential model. Agent attribution is optional: dashboard users, user-scoped MCP grants, and plain API key calls move money as user/party actions without naming an agent.

​
Instance ID required for agent money movement

A money-movement request attributed to an agent (by agent key or agent-scoped OAuth grant) must also carry an instance_id (X-Instance-ID) for transaction observability. Agent-attributed money-movement requests without X-Instance-ID are rejected with a 400 error (missing_instance_id).

​
Agent instances

An instance_id groups related agent executions. Natural tracks every payment on its own, but an instance_id lets you tie the actions of one logical workflow together. You control the value: pass a stable string that identifies the run.