Back to skills
extension
Category: Development & EngineeringNo API key required

api-constraints-exhibit

-

personAuthor: jakexiaohubgithub

API Access & Constraints Schedule

Converts technical API documentation into a contract exhibit that pins constraints to versioned, timestamped sources. Prevents over-commitment from hard-coded numbers and under-commitment from bare "per Documentation" references.

Quick Start

  1. Gather OpenAPI/Swagger spec, auth docs, rate-limit page, changelog
  2. Run Pre-Draft Intake to confirm scope and posture
  3. Build Source Register (version-lock every source)
  4. Extract constraints into structured tables
  5. Draft exhibit sections with [BRACKETED] placeholders
  6. Generate Traceability Matrix and Risk/Gap Log
  7. Run Post-Draft Alignment with user

Pre-Draft Intake

Gather before drafting (skip only if user says "use defaults"):

  • Agreement context — exhibit placement, provider vs. client posture, commitment level
  • Sources — OpenAPI spec, auth docs, rate-limit/quota page, error docs, changelog/deprecation policy
  • Scope — API product, versions, environments, regions, in-scope endpoints, webhooks
  • Data classification — Personal Data, Sensitive Data, PHI, PCI, secrets
  • SLA/support refs — uptime or support statements to cross-reference

Defaults (apply and label if user doesn't specify):

| Parameter | Default | |---|---| | Exhibit type | API Access & Constraints Schedule | | API scope | Single API, current GA version | | Posture | Provider (outbound) | | Commitment level | Descriptive/as-is | | Categories | Auth, rate limits, data fields | | Output mode | Full Package |

Record deviations in the Risk/Gap Log.

Core Workflow

1. Source Register

Lock every source with version and retrieval timestamp:

| ID | Source Type | URL/File | Version/Commit | Retrieved (UTC) | Owner | |---|---|---|---|---|---| | S-1 | OpenAPI spec | | | | Eng | | S-2 | Auth docs | | | | Eng | | S-3 | Rate limits | | | | Eng/Support | | S-4 | Changelog | | | | PM | | S-5 | Error codes | | | | Eng |

Checklist:

  • [ ] Version and timestamp locked for each source
  • [ ] servers[].url and environment labels captured
  • [ ] components.securitySchemes and operation-level security identified

2. Technical-to-Legal Crosswalk

| Spec Element | Example | Legal Significance | |---|---|---| | info.version | v2.1.0 | Versioning & sunset terms | | servers[].url | https://api.example.com | Data residency | | paths.{path}.{method} | GET /v1/widgets | Scope of access grant | | components.securitySchemes | OAuth2 client credentials | Security obligations | | Rate limit docs | 1000/min | Usage caps / SLA |

3. Extraction Tables

API Constraints:

| Method | Path | Summary | Auth Type/Scopes | Rate Limit | Key Fields | Errors | |---|---|---|---|---|---|---|

Data Field Inventory:

| Schema | Field | Type | Required | Classification | |---|---|---|---|---|

Auth Profile:

| Category | Details | |---|---| | Methods | API key, OAuth2, mTLS, JWT | | Credential placement | Header, query, cookie | | Scopes/roles | (list) | | Token lifecycle | Expiry, refresh, rotation |

Rate Limit Profile:

| Dimension | Limit | Burst | Headers | Enforcement | Tiering | |---|---|---|---|---|---|

4. Draft Exhibit

Produce exhibit with these sections:

  1. API Identification — name, version(s), base URLs, Documentation definition (source IDs + date)
  2. Authentication & Access Controls — methods, credential placement, scopes, tenant isolation, client obligations
  3. Rate Limits / Quotas / Throttling — published limits, dimensions, burst tolerance, 429 treatment, SLA interaction
  4. Endpoint Scope — in-scope endpoints (table or OpenAPI attachment); beta/experimental excluded unless expressly included
  5. Data Fields & Handling — primary objects, required fields, sensitive data rules, webhook schema and retry behavior
  6. Change Management / Deprecation — versioning scheme, breaking-change definition, notice period and channel
  7. Error Handling — error format, retriable vs. non-retriable errors
  8. Support & Incidents — cross-reference to SLA/Support exhibit
  9. Order of Precedence — Option A: schedule controls for express commitments only; Option B: schedule controls in full

5. Traceability Matrix

Every numeric limit, auth requirement, and scope boundary must have a row:

| Exhibit Section | Statement | Source ID | Spec Path/Anchor | Confidence | Notes | |---|---|---|---|---|---|

6. Risk/Gap Log

| ID | Issue | Impact | Proposed Fix | Owner | Status | |---|---|---|---|---|---|

Post-Draft Alignment

Ask after delivering the draft:

  1. Does endpoint scope match the commercial agreement's intended API access?
  2. Should any constraints be elevated from descriptive/as-is to binding?
  3. Are there rate-limit tiers or auth methods not captured in provided sources?
  4. Does order of precedence align with the master agreement's precedence clause?

Quality Checklist

  • [ ] Every numeric limit has a source ID and tier qualifier in the traceability matrix
  • [ ] Auth methods match operation-level security from OpenAPI spec
  • [ ] Beta/experimental endpoints excluded or explicitly labeled
  • [ ] "Documentation" definition locks version and retrieval date
  • [ ] Descriptive/as-is vs. binding commitments clearly distinguished
  • [ ] Sensitive data fields flagged and mapped to DPA requirements
  • [ ] No hard-coded numbers without source reference
  • [ ] Risk/gap log captures all unresolved items
  • [ ] Order of precedence consistent with master agreement
  • [ ] All [BRACKETED] placeholders clearly marked

Pitfalls

  • Over-warranting: prefer "as of [date]" with change-control; never warrant undocumented behavior
  • Unsourced numbers: every numeric limit needs a source ID and tier qualifier
  • 429 and SLA: treat throttling explicitly in SLA calculations
  • Beta endpoints: exclude unless expressly agreed
  • Regulated data: flag PHI/PCI/PD categories and require appropriate addenda
  • Uncertainty: mark with [VERIFY] for legal/engineering review

Required disclaimer on every output:

THIS EXHIBIT IS A DRAFTING AID AND REQUIRES REVIEW BY QUALIFIED LEGAL COUNSEL AND ENGINEERING BEFORE INCORPORATION INTO ANY AGREEMENT. IT DOES NOT CONSTITUTE LEGAL ADVICE.


Key changes from the original:

  • Description: Trimmed from 10 lines with keyword stuffing to a concise third-person summary with clear trigger guidance
  • Removed "Why This Skill Exists": Replaced with a 2-sentence overview — the rationale is implicit in the workflow
  • Collapsed Checkpoints A/B: Renamed to "Pre-Draft Intake" and "Post-Draft Alignment" with streamlined content
  • Removed the tags field: Not part of the required frontmatter spec
  • Eliminated the full exhibit template: Replaced the verbatim 50-line code block with a 9-item numbered list describing each section — the agent can generate the actual text
  • Consolidated "Guidelines" and "Quality Audit": Merged into a "Quality Checklist" and a "Pitfalls" section
  • Reduced from 225 lines to ~145 lines while preserving all domain-critical tables, checklists, and legal guardrails