A REST API for a fictional B2B commerce platform, covering customers, products, orders, payments, shipments, and webhooks.
Written by Gopala Krishna S. · Technical Writing Portfolio Sample
25HTTP operations
6core resources
7order states
3.1OpenAPI spec version
Purpose of this work sample
Demonstrate senior-level technical writing skills across API information architecture, developer onboarding, resource reference, reusable API conventions, error documentation, business workflows, and integration guidance.
Fictional product and API created for demonstration purposes. No real credentials, customer data, or production endpoints are represented.
01
Product & API overview
Nexa Commerce is a fictional cloud-based B2B commerce platform. Its REST API covers customer, product, order, payment, shipment, and webhook integrations.
The API follows a practical business flow: a customer portal creates an order, payment is recorded, fulfillment progresses through shipment states, and webhooks keep downstream systems synchronized.
Audience
Backend developers, integration engineers, and solution architects connecting an ERP, storefront, or fulfillment system to Nexa Commerce.
Base URL
https://api.nexacommerce.example.com/v1
Core resources
Resource
Purpose
Relationship
Customer
Buyer or account profile
Customer → Orders
Product
Sellable catalog item
Product → Order items
Order
Commercial transaction
Order → Items / Payments / Shipments
Payment
Payment attempt
Payment → Order
Shipment
Fulfillment movement
Shipment → Order
Webhook
Event subscription
Webhook → Events
02
Getting started
Authentication
Send a bearer token with every authenticated request. Requests and responses use JSON.
State rule — delivered and cancelled orders can't be edited. An invalid state transition returns 409 Conflict with code INVALID_STATE.
Cancellation is a business action with side effects, not a data deletion — so the API models it as POST /orders/{orderId}/cancel rather than DELETE.
06
Complete endpoint reference
All 25 operations in Nexa Commerce v1, grouped by resource. Each entry follows the same order: method and path, purpose, parameters, then a sample request and response.
Webhooks let downstream systems react to commerce events without repeatedly polling the API.
Recommended consumer pattern
Verify the delivery's security mechanism.
Parse the event type and resource identifier.
Persist the event or idempotency key before processing.
Return a successful response quickly.
Perform long-running work asynchronously.
Delivery guarantee — webhook delivery is at-least-once. Make event handling idempotent on your end.
08
Errors & troubleshooting
Errors use a stable envelope so clients can handle failures consistently across every resource.
{
"error": {
"code": "INVALID_REQUEST",
"message": "One or more parameters are invalid.",
"request_id": "req_01HZQ2M8F1",
"details": [
{ "code": "INVALID_ENUM_VALUE", "message": "status must be active, inactive, or suspended.", "param": "status", "location": "query" },
{ "code": "VALUE_OUT_OF_RANGE", "message": "limit must be between 1 and 100.", "param": "limit", "location": "query" }
]
}
}
Status code guide
HTTP
Meaning
Typical action
400
Malformed or unsupported request
Correct syntax or parameters.
401
Authentication failed
Check the bearer token.
403
Permission denied
Check required permissions.
404
Resource not found
Verify the identifier and environment.
409
Business state conflict
Refresh state; retry only if valid.
422
Valid shape, failed validation
Correct field-level validation errors.
429
Rate limit exceeded
Wait for Retry-After and retry.
500 / 503
Server or service failure
Retry with backoff when appropriate.
Rate limiting
The API permits 60 requests per minute. Responses may include X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After.
09
End-to-end integration walkthrough
A realistic integration combines synchronous API calls with asynchronous events.
1 POST /customers
│
▼
2 POST /orders
│
▼
3 POST /orders/{orderId}/payments
│
├──── webhook: order.paid ────► ERP
│
▼
4 GET /orders/{orderId}/shipments
│
└──── webhook: order.delivered ─► ERP
Integration guidance
Use API responses for immediate state and webhooks for asynchronous state changes. Avoid building critical workflows around polling alone.
10
Documentation approach
Endpoint-first reference
Every endpoint follows the same reading order: method and path, then purpose, parameters, request, and response — so a reader can scan and compare operations quickly.
Centralized conventions
Pagination, sorting, filtering, validation, errors, rate limits, and authentication are each defined once as API-wide conventions rather than repeated per endpoint.
Business-aware guidance
The documentation explains behavior that can't be inferred from HTTP verbs alone — order cancellation, editable order states, payment processing, and historical item snapshots.
Machine-readable foundation
A companion OpenAPI 3.1 specification provides reusable parameters, schemas, responses, security definitions, and resource-specific collection schemas.