Skyfire

This agent's wallet: `available`, `heldAmount` (reserved by payment tokens that have not been charged or expired yet), `pendingCharges` and `pendingDeposits`. `available` is what a new payment token can still reserve, so read it before Mint a Skyfire token rather than reading a 402 afterwards. IT IS ALSO THIS INTEGRATION'S CREDENTIAL CHECK, and the only endpoint here whose REJECTION has been measured: 2026-09-24, and re-measured 2026-09-25, a bogus `skyfire-api-key` answered 401 NOT_AUTHORIZED "API Key Not Found" and omitting the header answered 401 NOT_AUTHORIZED "Invalid API Key" -- so the endpoint genuinely authenticates rather than answering 200 to anyone. What a REAL key answers has never been observed: no Skyfire credential existed when this integration shipped. NEEDS A BUYER AGENT KEY. A Seller agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Every service this seller agent publishes, each with its `id`, `name`, `price`, `priceModel`, `minimumTokenAmount`, `tags`, `humanIdentityRequirement`, `termsOfService` and its `active`/`approved` flags. This is where a `sellerServiceId` for the other seller tools comes from. `approved: false` means Skyfire has not cleared the service yet, which is a different state from `active: false`. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

One of this seller's services in full, including the identity requirement a buyer's KYA token must satisfy and the terms of service they must accept. Read it before Update a seller service: the update sends only the members named, and this is what says what they currently are. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

The network allow-list on this agent, as a bare array of addresses. An empty array means Skyfire is not filtering by source address. READ THIS BEFORE Replace the agent's allowed source IPs, which overwrites the whole list. WORKS WITH EITHER AGENT KEY, Buyer or Seller: it is one of Skyfire's generic Agent APIs. An Enterprise Admin user key does NOT reach it -- an admin key manages organization users only. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Every user in this Skyfire organization, each with `email`, `isAdmin`, `orgMemberRole`, `isActive`, `createdAt` and their agents -- `agentId`, `agentType` (BUYER or SELLER) and each agent's blockchain `accounts`. CURSOR-PAGED with `pageSize` and `pageCursor`; `filter` narrows by one of `id`, `email`, `identifier`, `active`, `admin`, `orgMemberRole`. This is where a `userId` for the other organization tools comes from, and it is how an `isActive: false` user is found -- the cause of a 403 on a key that is otherwise perfectly valid. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

