Dataing context, with consent

Build with contextusers choose.

Context should come with receipts. The contract is public, the token is read-only, and the user stays in the loop. Check the source at api.dataing.io/openapi.json.

This API opens a window into user-approved Dataing context—not a back door into the person. It includes profiles, traits, connection summaries, compatibilities, and visible threads.

API docs Get a token

Generate a private token

Open the user API page in the Dataing app, create a dtok_ token, copy it once, and store it like a password.

Open token page

Send it as a header

Use X-Dataing-Profile-Token: dtok_... or Authorization: Bearer dtok_... against api.dataing.io.

Open API docs

Read user-approved context

Start with profile summary, bios, traits, data connections, discover profiles, match requests, compatibilities, and threads.

View OpenAPI

Endpoint atlas

The useful surface,with the lights on.

All examples use https://api.dataing.io. Most list endpoints support limit, offset, and cursor; threads use page, limit, and type.

The OpenAPI also lists /admin/user-api-usage for admin usage review. It is intentionally not part of this user-token quickstart.

Profile context

/user-api/me

Private API profile summary for the token owner.

/user-api/profile-pictures

Ordered profile pictures.

/user-api/bios/latest

Latest generated bio, or null if no bio exists yet.

/user-api/bios?limit=25&offset=0

Paginated bio history. Cursor pagination is also supported.

Signals and matching

/user-api/traits?limit=25&offset=0

Generated traits with evidence metadata.

/user-api/data-connections

Connected-provider summaries and status.

/user-api/discover?limit=25&offset=0

Discover profiles visible to the token owner.

/user-api/compatibilities?limit=25&offset=0

Compatibility records involving the token owner.

Conversation surface

/user-api/match-requests?limit=25&offset=0

Incoming match requests.

/user-api/threads?page=1&limit=20&type=ALL

Visible chat threads.

/user-api/threads/{threadId}/messages?limit=20

Messages and participants for one visible thread.

Copy, paste, understand

Test it before you trust it.

Keep dtok_ values out of browser bundles, repos, logs, analytics, and shared screenshots. Rotate or revoke them from the user API page.

curl

export DATAING_TOKEN="dtok_your-token-here"

curl https://api.dataing.io/user-api/me \
  -H "X-Dataing-Profile-Token: $DATAING_TOKEN"

JavaScript

const token = process.env.DATAING_TOKEN

if (!token) {
  throw new Error('Set DATAING_TOKEN first')
}

const response = await fetch('https://api.dataing.io/user-api/traits?limit=25', {
  headers: {
    'X-Dataing-Profile-Token': token,
  },
})

if (!response.ok) {
  throw new Error(`Dataing API ${response.status}`)
}

const payload = await response.json()
console.log(payload.data)

Bearer alternative

curl https://api.dataing.io/user-api/bios/latest \
  -H "Authorization: Bearer $DATAING_TOKEN"

Codex prompts

Prompts with the guardrails included.

Create a small TypeScript script that reads DATAING_TOKEN from .env, calls https://api.dataing.io/user-api/me, and prints my latest bio, top traits, and linked signals.

Build a local-only dashboard for my Dataing private profile API. Use /user-api/bios/latest, /user-api/traits, /user-api/profile-pictures, and /user-api/data-connections. Do not store my token in source control.

Write a smoke test for the Dataing API that checks /user-api/me returns 200 with a valid dtok_ token and gives a clear setup message on 401.

Generate a Next.js route handler that proxies selected read-only Dataing /user-api endpoints from my server. Keep DATAING_TOKEN server-side and redact it from logs.

Trust boundary

A private profile token is a key to a room the user chose—not a master key. It should never act like a login, perform mutations, or expose raw provider credentials. Treat it as user-approved read access to selected Dataing context.