This skill provides comprehensive guidance for documenting SAP APIs following the SAP API Style Guide standards. It should be used when creating or reviewing API documentation for REST, OData, Java, JavaScript, .NET, or C/C++ APIs. The skill covers naming conventions, documentation comments, OpenAPI specifications, quality checklists, deprecation policies, and manual documentation templates. It ensures consistency with SAP API Business Hub standards and industry best practices. Keywords: SAP API, REST, OData, OpenAPI, Swagger, Javadoc, JSDoc, XML documentation, API Business Hub, API naming, API deprecation, x-sap-stateInfo, Entity Data Model, EDM, documentation tags, API quality, API templates
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
npx agent-skills-cli listSkill Instructions
name: sap-api-style description: | This skill provides comprehensive guidance for documenting SAP APIs following the SAP API Style Guide standards. It should be used when creating or reviewing API documentation for REST, OData, Java, JavaScript, .NET, or C/C++ APIs.
The skill covers naming conventions, documentation comments, OpenAPI specifications, quality checklists, deprecation policies, and manual documentation templates. It ensures consistency with SAP API Business Hub standards and industry best practices.
Keywords: SAP API, REST, OData, OpenAPI, Swagger, Javadoc, JSDoc, XML documentation, API Business Hub, API naming, API deprecation, x-sap-stateInfo, Entity Data Model, EDM, documentation tags, API quality, API templates license: GPL-3.0 metadata: version: "1.1.1" last_verified: "2026-02-25" source_version: "2025.01" source_commit: "902247f3afb6a0cb3fa110b284bb5d93a65c1268" source_license: "CC-BY-4.0"
SAP API Style Guide
Related Skills
- sap-cap-capire: Use for OData service documentation, CAP API patterns, and service definition standards
- sap-fiori-tools: Use for API consumption patterns, Fiori app integration, and OData best practices
- sap-abap: Use when documenting ABAP APIs, implementing REST services, or following API design patterns
- sapui5: Use for frontend API integration, OData consumption, and UI service patterns
- sap-btp-cloud-platform: Use for BTP service API documentation and integration patterns
Table of Contents
- Overview
- When to Use This Skill
- Quick Decision Tree
- Core Principles
- Quick Reference Tables
- Templates Available
- Reference Files
- Instructions for Use
- Common Pitfalls to Avoid
- External Resources
- Updates and Maintenance
Overview
This skill provides comprehensive guidance for documenting SAP APIs according to official SAP API Style Guide standards. It covers all major API types and documentation approaches used across the SAP ecosystem.
Documentation Source: https://github.com/SAP-docs/api-style-guide (76 files extracted)
Last Verified: 2025-11-21
When to Use This Skill
Use this skill when:
- Creating API documentation for REST, OData, Java, JavaScript, .NET, or C/C++ APIs
- Writing OpenAPI specifications for SAP API Business Hub
- Reviewing API names for SAP naming convention compliance
- Documenting API parameters, responses, operations with proper formatting
- Creating manual API documentation using SAP templates
- Writing documentation comments in source code (Javadoc, JSDoc, XML comments)
- Implementing API deprecation following SAP lifecycle policies
- Developing developer guides or service documentation
- Performing quality checks on API documentation
- Publishing APIs to SAP API Business Hub
Quick Decision Tree
What Type of API?
REST/OData API
ββ Auto-generated (OpenAPI/Swagger)?
β ββ references/rest-odata-openapi-guide.md
β β’ OpenAPI specification standards
β β’ Package, API, operation descriptions
β β’ Parameters, responses, components
β β’ SAP API Business Hub requirements
β
ββ Manually written?
ββ references/manual-templates-guide.md
β’ REST templates (2-level: overview β method)
β’ OData templates (3-level: service β resource β operation)
β’ Complete field requirements
β’ templates/ directory for ready-to-use files
Native Library API
ββ Java β references/java-javascript-dotnet-guide.md
ββ JavaScript β references/java-javascript-dotnet-guide.md
ββ .NET (C#) β references/java-javascript-dotnet-guide.md
ββ C/C++ β references/java-javascript-dotnet-guide.md
β’ Documentation comments structure
β’ Language-specific tags
β’ Templates for classes, methods, enums
β’ Complete code examples
What Task?
Naming
ββ references/naming-conventions.md
β’ REST/OData naming (resources, parameters, URIs)
β’ Native library naming (classes, methods, constants)
β’ Common mistakes to avoid
Writing Descriptions
ββ references/rest-odata-openapi-guide.md
β’ Package descriptions
β’ API details (info object)
β’ Operations, parameters, responses
Quality Assurance
ββ references/quality-processes.md
β’ Complete API Quality Checklist
β’ Review workflows
β’ Development team guidelines
Deprecating APIs
ββ references/deprecation-policy.md
β’ Lifecycle states (beta, active, deprecated, decommissioned)
β’ Timeline requirements (12+ months support)
β’ Required metadata (x-sap-stateInfo)
Developer Guides
ββ references/developer-guides.md
β’ Structure guidelines
β’ Content selection
β’ Code sample standards
Core Principles
1. Consistency Across SAP APIs
All SAP API documentation follows consistent conventions:
- Naming: Language-specific (camelCase, PascalCase, kebab-case)
- Structure: Hierarchical with clear navigation
- Formatting: Sentences start with capitals, end with periods
- Language: American English
2. API-Type-Specific Standards
| API Type | Standard | Tool | Documentation |
|---|---|---|---|
| REST | OpenAPI 3.0.3 | Swagger | Spec |
| OData | v4.01, v3.0, v2.0 | Various | OData.org |
| Java | Javadoc | javadoc | Oracle |
| JavaScript | JSDoc 3 | jsdoc | JSDoc.app |
| .NET | XML Comments | DocFX | Microsoft |
| C/C++ | Doxygen | doxygen | Doxygen.nl |
3. Progressive Disclosure
Documentation organized hierarchically:
- High-level overviews provide context and navigation
- Detailed references cover specific APIs, methods, operations
- Examples and templates demonstrate practical usage
4. Quality Standards
All documentation must:
- β Be reviewed by User Assistance (UA) developers
- β Use consistent naming and terminology
- β Include complete parameter and response descriptions
- β Avoid sensitive data in examples
- β Provide working code examples
- β Maintain accurate links and cross-references
Quick Reference Tables
Character Limits
| Element | Limit | Use Case |
|---|---|---|
| API Title | 80 | info.title in OpenAPI |
| API Short Text | 180 | x-sap-shortText |
| Package Short Desc | 250 | Package tile description |
| Operation Summary | 255 | Operation summary line |
| Description | 1024 | General descriptions |
API Naming Rules
General Rules (all API types):
- β Don't include "API" in name:
"Custom Forms API"β β "Custom Forms" - β Don't include "SAP" prefix:
"SAP Document Approval"β β "Document Approval" - β Don't use verbs:
"Configuring Portal"β β "Portal Configuration" - β Capitalize words properly
- β Avoid technical specifics (REST, OData, etc.)
See references/naming-conventions.md for complete language-specific rules.
Common Documentation Tags
Java/JavaScript:
@param <name> <description>- Parameter documentation@return <description>- Return value@throws <class> <description>- Exception@deprecated <description>- Deprecation notice
.NET:
<summary>- Brief description<param name="">- Parameter<returns>- Return value<exception cref="">- Exception
See references/java-javascript-dotnet-guide.md for complete tag reference.
API Lifecycle States
| State | Definition | Support | Metadata Required |
|---|---|---|---|
| Beta | Pre-production testing | No guarantees | state: beta |
| Active | Production-ready (default) | Full support | Optional |
| Deprecated | Replaced by successor | 12+ months | state, deprecationDate, successorApi |
| Decommissioned | Fully retired | None | Document removal |
See references/deprecation-policy.md for complete timeline and process requirements.
Templates Available
Ready-to-use templates in templates/ directory:
REST API Templates (2-Level)
- rest-api-overview-template.md - Resource-level overview
- rest-api-method-template.md - Individual endpoint details
OData API Templates (3-Level)
- odata-service-overview-template.md - Complete service overview
- odata-resource-template.md - Individual resource/entity set
- odata-operation-template.md - Specific operation details
All templates include:
- Clear "How to Use" instructions
- [Placeholder text] for customization
- Complete section structure
- Working examples
- Inline guidance
Reference Files
Complete Guides Available
-
rest-odata-openapi-guide.md (2,800 lines)
- Complete OpenAPI specification guidelines
- Package, API, operation descriptions
- Parameters, responses, components
- Security schemes, tags, external docs
- Character limits and anti-patterns
-
manual-templates-guide.md (2,765 lines)
- REST API templates (2-level hierarchy)
- OData API templates (3-level hierarchy)
- Complete template structures
- Field-by-field requirements
- Best practices and examples
-
naming-conventions.md (2,059 lines)
- REST/OData naming rules (resources, parameters, URIs)
- Native library naming (classes, methods, constants, packages)
- Language-specific conventions
- Common mistakes with fixes
- Decision trees and reference tables
-
quality-processes.md (1,774 lines)
- Complete API Quality Checklist
- Review workflows (developer + UA collaboration)
- Development team guidelines
- Common review findings and solutions
- Process flowcharts
-
java-javascript-dotnet-guide.md (1,517 lines)
- Documentation comments structure
- Language-specific tags (Java, JavaScript, .NET, C/C++)
- Templates for classes, methods, enums
- Complete code examples
- Best practices by language
-
developer-guides.md (704 lines)
- Guide structure standards
- Topic types (concept, reference, task)
- Content selection criteria
- Code sample standards (compilable, concise, commented)
- Best practices
-
deprecation-policy.md (664 lines)
- API lifecycle states (beta, active, deprecated, decommissioned)
- Timeline requirements (12+ months support, 24+ months lifespan)
- Required metadata (x-sap-stateInfo, artifact.json)
- Decommission process
- Complete examples
-
glossary-resources.md (472 lines)
-
Complete terminology definitions (API, OData, OpenAPI, etc.)
-
External resource links (standards, tools, SAP resources)
-
Quick reference tables
-
Tool documentation links
-
Content extraction and organization tracking
-
Source file mapping from SAP documentation
-
Consolidation and adaptation notes
-
Bundled Resources
This skill includes comprehensive documentation and templates organized for optimal use:
Reference Guides (references/)
- 9 detailed reference files (10,861 total lines)
- Complete coverage of SAP API Style Guide standards
- Progressive disclosure architecture for efficient loading
Template Files (templates/)
- rest-api-overview-template.md (217 lines) - Level 1 REST overview
- rest-api-method-template.md (477 lines) - Level 2 REST method details
- odata-service-overview-template.md (411 lines) - Level 1 OData service
- odata-resource-template.md (557 lines) - Level 2 OData resource
- odata-operation-template.md (681 lines) - Level 3 OData operation
Total: 2,343 lines of ready-to-use templates
Instructions for Use
Step 1: Identify API Type
Determine if you're documenting REST, OData, Java, JavaScript, .NET, or C/C++ API.
Step 2: Choose Approach
Auto-Generated: Write documentation comments in source code β Use appropriate tags β Submit for review
Manual: Select template from templates/ β Customize [placeholders] β Follow hierarchy β Validate with checklist
Step 3: Apply Standards
Consult appropriate reference file:
- Naming:
naming-conventions.md - Descriptions:
rest-odata-openapi-guide.mdorjava-javascript-dotnet-guide.md - Quality:
quality-processes.md - Deprecation:
deprecation-policy.md
Step 4: Quality Check
Before publishing:
- Review against API Quality Checklist (
quality-processes.md) - Verify naming conventions (
naming-conventions.md) - Check character limits (see Quick Reference Tables above)
- Validate no sensitive data in examples
- Test all code examples
- Verify links work
- Obtain UA developer review
Step 5: Publish
- REST/OData: Submit to SAP API Business Hub
- Java/JavaScript/.NET: Generate with appropriate tool (Javadoc, JSDoc, DocFX)
- Developer Guides: Publish to SAP Help Portal or product documentation
Common Pitfalls to Avoid
Naming:
- β Including "API":
"Custom Forms APIs"β β "Custom Forms" - β Using "SAP" prefix:
"SAP Document Approval"β β "Document Approval" - β Using verbs:
"Configuring Portal"β β "Portal Configuration"
Descriptions:
- β Second person:
"This operation creates..."β β "Creates a new user" - β Generic responses:
"No content"β β "Product is out of stock" - β Repeating summary in description
Documentation:
- β Skipping UA review
- β Including sensitive data in examples
- β Missing required tags
- β Inconsistent terminology
See individual reference files for complete anti-patterns and fixes.
External Resources
Standards
- OpenAPI Specification: https://spec.openapis.org/oas/latest.html
- OData v4.01: https://www.odata.org/documentation/
- Javadoc: https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html
- JSDoc 3: https://jsdoc.app/
- Doxygen: https://www.doxygen.nl/
SAP Resources
- SAP API Business Hub: https://api.sap.com/
- SAP Developer Center: https://developers.sap.com/
- SAP Help Portal: https://help.sap.com/
- SAP Community: https://community.sap.com/
Source
- SAP API Style Guide: https://github.com/SAP-docs/api-style-guide
Updates and Maintenance
Source Version: SAP API Style Guide 2025.01 (verified against commit 902247f)
Recent Changes:
- Source repository updated 2025-10-28
- Reference file line counts verified and updated
- Added comprehensive Table of Contents for navigation
- Added Bundled Resources section for content discovery
To Update This Skill:
- Check source repository for changes: https://github.com/SAP-docs/api-style-guide
- Review "What's New in the Style Guide"
- Update affected reference files
- Update templates if standards changed
- Update "Last Verified" date
Quarterly Review Recommended: Check for updates every 3 months
Next Review: 2026-02-27
Skill Version: 1.1.0 Last Updated: 2025-11-27 License: GPL-3.0 Maintainer: SAP Skills Team | https://github.com/secondsky/sap-skills
More by secondsky
View allDevelops and administers SAP Build Work Zone, advanced edition digital workplace solutions. Use when creating workspaces, workpages, and collaborative sites, developing UI Integration Cards in SAP Business Application Studio, building content packages and workspace templates, integrating with Microsoft 365/Teams/SharePoint/Google Drive, configuring chatbots and webhooks, implementing SCIM API user provisioning, setting up OData business records, managing themes and branding, configuring role-based access and SSO, troubleshooting deployment issues, or working with the Administration Console. Keywords: SAP Build Work Zone advanced edition, digital workplace, UI Integration Cards, content packages, workspace templates, SAP Business Application Studio, SAP Conversational AI, SCIM API, OData, Microsoft Teams integration, SSO, theming, Administration Console
This skill provides comprehensive guidance for SAP Business Application Studio (BAS), the cloud-based IDE on SAP BTP built on Code-OSS. Use when setting up BAS subscriptions, creating dev spaces, connecting to external systems, deploying MTA applications, troubleshooting connectivity issues, managing Git repositories, configuring runtime versions, or using the layout editor. Keywords: SAP Business Application Studio, BAS, SAP BTP, dev space, Cloud Foundry, MTA, multitarget application, SAP Fiori, CAP, HANA, destination, WebIDEEnabled, Cloud Connector, Service Center, Storyboard, Layout Editor, ABAP, OData, subscription, entitlements, role collection, Business_Application_Studio_Developer, Git, clone, push, pull, Gerrit, PAT, OAuth, asdf, runtime, Node.js, Java, Python, Task Explorer, CI/CD, Yeoman, generator, template wizard, mbt, mtar, debugging, breakpoint
Production-ready SAP BTP best practices for enterprise architecture, account management, security, and operations. Use when planning BTP implementations, setting up account hierarchies, configuring environments, implementing authentication, designing CI/CD pipelines, establishing governance, building Platform Engineering teams, implementing failover strategies, or managing application lifecycle on SAP BTP. Keywords: SAP BTP, account hierarchy, global account, directory, subaccount, Cloud Foundry, Kyma, ABAP, SAP Identity Authentication, CI/CD, governance, Platform Engineering, failover, multi-region, SAP BTP best practices
SAP BTP Cloud Integration Automation Service (CIAS) skill for guided integration workflows. Use when: setting up CIAS subscriptions, configuring destinations, assigning roles (CIASIntegrationAdministrator, CIASIntegrationExpert, CIASIntegrationMonitor), planning integration scenarios, working with My Inbox tasks, monitoring scenario execution, troubleshooting CIAS errors, creating OAuth2 instances, configuring identity providers for CIAS, understanding CIAS security architecture, or integrating SAP products (S/4HANA, SuccessFactors, BTP services, SAP Build, IBP).