The charge history for one token: each entry carries `chargeId`, `claimId`, `value`, `network`, `chargedAt` and, once the chain has settled it, `settledAt`. CURSOR-PAGED -- pass the previous reply's `nextPageCursor` back as `pageCursor`, and a reply with no `nextPageCursor` is the last page. This reads charges; it does not make one. WORKS WITH EITHER AGENT KEY, Buyer or Seller: it is one of Skyfire's generic Agent APIs. An Enterprise Admin user key does NOT reach it -- an admin key manages organization users only. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Change a published service's name, tags, price, minimum token amount, accepted tokens or terms of service. No member is required: send only what is changing. NOTE THE TYPE CHANGE FROM THE CREATE: `acceptedTokens` is an ARRAY on Create a seller service and a plain STRING here -- that is what the reference declares, transcribed rather than corrected, because no credential existed to measure which one the live API takes. Answers 204 with no body, so read the service back to confirm the change. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Reactivate a deactivated organization user, which is what restores every key they hold. This is the remedy for a 403 on a key that is otherwise valid -- pasting a new key does not fix that fault, because the key was never the problem. Answers 204 with no body. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Deactivate an organization user. EVERY KEY THAT USER HOLDS STOPS WORKING, and it fails in a way that looks like something else: Skyfire answers 403 -- not 401 -- to an otherwise perfectly valid key whose organization user has been deactivated, so any Agentic Fabriq connection holding one of their agent keys begins failing and re-pasting the key will not fix it. Reversible with Activate an organization user. Answers 204 with no body; confirm with List organization users rather than trusting it. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Publish a new service for this seller agent: what it is, what it costs, and what identity a buyer must prove to use it. `price`/`priceModel` and `minimumTokenAmount` are the commercial terms every buyer's token is checked against, so a wrong `minimumTokenAmount` silently refuses legitimate buyers. ONE LEDGER DEFECT IS CORRECTED HERE: the reference lists `description` among the required members while declaring no schema for it, so it is declared as a string and kept required -- a required member with no type could not be sent at all. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Put a service back on sale. It takes no body. ACTIVE IS NOT THE SAME AS APPROVED: a service Skyfire has not cleared stays unreachable to buyers with `approved: false` however often this is called. Answers 204 with no body. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Take a service off sale: buyers can no longer mint tokens against it and the seller stops earning from it. DESTRUCTIVE, and the ledger classifies it so, although it is REVERSIBLE with Activate a seller service -- what it destroys is availability, immediately and for every buyer, and Skyfire says nothing about what happens to payment tokens already outstanding against it. Confirm with Get a seller service rather than trusting the 204. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Create a user in this Skyfire organization, together with a Buyer agent for them. `role` is `MEMBER` or `ADMIN`, and an `ADMIN` can create and deactivate other users -- read that field twice. THE REPLY CARRIES TWO LIVE CREDENTIALS AND AGENTIC FABRIQ REDACTS BOTH: Skyfire returns the new user's `userApiKey` and the new Buyer agent's `buyerAgent.apiKey`, and a tool result is copied into the model's context and into the audit trail. Each comes back as a marker instead. Skyfire shows a key only once, so the way to obtain them is to rotate that user's and that agent's keys in the Skyfire Dashboard -- nothing in this integration can recover the values it withheld. `userId` and `buyerAgent.id` are returned in full, which is everything the other organization tools need. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Give an existing organization user a SELLER agent, so they can publish services and charge tokens. A Skyfire agent's role is fixed when the agent is created and cannot be changed, which is why a seller agent is created rather than a buyer agent converted. THE REPLY CARRIES THE NEW AGENT'S LIVE API KEY AND AGENTIC FABRIQ REDACTS IT, for the reason Create an organization user gives; the agent `id` comes back in full. Note what that means for reaching the seller tools: this Enterprise Admin key does not reach them, so the new agent's key -- rotated out of the Dashboard -- is pasted into a SECOND Agentic Fabriq connection. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Attach personal data to an organization user -- legal name, date of birth, government identity documents, addresses, email addresses and phone numbers -- so their agents can satisfy a seller's `humanIdentityRequirement`. THIS IS THE MOST SENSITIVE WRITE IN THIS INTEGRATION: it sends identifying documents about a real person to Skyfire, and the arguments of the call are recorded in Agentic Fabriq's audit trail like every other call's. Send only what a named seller requirement actually asks for. Treated as REPLACING the record rather than merging into it: the reference publishes no merge semantics and none was measured, so send the whole record. Answers 204 with no body. NEEDS AN ENTERPRISE ADMIN USER KEY, which is NOT self-service: Skyfire issues it after a signed contract (sales@skyfire.xyz, support@skyfire.xyz) rather than from the Agent Dashboard. Neither agent key reaches this, and an admin key does not reach the token or seller-service tools -- so an organization that wants both needs a second Agentic Fabriq connection holding the other key. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Mint a Skyfire token -- the ES256-signed JWT a buyer agent presents to a seller service. `type` chooses what it carries: identity (KYA), payment (PAY) or both (KYA+PAY). A payment token needs `tokenAmount` and RESERVES THAT AMOUNT against this agent's wallet, so this call moves money into escrow and a 402 means the wallet cannot cover it -- read the balance first. Name the counterparty with `sellerServiceId` or `sellerDomainOrUrl`. THE REPLY IS A BEARER CREDENTIAL FOR THE SELLER: whoever holds the returned `token` can claim up to `tokenAmount`, so treat it as a secret and do not log it. It is returned rather than redacted because presenting it to the seller is the entire purpose of the call. IT IS NOT AN OAUTH GRANT AND ITS `scope` CLAIM IS NOT AN OAUTH SCOPE: this is a request payload Skyfire mints and a third-party seller verifies against the JWKS at app.skyfire.xyz/.well-known/jwks.json. NEEDS A BUYER AGENT KEY. A Seller agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Redeem a buyer's payment token: the seller agent claims `chargeAmount` (or whatever the token still holds when it is omitted) and Skyfire answers `amountCharged` and `remainingBalance`. THIS TAKES THE BUYER'S MONEY, and this integration cannot undo it -- Skyfire publishes no refund endpoint in this ledger, so a mistaken charge is settled out of band. Introspect the token first: a charge above the remaining balance answers 402, and a token past its `chargeableUntil` is already dead. NEEDS A SELLER AGENT KEY. A Buyer agent key answers 401 here even though it is valid, and an Enterprise Admin user key is explicitly not for token or service operations, so it does not reach this either. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

Validate a Skyfire token and read what it is still good for, without spending it. THE REPLY SHAPE DEPENDS ON THE TOKEN TYPE: an identity (KYA) token answers `{isValid, expiresAt}`; a payment (PAY or KYA+PAY) token also answers `remainingBalance` and `chargeableUntil`. When `isValid` is false the reason is in `validationError` -- read it rather than inferring one. This is the safe read to make before Charge a token. WORKS WITH EITHER AGENT KEY, Buyer or Seller: it is one of Skyfire's generic Agent APIs. An Enterprise Admin user key does NOT reach it -- an admin key manages organization users only. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.

REPLACES the agent's whole network allow-list rather than adding to it, so send every address that must keep working -- INCLUDING AGENTIC FABRIQ'S OWN EGRESS ADDRESSES, or this connection locks itself out and every other Skyfire tool begins failing at the network layer where the error will look like a credential fault. List the current addresses first. THE MEMBER NAME IS TRANSCRIBED, NOT MEASURED: the reference the ledger was read from names it `IP addresses`, with the space, and no Skyfire credential existed to confirm it. Any additional members are forwarded unchanged, so if Skyfire answers 400 naming a different one, send that one. Answers 204 with no body. WORKS WITH EITHER AGENT KEY, Buyer or Seller: it is one of Skyfire's generic Agent APIs. An Enterprise Admin user key does NOT reach it -- an admin key manages organization users only. Skyfire reports a failure as `{"code": ..., "message": ...}`. A 401 HERE IS AS LIKELY TO BE THE WRONG KEY ROLE AS A BAD KEY: measured 2026-09-24 and re-measured 2026-09-25 against GET https://api.skyfire.xyz/api/v1/agents/balance, a bogus `skyfire-api-key` answers 401 `{"code":"NOT_AUTHORIZED","message":"API Key Not Found"}` and omitting the header answers 401 `{"code":"NOT_AUTHORIZED","message":"Invalid API Key"}` -- and a perfectly valid key of the wrong ROLE answers 401 too, because a Skyfire agent's role is fixed when the agent is created. A 403 is a different fault and pasting a new key will not fix it: it is the documented answer when the organization user behind an otherwise-valid key has been DEACTIVATED, and the remedy is reactivating that user.