Organization Guide

Skyfire lets you onboard as an organization, an account structure that lets you manage a group of Skyfire users centrally, under one umbrella. Most commonly, each organization user represents one of your customers, giving every customer its own presence on Skyfire: its own identity, its own wallet, and its own agents acting on Skyfire on that customer's behalf.

Onboarding requires an Organization Agreement. Reach out to [email protected] to get started.

Your organization takes one of three shapes: buy-side, where your organization users create tokens, sell-side, where they receive tokens, or a marketplace, where they do both. For example, Sequentum's customers build agents that need access to the open internet (buy-side), Blackhawk sells gift cards (sell-side), and Buildship's customers buy and sell workflow automations (marketplace).

Your organization in every token

Every token your organization users create has an apd claim, representing agent platform identity.

The claim is named for the general case: any party that an agent acts on behalf of. Your organization is one instance of that pattern, so apd identifies your organization on every token your organization users create.

{
  ...
  "apd": {
    "id": "1ae68a2d-1266-4647-98be-f9f72eed4076",
    "name": "ACME Shopping",
    "email": "[email protected]",
    ...
  },
  ...
}

Buy-side organizations

You are a buy-side organization if your organization users' create tokens and present them to merchants and services.

Share your setup with your Skyfire contact. They create your organization and assign it an organization ID, which every organization user, agent, and wallet you create will belong to. You also choose a designated admin, your organization's point of contact, and Skyfire issues that admin an API key.

Every Skyfire API key is shown once at creation. Capture each key as you receive it, since a lost key has to be reissued rather than recovered. Keep your admin API key server side, because it can create and modify organization users across your organization.

You use your admin API key to create organization users. Each one comes with a buyer agent already linked to it.

{
  "email": "[email protected]",
  "role": "MEMBER"
}

{
  "userId": "6f9d2b1e-...",
  "buyerAgent": {
    "id": "a3c81f04-...",
    "apiKey": "e6c4...-..."
  }
}

An organization user can represent a customer individual or a customer organization: one organization user per individual, each with its own identity and wallet, or one organization user shared by an entire customer organization, with a shared identity and wallet. For example, a shopping platform like Acme Shopping might sell directly to consumers, B2C, giving each individual customer their own organization user and running KYC on each one; or it might sell to businesses, B2B, giving each business customer a single shared organization user and running KYB on the business itself.

You can optionally submit personal data to organization users, which populates the identity claims a merchant or service reads.

{
  "data": {
    "person": { "firstName": "Ada", "lastName": "Lovelace", "birthdate": "1990-12-10" }
  }
}

Decide who verifies your organization users, and run that process before they transact. Verification confirms that the party behind an organization user is who they claim to be: KYC for a customer individual, KYB for a customer organization.

Skyfire runs verification for you, and is named as the verifier in the resulting token claims. Optionally, you build and run your own verification process, meeting Skyfire's criteria, and your organization is named as the verifier instead.

Now they can create tokens: kya, pay, and kya-pay.

{
  "type": "kya-pay",
  "sellerServiceId": "b7e2f1a0-...",
  "tokenAmount": "0.01"
}

Decide how they'll reach Skyfire's APIs to create those tokens, and build for it. This determines who holds credentials and who makes the calls. Your organization users can call Skyfire's APIs and iframes directly, using Skyfire-issued credentials, the simpler path since you're not in the request path. Optionally, they call your own service instead, which proxies their calls to Skyfire; you build and run that proxy, and you control the underlying Skyfire-issued credentials, whether you store them yourself or expose them to your customers directly.

You remain your customers' sole point of contact, throughout onboarding and afterward. Skyfire does not engage with your customers directly; all customer-facing communication and support flows through you.

All tokens they create carry your organization in the apd claim. See Your organization in every token above.

Sell-side organizations

You are a sell-side organization if your organization users' agents receive tokens in exchange for a resource, i.e. an API, an MCP server, a webpage, or an agent.

Share your setup with your Skyfire contact. They create your organization and assign it an organization ID, which every organization user, agent, and wallet you create will belong to. You also choose a designated admin, the organization user whose identity backs your organization, and Skyfire issues that admin an API key.

You use your admin API key to create organization users.

{
  "email": "[email protected]",
  "role": "MEMBER"
}

{
  "userId": "6f9d2b1e-...",
  "buyerAgent": {
    "id": "a3c81f04-...",
    "apiKey": "e6c4...-..."
  }
}

An organization user can represent a customer individual or a customer organization: one organization user per individual, each with its own identity and wallet, or one organization user shared by an entire customer organization, with a shared identity and wallet.

