Data API for content and analytics products

What breaks when you build this on the wrong foundation

The first approach most teams try is asking each user to connect their own account. Conversion drops at that step, support inherits a permanent category of tickets, and the accounts that do connect are the ones at risk when anything goes wrong. You have also made your product only as reliable as your least careful user.

The second is a stored dataset. That works until someone generates a post about their current role and the model writes about the job they left two years ago. In a product whose entire promise is that the output sounds like the user, being out of date is not a data quality issue, it is the failure of the product.

The third is building the fetching yourself. It works for a quarter. Then it becomes a permanent engineering cost that has nothing to do with why customers pay you.

How it works

1. 01

   Read the user, once

   On onboarding, resolve the profile into role, employer, history, skills and headline. That is the voice and the context every generation afterwards is grounded in.

   Profile enrichment

2. 02

   Learn from what already worked

   Fetch their published posts with reaction, comment and share counts. Style, format and topics that landed are all in there, and it is the difference between generic output and output that sounds like them.

   Posts

3. 03

   Report on the audience

   Comments and reactions come back with the profile behind each one, so an analytics view can show who engaged and what they do, not just how many hits a post took.

   Engagement

4. 04

   Refresh on your schedule

   Re-read on a cadence you control. Roles change, and a generator working from a stale headline writes confidently wrong copy for a paying customer.

   Profile enrichment

In code

// Onboarding: the voice, once
const { profile } = await fetch(
  `https://api.fetchin.io/api/v1/profile?url=${user.profileUrl}`,
  { headers: { 'X-API-Key': process.env.FETCHIN_KEY } }
).then(r => r.json())

// What has actually landed for them before
const { posts } = await fetch(
  `https://api.fetchin.io/api/v1/posts?url=${user.profileUrl}`,
  { headers: { 'X-API-Key': process.env.FETCHIN_KEY } }
).then(r => r.json())

const topPerforming = posts
  .sort((a, b) => b.reactionCount - a.reactionCount)
  .slice(0, 5)

return generate({
  role:     profile.jobTitle,
  employer: profile.companyName,
  about:    profile.description,
  skills:   profile.skills,
  // Style transfer from their own best work, not a generic template
  examples: topPerforming.map(p => p.content),
})

What it changes

Endpoints this uses

Questions

Do my users have to connect their own account?

No, and that is usually the reason teams move here. Your service calls with your own API key and a URL. There is nothing for the end user to authorise, no session to keep alive, and no per-seat cost hiding behind the per-request price.

Can I resell or white-label the data?

Building it into a product you sell is the normal case here, and has been since 2023. The API has no branding requirement and no attribution in the response. For volume commitments and dedicated throughput, talk to us rather than using the self-serve tiers.

What happens on a launch day?

Throughput is priced as its own axis, so more requests per second is a plan change rather than a rewrite. Self-serve is 5 per second and 10 to 100 or more is provisioned on request, typically in a couple of business days.

How do I keep costs predictable?

Billing is per successful call, so cost tracks usage exactly and a failing integration does not quietly bill you. Read your own remaining balance from the subscription endpoint, which is free and is never gated on your quota, and back off before you hit a limit.

Is it fast enough to sit in my product?

1 second at the median and 1.5 at P95, synchronous, so it fits inside a user-facing request. Most products read the profile once at onboarding and cache it, then refresh on their own schedule, which keeps the read out of the hot path entirely.

Other use cases