> ## 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.

# Closient vs Building Your Own Resolver

> What it actually takes to build a GTIN resolver, GS1 Digital Link service, or product graph in-house — and where a hosted platform pays off.

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.

## 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:

1. **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](https://www.gs1.org/standards/genspecs).
2. **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.
3. **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.
4. **A linkset response.** The
   [GS1 Resolver test suite](https://ref.gs1.org/test-suites/resolver/)
   enforces specific shapes for JSON linksets, content negotiation, and
   link-type CURIE handling. Failing it is failing GS1 conformance.
5. **A product graph behind it.** Brand claims, certifications, GPC
   classification, product images, dimensions, ingredients, sustainability
   data — and the contention model for *who edits what*.
6. **Operational scaffolding.** Logging, rate limiting, abuse handling,
   audit trails for who-changed-which-rule, deploy pipeline, on-call.

Closient already does all of the above. The trade-off question is
whether the parts you'd skip *are actually safe to skip*.

## 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                                         |

The first row is honest engineering, not pessimism — the GS1 test suite
is non-trivial and most in-house implementations stop at "happy path
redirects work" rather than reaching conformance.

## 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.

Outside those cases, the build-vs-buy math usually favours the platform
because the marginal product feature isn't a redirect server, it's the
thing your team is actually trying to ship.

## 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?

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    First REST API call in under five minutes.
  </Card>

  <Card title="MCP Quickstart" icon="rocket" href="/guides/mcp-quickstart">
    First MCP tool call in under two minutes.
  </Card>

  <Card title="Digital Link Resolution Guide" icon="link" href="/guides/digital-link-resolution">
    The full conceptual model — scopes, time-based routing, linksets.
  </Card>

  <Card title="API Reference" icon="code" href="/api-reference/overview">
    Eighteen domain APIs with interactive playgrounds.
  </Card>
</CardGroup>

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: JSON.stringify({
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
  "@type": "Question",
  "name": "What does building your own GTIN resolver actually involve?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "A working resolver requires a normalized identifier model (GTIN-8/12/13/14 canonicalization, check-digit validation, Application Identifiers parsing), a GS1 Digital Link URI parser, a resolver rule engine with scope hierarchy and time-based routing, GS1-conformant linkset responses that pass the GS1 Resolver test suite, a product graph behind it, and operational scaffolding (logging, rate limiting, audit trails). It is not just a redirect table."
  }
},
{
  "@type": "Question",
  "name": "How long does it take to build a GTIN resolver vs integrating Closient?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "Building in-house: 1-2 weeks for a prototype, 2-3 months to pass the GS1 Resolver test suite, 6-12 months for multi-brand support with rules and claims. Integrating Closient: under an hour for the first REST API call, same day for GS1-conformant linksets, same day for multi-brand support."
  }
},
{
  "@type": "Question",
  "name": "When is building a GTIN resolver in-house the right call?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "Build in-house when resolver logic is your competitive moat (new rule types that don't fit scope-hierarchy or time-based routing), when data sovereignty prevents using a hosted service, or when you're building a competing service. Outside those cases, the build-vs-buy math usually favours the platform because the marginal product feature isn't a redirect server."
  }
},
{
  "@type": "Question",
  "name": "What do I lose by integrating Closient instead of building my own?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "You don't run the database schema (mitigated by full REST export of your data), you add a network hop (mitigated by client-side caching), and custom rules outside the scope model may hit limits (most observed patterns fit). In exchange, you skip the 2-3 months of building GS1-conformant infrastructure."
  }
},
{
  "@type": "Question",
  "name": "What do I keep if I integrate Closient instead of building?",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "You keep your domain name (resolver routes can point at any HTTPS target), your branding (hosted product pages can be co-branded or bypassed), and full ownership of your product data (export at any time through the REST API)."
  }
}
]
}) }}
/>