Send a message to the granted deployment and wait for the answer
Payman Connect resolves the grant to its one deployment, attaches that deployment’s key and configuration, forwards the message, and returns what the agent said.
Authorizations
A Connect app key (pgc_app_…), identifying the registered third-party app. Always presented together with connectGrant — the pair is one credential, and either half alone is refused. Accepted on the /connect/* surface only.
A Connect grant token (pgc_grant_…): one user's consent for the presenting app to reach one deployment. Every failure mode — missing, malformed, revoked, expired, or paired with the wrong app key — answers the same 401 invalid_connect_credentials.
Headers
A key of your own choosing that names ONE instruction, so a retry of it is not a second execution. Scoped to your grant, so it cannot collide with another app's.
16 - 255^[A-Za-z0-9._~-]+$Body
1Reuse within one conversation to thread history. On Connect, also scopes short-lived explicit account selection for referential follow-ups; use a new ID for each chat.
Display name for the end user; defaults to the caller's email.
Extra per-call attributes merged into the ones derived from the stored configuration. Configuration wins on a key collision, so a caller cannot override a stored bank token from the request body.
fast, deep Which connected account a multi-provider wallet should use — an institution type (BREX) or an account label, exactly as a needs_provider result's candidates listed them. Optional.
256Response
The customer's agent answered — or, on a multi-provider grant, the router answered instead of dispatching: a body whose status is needs_provider or no_capable_provider (see ConnectRoutingDecision) means no agent ran, nothing was charged, and the app should re-ask per howToProceed rather than retry.
- Option 1
- Option 2
The common fields lifted out of the agent's answer, plus the answer itself. Agents that don't speak K2's ExecuteAgentResponse shape still round-trip intact through raw.
Which mode served this turn — assert it in your integration, so a live key in a test config (or the reverse) fails loudly at the first call instead of quietly moving the wrong kind of money. Added by this server at the route, never read off the agent's body.
sandbox, live The agent's own status, e.g. COMPLETED or FAILED.
The agent's answer text; empty when the agent returned none.
The agent's response body, verbatim.
The frozen operation's handle, when the run stopped for the account owner's approval. Non-null exactly when status is APPROVAL_REQUIRED — both or neither, because a ref on an otherwise ordinary turn would put an approval button in front of somebody for a payment nothing is holding.
48^pgtk_[A-Za-z0-9_-]{43}$"pgtk_9Qv2mB7fJ0xkLpR4sTuVwXyZa1b2c3d4e5f6g7h8i9j"
When that frozen operation lapses. ISO-8601 UTC. After it, the ticket is inert and replaying simply asks for approval again.
Payman's approval page for the frozen operation — the console origin plus the ref.

