This page is for engineers evaluating “should we build this ourselves?”. It assumes you’ve already understood the goal — resolving GTINs, serving Digital Link redirects, returning structured product data — and you want a candid view of the real cost.Documentation Index
Fetch the complete documentation index at: https://docs.closient.com/llms.txt
Use this file to discover all available pages before exploring further.
What does building your own GTIN resolver actually involve?
A working resolver isn’t a redirect table. To match a hosted service at parity you need:- A normalized identifier model. GTIN-8, UPC-12 (GTIN-12), EAN-13 (GTIN-13), and GTIN-14 all need to canonicalize to the same internal key. Check-digit validation. Application Identifiers parsing (AI 01, 10, 21, 17, 8200, …) per GS1 General Specifications.
- A GS1 Digital Link parser. RFC-style URI parsing that handles
/01/<gtin>/10/<lot>/21/<serial>?<qs>and round-trips through compressed and uncompressed forms. - A resolver rule engine. Rules are scoped (org / brand / SKU) with time-of-day, locale, device-class, and link-type filtering. Conflict resolution between overlapping rules has to be deterministic.
- A linkset response. The GS1 Resolver test suite enforces specific shapes for JSON linksets, content negotiation, and link-type CURIE handling. Failing it is failing GS1 conformance.
- A product graph behind it. Brand claims, certifications, GPC classification, product images, dimensions, ingredients, sustainability data — and the contention model for who edits what.
- Operational scaffolding. Logging, rate limiting, abuse handling, audit trails for who-changed-which-rule, deploy pipeline, on-call.
How long does it take to build vs to integrate Closient?
| Path | Time to “first resolve works” | Time to GS1-conformant linksets | Time to multi-brand support |
|---|---|---|---|
| Build in-house from scratch | 1-2 weeks (prototype) | 2-3 months (test suite green) | 6-12 months (rules, claims, conflict resolution) |
| Closient REST API | Under an hour | Same day — already conformant | Same day — already supported |
| Closient MCP server | Under five minutes | Same day | Same day |
When is building in-house the right call?
There are real cases:- Your resolver logic is your moat. You’re inventing a new rule type that doesn’t map to scope hierarchy or time-based routing, and you can’t get it shipped on a platform.
- You have a data sovereignty requirement that prevents you from using a hosted service even with private resolver endpoints.
- You’re building a competing service. Then you need control end to end and an external vendor is a strategic risk.
What do I lose by integrating Closient instead of building?
- Control of the database. Product data is queried via the API; you don’t run the schema. Mitigation: every read endpoint is documented, and the REST API gives you full export of your own product data.
- Latency floor. A hosted service adds an HTTP hop. For most catalog-lookup use cases this is irrelevant; for sub-10ms ad-stack paths it matters. Mitigation: cache responses on your side; Closient responses are JSON and cache-friendly.
- Custom rules outside the scope model. If your routing logic doesn’t fit the org/brand/SKU scope hierarchy or time-based routing, you might hit a model limit. Mitigation: most observed patterns fit; the resolver rules engine is intentionally broad.
What do I keep?
- Your domain name. Resolver routes can point at any HTTPS target.
- Your branding. Hosted product pages can be co-branded; you can also bypass them entirely and route directly to your own pages.
- Your data. Product records you create are yours. Export at any time through the REST API.
I want to integrate. Where do I start?
Quickstart
First REST API call in under five minutes.
MCP Quickstart
First MCP tool call in under two minutes.
Digital Link Resolution Guide
The full conceptual model — scopes, time-based routing, linksets.
API Reference
Eighteen domain APIs with interactive playgrounds.