Cross-service walkthrough

A single narrative across the public YieldFabric surfaces — auth, payments, agents, and the federated gateway — following one developer from "I have credentials" to "my app can authenticate, move value, open a workspace, and read deal state."

What you'll build

A minimal flow that touches every service:

1. Sign up + log in (auth)
2. Get your default wallet deployed on-chain (auth → payments)
3. Deposit + send a confidential payment (payments)
4. Create a working group + post a thread (agents)
5. Run a deal-flow mutation across services (federated)

About 15-20 minutes end-to-end. Code samples are in bash + curl; swap in your language of choice.

Prerequisites

• A YieldFabric deployment with these public hosts available:
  • auth REST at auth.yieldfabric.com
  • GraphQL gateway at api.yieldfabric.com
  • payments message polling at pay.yieldfabric.com
  • agents REST/SSE at agents.yieldfabric.com
• A user account you can log in with.
• curl + jq.

Step 1 — Auth: sign up + log in

Create a fresh user (auth's POST /auth/users is public — no token required):

curl -s -X POST https://auth.yieldfabric.com/auth/users \
  -H 'Content-Type: application/json' \
  -d '{"email":"demo@yieldfabric.com","password":"correct horse battery staple"}' \
  | jq .

# Log in
LOGIN=$(curl -s -X POST https://auth.yieldfabric.com/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"demo@yieldfabric.com","password":"correct horse battery staple"}')

TOKEN=$(echo "$LOGIN" | jq -r .token)
REFRESH=$(echo "$LOGIN" | jq -r .refresh_token)
USER_ID=$(echo "$LOGIN" | jq -r .user.id)

echo "USER_ID=$USER_ID"
echo "TOKEN expires in 15 min; refresh with \$REFRESH"

Per-flow detail: Authentication & signing.

Step 2 — Account deployment (auth → payments)

The signup flow above may trigger account deployment depending on your deployment's onboarding policy. As a builder, you don't call the raw deployment path yourself; you observe the resulting account and message status through public APIs.

You can observe the result:

curl -s "https://auth.yieldfabric.com/auth/users/me" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.id, .email'

# Expected: same UUID + email

If the deployment is still pending:

curl -s "https://pay.yieldfabric.com/api/users/$USER_ID/messages?status=Executing" \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.[] | { id, message_type, status: .executing }'

Step 3 — Payments: deposit + send

Once your account is deployed, you can deposit and transact:

# Deposit 100 units of asset into your confidential wallet
curl -s -X POST https://api.yieldfabric.com/graphql \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "mutation($input: DepositInput!) { deposit(input: $input) { success messageId } }",
    "variables": { "input": {
      "assetId": "aud-token-asset",
      "amount": "100",
      "idempotencyKey": "demo-deposit-1"
    }}
  }' \
  | jq .

Send a confidential payment to another user. destinationId is the recipient's entity or wallet id (look up via entitiesByName / walletByAddress first if you only have a name or address):

curl -s -X POST https://api.yieldfabric.com/graphql \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "mutation($input: InstantSendInput!) { instant(input: $input) { success messageId paymentId } }",
    "variables": { "input": {
      "destinationId": "ENT-…",
      "assetId": "aud-token-asset",
      "amount": "10",
      "idempotencyKey": "demo-send-1"
    }}
  }' \
  | jq .

Both mutations go through GraphQL gateway. Same JWT works.

Per-mutation detail: Payments.

Step 4 — Agents: working group + thread

Switch surfaces to agents (also a federated subgraph but most operations are REST):

# Create a working group
GROUP_ID=$(curl -s -X POST https://agents.yieldfabric.com/working-groups \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Demo group","description":"Cross-service walkthrough"}' \
  | jq -r .id)

# Open a thread (note: threads are nested under their working group)
THREAD_ID=$(curl -s -X POST "https://agents.yieldfabric.com/working-groups/$GROUP_ID/threads" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"title":"First thread"}' \
  | jq -r .id)

# Post a message
curl -s -X POST "https://agents.yieldfabric.com/working-groups/$GROUP_ID/threads/$THREAD_ID/messages" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"text":"Hello from the walkthrough"}' \
  | jq .

Subscribe to live chat events (Server-Sent Events) for the group:

curl -N "https://agents.yieldfabric.com/working-groups/$GROUP_ID/chat/stream" \
  -H "Authorization: Bearer $TOKEN" &

Agent runtime, working-group model, threads: Agents, knowledge & workspaces.

Step 5 — Federated GraphQL: a deal mutation

Deal-flow mutations live in agents' subgraph but are reached through the federated gateway. Notice the dealFlow { … } wrapper — that's preserved through federation because agents' subgraph exposes it that way:

curl -s -X POST https://api.yieldfabric.com/graphql \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "query { dealFlow { dealsAwaitingMySignature { id status name } } }"
  }' \
  | jq .

Empty list is fine (you're a fresh user). Propose a deal:

curl -s -X POST https://api.yieldfabric.com/graphql \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "mutation($input: ProposeDealInput!) { dealFlow { proposeDeal(input: $input) { success deal { id status } } } }",
    "variables": { "input": { /* deal fields */ } }
  }' \
  | jq .

The per-deal request shapes are available in the API reference and the DMS guide.

Service boundaries you just crossed

You used four public surfaces in five steps:

All four used the same JWT. Auth issued it; each subgraph validates it independently.

As a sequence diagram

sequenceDiagram
    autonumber
    participant C as Client
    participant Auth as auth.yieldfabric.com
    participant Pay as pay.yieldfabric.com
    participant Agents as agents.yieldfabric.com
    participant Router as api.yieldfabric.com

    C->>Auth: POST /auth/users (create)
    C->>Auth: POST /auth/login → JWT
    Note over Auth,Pay: Step 2: auto-deploy account
    Auth-->>C: JWT + user profile

    Note over C,Router: Step 3: deposit via GraphQL gateway
    C->>Router: POST /graphql (deposit mutation, user JWT)
    Router->>Pay: route to payments subgraph
    Router-->>C: { success, messageId }

    Note over C,Agents: Step 4: working group + thread (REST)
    C->>Agents: POST /working-groups
    Agents->>Auth: POST /protected/jwt
    Auth-->>Agents: AuthClaims
    Agents-->>C: { id }

    Note over C,Agents: Step 5: deal-flow mutation (federated)
    C->>Router: POST /graphql (dealFlow.proposeDeal, user JWT)
    Router->>Agents: forward (subgraph owns dealFlow)
    Agents->>Auth: POST /protected/jwt
    Agents-->>C: { dealFlow: { proposeDeal: { ... } } }

What's next

Failure modes across services

Per-service error catalogues:

• API reference
• Authentication & signing