OpenAPI Specs
How to document token requirements in an OpenAPI spec, so buyer agents can generate the right requests automatically.
If your seller service is defined using an OpenAPI specification, document how Skyfire tokens must be passed and validated. Explicit documentation lets buyer agents automatically generate and include the correct tokens when calling your API.
See an example OpenAPI spec.
Older integrations may reference the
skyfire-pay-idheader instead ofkyapay-token. It is deprecated and being replaced.
Ways to require a header
Avoid using the standard Authorization header in either approach below. It can conflict with existing authentication middleware and tooling. Use a dedicated header instead, such as kyapay-token.
Define a security scheme:
{
"components": {
"securitySchemes": {
"SkyfireToken": {
"type": "apiKey",
"in": "header",
"name": "kyapay-token",
"description": "Skyfire token header. This service accepts kya, pay, or kya-pay tokens."
}
}
},
"security": [
{
"SkyfireToken": []
}
]
}components:
securitySchemes:
SkyfireToken:
type: apiKey
in: header
name: kyapay-token
description: Skyfire token header. This service accepts kya, pay, or kya-pay tokens.
security:
- SkyfireToken: []A security scheme:
- Defines the header as part of authentication
- Applies globally to all endpoints, or can be overridden per operation
- Signals to tools and clients that this is security-related
- Is enforced by the
securityfield
Specify accepted token types
For each endpoint, describe which Skyfire tokens are accepted, so integrators and buyer agents know what to send. Document this either in the header description itself, or with an optional vendor extension such as x-skyfire-token-type. In many cases, a clear description like "Accepts pay or kya-pay tokens" is enough for both human readers and generated documentation.
Document, where relevant:
- Whether a
kyatoken is required (identity only) - Whether a
paytoken is required (payment only) - Whether a
kya-paytoken is required (identity and payment) - Whether one token type is required or multiple are allowed
- Any required token claims your service validates, such as
sub,hid, or payment-specific fields
Using a vendor extension to specify token type (optional)
You may optionally use a vendor extension like x-skyfire-token-type to explicitly indicate expected token behavior for tooling or documentation purposes.
Security scheme example
{
"components": {
"securitySchemes": {
"SkyfireToken": {
"type": "apiKey",
"in": "header",
"name": "kyapay-token",
"description": "Skyfire token header. This service accepts pay or kya-pay tokens."
}
}
},
"security": [
{
"SkyfireToken": []
}
],
"paths": {
"/purchase": {
"post": {
"summary": "Create a purchase",
"description": "Creates a purchase for the requested resource.",
"security": [
{
"SkyfireToken": []
}
],
"x-skyfire-token-type": ["pay", "kya-pay"]
}
}
}
}components:
securitySchemes:
SkyfireToken:
type: apiKey
in: header
name: kyapay-token
description: Skyfire token header. This service accepts pay or kya-pay tokens.
security:
- SkyfireToken: []
paths:
/purchase:
post:
summary: Create a purchase
description: Creates a purchase for the requested resource.
security:
- SkyfireToken: []
x-skyfire-token-type:
- pay
- kya-payRequired header parameter example
{
"paths": {
"/profile": {
"get": {
"summary": "Get profile",
"description": "Returns the profile for the current user.",
"parameters": [
{
"name": "kyapay-token",
"in": "header",
"required": true,
"schema": {
"type": "string"
},
"description": "Skyfire token header. This service accepts kya or kya-pay tokens."
}
],
"x-skyfire-token-type": ["kya", "kya-pay"]
}
}
}
}paths:
/profile:
get:
summary: Get profile
description: Returns the profile for the current user.
parameters:
- name: kyapay-token
in: header
required: true
schema:
type: string
description: Skyfire token header. This service accepts kya or kya-pay tokens.
x-skyfire-token-type:
- kya
- kya-payRecommended error handling
Describe error responses for a missing token, an invalid or expired token, and an incorrect token type for the operation. Clear error documentation improves integration speed and reduces support overhead. See Handling Missing or Invalid Tokens.
Why this matters
Well-documented token requirements let buyer agents:
- Automatically attach the correct token
- Avoid conflicts with existing
Authorization-based authentication systems - Enforce payment requirements correctly
- Reduce integration errors
For how to validate tokens and extract claims, see Verify and Extract Data from Tokens.
Updated 4 days ago