Then, for each organization user, create a seller agent for them.

{ "displayName": "Acme Widgets" }

{
  "id": "9e5b7c22-...",
  "apiKey": "b41f...-..."
}

You can optionally submit their personal data, which increases trust signals to buyer agents.

{
  "data": {
    "person": { "firstName": "Ada", "lastName": "Lovelace", "birthdate": "1990-12-10" }
  }
}

Decide who verifies your organization users, and run that process before a buyer agent transacts with their seller service. Verification confirms that the party behind an organization user is who they claim to be: KYC for a customer individual, KYB for a customer organization. Skyfire runs verification for you, and is named as the verifier in the resulting token claims. Optionally, you build and run your own verification process, meeting Skyfire's criteria, and your organization is named as the verifier instead.

Now they can create seller services. See Seller Guide for creating a seller agent's first service, and How Seller Services Work for configuring what it costs and requires, and getting it approved.

Decide how they'll manage those seller agents and services, and build for it. This determines who holds credentials and who makes the calls. Your organization users can manage their seller agents and services directly in the Skyfire Dashboard or API, using Skyfire-issued credentials. Optionally, they call your own service instead, which proxies their calls to Skyfire; you build and run that proxy, and you control the underlying Skyfire-issued credentials.

For example, Buildship lets each of its own customers create a service, but Buildship itself manages monetization behind the scenes, wrapping access so its customers never touch Skyfire credentials directly. Other organizations use Skyfire as their internal monetization platform instead, giving organization users direct access to sell their own credits to their buyers.

Contact [email protected] to discuss monetization options for your organization.

Marketplace organizations

You are a marketplace organization if you want your organization users to both spend and sell. Follow Buy-side organizations and Sell-side organizations above. The same organization user can hold both a buyer agent and a seller agent, each with its own API key.

Originating tokens

Originating tokens is a further, deliberate choice layered on top of any of the patterns above, not an automatic consequence of a customer being an organization rather than an individual. It means facilitating token creation for that organization's own agents.

An originator is an organization that uses Skyfire to offer agentic identity and agentic wallets to organizations that run agents on behalf of their own end users. Skyfire issues the kya, pay, and kya-pay tokens involved, and hosts the identity and wallet infrastructure behind them. Depending on your access model, Skyfire issues each token either to you or to your customer's organization; either way, your organization's URL is recorded in the ori claim, identifying you as the originator.

Roles in an origination relationship

Role	Description
End user	The person on whose behalf an agent acts, the human principal.
Agent platform (your customer's organization)	Runs the agents, which act on behalf of the end user and present tokens to merchants or services. Owns the relationship with its end users, and is responsible for KYC of its end users.
Originator (you)	Provider of agentic identity and agentic wallets to its customers. Responsible for KYB of its customers.
Skyfire	Issues the tokens and hosts the identity and wallet infrastructure behind them.
Skyfire's KYAPay Acceptance Network	A network of security vendors that merchants use to help secure their websites and APIs, including bot managers, fraud managers, account takeover protectors, and CIAMs.
Merchant / service	Accepts tokens from agents to grant access, complete a purchase, or both.

Skyfire has partnerships with a large and growing list of security vendors that natively accept kya/kya-pay tokens. If you are a security vendor who wants to enable agentic access and payments for your merchants and services, see kyapay.org for more information and reach out to [email protected].

What Skyfire configures for you

Skyfire configures your organization as an originator, which populates the ori claim in every token your organization users create. This requires no action from you.

The ori claim is what tells a merchant or service that your organization stands behind the token, distinct from the verifier claims above, which record who performed verification.

What origination adds

Origination adds two things on top of whichever pattern your customer's organization follows.

• Skyfire onboards the customer's organization as an agent platform. This is what lets it run agents of its own, rather than only holding a wallet.
• Skyfire sets up a designated admin. A staff member at the customer's company. Tokens identify this contact as the contact person in the apd claim.
  From there, your customer's organization is itself a buy-side, sell-side, or marketplace organization: it follows whichever pattern above fits, and you can facilitate that setup however you want, performing it on their behalf directly, or handing the designated admin's credentials to them to do it themselves.

Originating card-backed pay and kya-pay tokens is fully supported. Creating one involves Skyfire's Payments React SDK alongside Create Token, rather than an API call on its own. See Agentic Commerce with Payment Cards for how that works.

Next steps

• To run a single seller for your buy-side organization, see Sell to Your Customers' Agents.
• To let your customers fund their wallets from inside your own application, see Credits Wallet Embed SDK.