GenticSprint

Resources

Evaluate it properly, or don’t use it.

A trend pipeline is easy to demo and hard to verify. This page is written for the second activity: what to measure, how to check provenance, how the API is shaped to be used, and what the security posture actually is.

Read the docsOpen Test Ground

Live status

The state of each surface, described plainly. A surface is listed as available only once it is serving real requests, and the label says what it serves rather than how it is deployed.

  • REST APIAvailable now
  • MCP serverAvailable now
  • Trend pipelineRunning on a schedule
  • Developer consoleAvailable now

This board is updated by a deploy, not by a heartbeat, so it cannot drift out of sync with reality between releases.

Benchmarks

Measure verifiability, not volume

Every item below is checkable against the live API rather than taken on trust.

How to evaluate this

The honest benchmark for a trend pipeline is not how many items it can emit — it is how much of the emitted record you can verify. Measure three things: the share of trends whose source URL resolves, the share with a retained body, and the share whose provenance fields are populated.

  • GET /v1/trends/{trend_id} returns the citation list for a trend, including canonical URL, publisher, author, word count, and fetch method.
  • GET /v1/content/{trend_id} returns the retained bodies, with content_retained telling you plainly whether anything survived sanitisation.
  • GET /v1/benefits reports aggregate counts of trends, retained documents, publishers, source URLs, and distinct fetch methods.

Security posture

Reads are served over HTTPS from an edge that does nothing but serve reads. The storage that holds the data is never addressable from the public internet — a single authenticated edge is the only route in.

  • The public surface is read-only by construction: there is no write path to abuse.
  • Backing storage sits behind one authenticated edge; raw service ports are never exposed.
  • Fetched content is stripped of embedded markup and personal data before it is stored, not after you receive it.
  • API keys cannot be read back after creation, and can be rotated or revoked from the console.
  • Account access is enforced server-side, never by hiding links in the interface.

Honest semantics

Several fields exist specifically to distinguish “measured zero” from “not measured”. Clients should branch on them rather than treating null as a number.

  • An unmeasured aggregate is returned as null, never as 0.
  • A trend with nothing retained returns documents: [] and content_retained: false.
  • Optional provenance such as author or published_date is null when the source did not provide it.
  • An empty result set is a valid response describing an empty query window, not an error.

Changelog and roadmap

The public schema is versioned and additive-first: new fields appear with the version bumped, and removals are deprecation-gated rather than silent.

  • Current public schema_version: 1.0.
  • Deprecation policy: add the replacement, mark the old field deprecated in the OpenAPI document, keep serving both, then remove.
  • Additive-first by default: new fields ship with the version bumped, and nothing is removed before a documented deprecation window.

Integration patterns

Four ways the API is shaped to be used

Each pattern maps onto real endpoints and can be reproduced from the docs in a few minutes. We publish patterns rather than testimonials, because a pattern is something you can verify yourself.

Agent context loading

An agent fetches recent trends for its domain, then calls the content endpoint for the ones it decides to reason about. Two calls, no crawler of its own, and provenance it can quote back to the user.

GET /v1/trends/recent → GET /v1/content/{trend_id}

Topic monitoring

A scheduled job polls a keyword with a bounded time window, compares impact scores against the previous run, and alerts on genuine movement instead of raw volume.

GET /v1/search?q=…&hours=24

Publisher watching

Track a set of domains and read the domain quality score alongside each trend, so a single low-quality source cannot inflate a signal.

GET /v1/sources/{domain}/trending

Aggregate reporting

Pull platform-level counts and freshness for a dashboard without reading individual trends. Unmeasured aggregates arrive as null, so the chart can show a gap rather than a false zero.

GET /v1/stats · GET /v1/benefits

Contact

Enterprise and partnership enquiries

Reserved ceilings, custom source and category configuration, aggregate benefit reporting, and a dedicated support and SLA agreement are arranged with us rather than self-served.

Tell us the volume you expect and the domains that matter to you, and the agreement is sized around that rather than around a template.

See the plansRead the docs first

Handy references

REST base URL
https://api.genticsprint.com
MCP endpoint
https://mcp.genticsprint.com/mcp
OpenAPI document
/docs/openapi.json

Canonical specification: https://www.genticsprint.com/docs/openapi.json

OpenAPI 3.1MCP serversource lineageretained cleaned bodiesidentical shape on every tier

Each signal above is a checkable property of the running API, not a marketing adjective. The REST reference shows how to check them yourself in three requests.