> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/operate-and-monitor/query-your-datamart/retrieve-user-data-using-graphql-api.md).
# Retrieve user data using GraphQL API
A walkthrough: get everything the platform holds about one user, by any identifier.
## Your goal
Retrieve the data held about **one** user, starting from whatever identifier you have - for an access request, a support investigation, or a real-time personalisation call.
## Expected outcome
A single response containing the fields you need, and an understanding of what the response does **not** include.
## Prerequisites
* An [authenticated](/setup-and-monitor/manage-the-platform/manage-api-access.md) call. For code running in a browser or an app, use signature authentication, not a long-term token.
* One identifier for the user.
* Fields present in your [schema](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/schema-definition.md) - the GraphQL schema is derived from yours.
## Walk through it
{% stepper %}
{% step %}
### Start from the identifier you have
Each identifier type has its own selector function:
| You have | Function |
| -------------------------------------- | ------------------------------------------------------------------------------ |
| A UserPoint ID | `user_point(user_point_id: "...")` |
| An email hash | `user_point_by_email_hash(email_hash: "...")` |
| An account ID **and** a compartment ID | `user_point_by_user_account_id(compartment_id: "...", user_account_id: "...")` |
| A user agent ID | `user_point_by_user_agent_id(user_agent_id: "...")` |
{% hint style="warning" %}
For an account, **both** the compartment ID and the account ID are mandatory - an account ID alone is not an identifier. See [User Account](/setup-and-monitor/collect-and-manage-your-data/design-your-data-model-and-schema/user-identity/user-identifiers/user-account.md).
{% endhint %}
{% endstep %}
{% step %}
### Confirm the user exists
Start minimal, so a problem with the identifier is not confused with a problem in the field selection:
```graphql
query MyQuery {
user_point_by_email_hash(email_hash: "xxxxxxxxxxxxxxxxxxx") {
id
creation_ts
}
}
```
{% endstep %}
{% step %}
### Ask for what you need
```graphql
query MyQuery {
user_point(user_point_id: "xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx") {
id
creation_ts
profiles {
gender
birth_date
}
accounts {
compartment_id
user_account_id
}
segments {
id
}
scenarios {
scenario_id
}
}
}
```
{% hint style="info" %}
The field names here depend on **your** schema - `gender` and `birth_date` are examples. Check your own model, in the Query Tool or in the GraphQL playground available in the Computing Console.
{% endhint %}
{% endstep %}
{% step %}
### Send it
```
POST /v1/datamarts/:datamartId/query_executions/graphql
```
The body carries a `query` parameter with the query text, starting with `query MyQuery {`. Escape double quotes as needed. A `200` returns `{ "data": { ... } }`.
{% endstep %}
{% step %}
### Narrow the activities, knowing the caveat
`@filter` restricts the objects returned:
```graphql
query micsQuery {
user_point(user_point_id:"xxx") {
activities {
events @filter(clause: "name == \"$home_view\""){
ts
}
}
}
}
```
{% hint style="danger" %}
**A GraphQL query returns a maximum of 100 activities**, with no warning, and `@filter` is applied **after** that limit.
So an empty result means "no match **among the first hundred activities**", not "no match". For a user with a long history, this is the difference between a correct answer and a wrong one.
{% endhint %}
{% endstep %}
{% endstepper %}
## When GraphQL is the wrong tool
| Situation | Use instead |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| You need the **complete** history of a user, beyond 100 activities | [OTQL](/setup-and-monitor/operate-and-monitor/query-your-datamart/otql.md), or [Explore a user profile](/setup-and-monitor/operate-and-monitor/explore-a-user-profile.md) to read the raw activities |
| You need data for **many** users | [OTQL](/setup-and-monitor/operate-and-monitor/query-your-datamart/otql.md), or a [query export](/setup-and-monitor/collect-and-manage-your-data/export-your-data/export.md) |
| You need to **write** something | The GraphQL endpoint is read-only. See [Server-side events](/setup-and-monitor/collect-and-manage-your-data/collect-data-in-real-time/server-side-events.md) |
| You are answering a formal access request | [Exercise rights of the user](/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md), which also covers looking the person up by every identifier they gave you |
## Verify
* The minimal query returns an `id`, confirming the identifier resolves.
* Every field you request exists in your schema - an unknown field is a query error, not an empty value.
* For anything depending on completeness, you have accounted for the 100-activity limit.
* Calls stay within the endpoint's rate limit; `429` means you exceeded it.
## Related pages
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.mediarithmics.io/setup-and-monitor/operate-and-monitor/query-your-datamart/retrieve-user-data-using-graphql-api.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.