The Shippo Addresses API validates and manages shipping addresses. Its catalog entry carries sixteen properties spanning ten artifact types — OpenAPI, Documentation, AsyncAPI, six separate SDK entries, JSONSchema, JSON-LD, SpectralRules, Vocabulary, GraphQL, and APIs.json.
Six SDKs on an address-validation API is the detail worth examining.
Why address validation earns this treatment
Address validation looks trivial and is not. It is the step where a shipping integration silently fails: a deliverable-looking address that the carrier rejects, a suite number dropped in normalization, a residential address classified as commercial and priced wrong. Every one of those becomes a support ticket days later, after the label is bought.
That failure mode — wrong answers rather than errors — is why the artifact stack here skews semantic. A JSON Schema pins the address object’s structure. A Vocabulary and a JSON-LD context define what the fields mean: which line is the street, what a normalized versus a raw address is, what a validation confidence actually asserts. Those distinctions are precisely where naive implementations go wrong.
The six SDKs
Six separate SDK properties is the highest count in this week’s sweep, and it reflects who integrates shipping.
Shipping is not integrated by platform teams building against a spec. It is integrated by e-commerce developers in whatever language their store runs — PHP, Python, Ruby, JavaScript, Java, C#. That population wants an idiomatic client library, not an OpenAPI document to generate from.
Publishing six and having them appear as first-class catalog properties is a provider meeting integrators where they actually are. Compare the Strava Activities API covered this week, which leads with rate limits and webhooks because its consumers are app developers worried about quotas. Different consumer, different artifact emphasis — both correct.
Spectral rules on a validation API
The SpectralRules property signals the same thing it did on Ramp’s Accounts API earlier this week: the definitions are linted, so conventions hold across Shippo’s surface. For a provider whose API you will call on every single order, that predictability compounds.
The one gap
The entry carries no baseURL. For an API this well described everywhere else, the missing base URL is a small but real omission — it is the first thing an agent resolving this API from the catalog alone would need, and it is the one thing not there.
Takeaway
Sixteen properties, six SDKs, a vocabulary and JSON-LD context defining what a validated address actually means, and linting rules keeping it consistent. Shippo treats address validation as a semantics problem rather than a string-matching one, which is exactly right — and then omits the base URL.
See it at docs.goshippo.com, and the provider entry at apis.io/providers/shippo/.