Understanding the Persona API data model
Learn how the Persona API structures data using the JSON:API specification. This section explains data serialization, relationships, and how to optimize responses with sparse fieldsets. We'll walk through examples using the Retrieve an Inquiry endpoint.
Data organization overview
Persona’s API follows a consistent, portable data model:
- Predictable: Each resource type (e.g., inquiry, account) has a defined shape and
attributes
. - Implicit Relationships: Connected resources (e.g., inquiries and their verifications) are automatically linked and accessible via
relationships
. - Portable: API responses are standardized and compatible across environments.
This makes it easier to fetch individual resources, include
related data, or streamline responses
with filters.
Serialization
Serialization is the process of converting data into a consistent structure and for the Persona API, this is an important concept to help ensure that you can get data that you need and know how to obtain additional or specific pieces of data. Persona uses the JSON:API specification to deliver predictable, machine-readable responses
in JSON-encoded bodies.
There are many benefits of this type of serialization including:
- Performance: Faster
responses
with default payloads containing commonly needed data across various use cases. - Privacy: Ability to limit exposure of PII by fetching only what is needed.
- Clarity: Ability to return only relevant data to simplify integration with Persona.
Sparse fields and include features
The sparse fields feature allows faster
responses
by returning only the specific PII data you need, which simplifies your integration.The
include
feature lets you easily retrieve additional data by leveragingrelationships
between resources and objects.
Data structure
Request
The request
format depends on the endpoint type. For data retrieve endpoints like GET /inquiries/:id
, a request
body is not needed. However, when creating or updating with POST
or PATCH
endpoints, you may need to include specific parameters related to the data object.
Example of a POST
Request
POST
RequestLet’s look at an example of a POST
request. The Create an Inquiry endpoint helps you create an Inquiry with an inquiry-template-id
. However you can also create an Account through the endpoint if you provide additional data. For more details about creating an Account with this endpoint here.
curl --request POST \
--url https://api.withpersona.com/api/v1/inquiries \
--header 'Persona-Version: 2023-01-05' \
--header 'accept: application/json' \
--header 'authorization: Bearer {persona-api-key}' \
--header 'content-type: application/json' \
--data '
{
"data": {
"attributes": {
"template-id": "tmpl_ABC123",
"inquiry-template-id": "itmpl_ABC123",
"inquiry-template-version-id": "itmplv_ABC123",
"account-id": "act_ABC123",
"creator-email-address": "[email protected]",
"theme-id": "the_ABC123",
"theme-set-id": "theset_ABC123",
"redirect-uri": "https://yoururl.com/redirect",
"note": "A note about this inquiry",
"tags": [
"string"
],
"initial-step-name": "string"
}
},
"meta": {
"auto-create-account": true,
"auto-create-account-type-id": "acttp_ABC123",
"auto-create-account-reference-id": "my_reference_id",
"expiration-after-create-interval-seconds": 86400,
"expiration-after-start-interval-seconds": 86400,
"expiration-after-resume-interval-seconds": 86400,
"one-time-link-expiration-seconds": 3600
}
}
Note: You will need to replace
{persona-api-key}
with your Persona API Key
Example of a GET
Request
GET
RequestHere’s an example of using the Retrieve an Inquiry endpoint with a GET
request. To get data for a specific Inquiry, you will need both an inquiry-id
and a persona-api-key
.
curl --request GET \
--url https://api.withpersona.com/api/v1/inquiries/{inquiry-id} \
--header 'Persona-Version: 2023-01-05' \
--header 'accept: application/json' \
--header 'authorization: Bearer {persona-api-key}'
Check the specific API reference documentation for details.
Responses
The response
format follows a consistent structure. For data retrieve endpoints like GET /inquiries/:id
, responses include a primary resource object. For create or update endpoints using POST
or PATCH
, responses contain the newly created or modified resource with its updated attributes.
All Persona API responses follow JSON:API specification and has the following components::
data
: the primary resourceincluded
: related resourcesmeta
: additional context
data
key
data
keyThe data
key contains an object representing the serialized data of the primary resource.
Each object contains:
type
: The resource type, such asinquiry
id
: A globally unique string that identifies the resourceattributes
: An object of fields and values for that resourcerelationships
: References to related resources
The following examples use the Retrieve an Inquiry endpoint to demonstrate response formats. For brevity, some sections are abbreviated with "…": "…"
.
# GET <https://api.withpersona.com/api/v1/inquiries/inq_ABC123>
{
"data": {
"type": "inquiry",
"id": "inq_ABC123",
"attributes": {
"status": "approved",
"reference-id": "abc-123",
"note": null,
"behaviors": {
"api-version-less-than-minimum-count": null,
"autofill-cancels": 22,
"...": "...",
},
"tags": [],
"creator": "[email protected]",
"reviewer-comment": null,
"updated-at": "2025-05-05T18:02:57.000Z",
"...": "...",
"previous-step-name": "verification_aamva",
"next-step-name": "aamva_retry",
"name-first": "Jane",
"name-middle": "Marie",
"...": "...",
"fields": {
"name-first": {
"type": "string",
"value": "Jane"
},
"name-middle": {
"type": "string",
"value": "Marie"
},
"...": {
"type": "...",
"value": "..."
},
},
},
"relationships": {
"account": {
"data": {
"type": "account",
"id": "act_ABC123"
}
},
"template": {
"data": null
},
"inquiry-template": {
"data": {
"type": "inquiry-template",
"id": "itmpl_ABC123"
}
},
"inquiry-template-version": {
"data": {
"type": "inquiry-template-version",
"id": "itmplv_ABC123"
}
},
"transaction": {
"data": null
},
"reviewer": {
"data": {
"type": "workflow-run",
"id": "wfr_ABC123"
}
},
"reports": {
"data": []
},
"verifications": {
"data": [
{
"type": "verification/aamva",
"id": "ver_ABC123"
}
]
},
"sessions": {
"data": [
{
"type": "inquiry-session",
"id": "iqse_ABC123"
},
{
"type": "inquiry-session",
"id": "iqse_ABC123"
}
]
},
"documents": {
"data": []
},
"selfies": {
"data": []
}
}
},
"included": [
{
"type": "verification/aamva",
"id": "ver_ABC123",
"attributes": {
"status": "passed",
"created-at": "2025-05-05T17:56:14.000Z",
"created-at-ts": 1746467774,
"submitted-at": "2025-05-05T17:56:14.000Z",
"submitted-at-ts": 1746467774,
"completed-at": "2025-05-05T17:56:14.000Z",
"completed-at-ts": 1746467774,
"country-code": null,
"name-first": "Jane",
"...": "...",
"checks": [
{
"name": "aamva_address_comparison",
"status": "passed",
"reasons": [],
"requirement": "not_required",
"metadata": {
"match-result": null
}
},
{
"name": "aamva_birthdate_comparison",
"status": "passed",
"reasons": [],
"requirement": "required",
"metadata": {
"match-result": null
}
},
{
"...": "..."
}
},
],
},
"relationships": {
"inquiry": {
"data": {
"type": "inquiry",
"id": "inq_ABC123"
}
},
"template": {
"data": null
},
"inquiry-template-version": {
"data": {
"type": "inquiry-template-version",
"id": "itmplv_ABC123"
}
},
"inquiry-template": {
"data": {
"type": "inquiry-template",
"id": "itmpl_ABC123"
}
},
"verification-template": {
"data": {
"type": "verification-template/aamva",
"id": "vtmpl_ABC123"
}
},
"verification-template-version": {
"data": {
"type": "verification-template-version/aamva",
"id": "vtmplv_ABC123"
}
},
"transaction": {
"data": null
}
}
},
{
"type": "inquiry-session",
"id": "iqse_ABC123",
"attributes": {
"status": "expired",
"...": "...",
},
"relationships": {
"inquiry": {
"data": {
"type": "inquiry",
"id": "inq_ABC123"
}
},
"device": {
"data": {
"type": "device",
"id": "dev_ABC123"
}
},
"network": {
"data": {
"type": "network",
"id": "net_ABC123"
}
}
}
},
{
"type": "inquiry-session",
"id": "iqse_ABC123",
"attributes": {
"status": "expired",
"...": "...",
},
"relationships": {
"inquiry": {
"data": {
"type": "inquiry",
"id": "inq_ABC123"
}
},
"device": {
"data": {
"type": "device",
"id": "dev_ABC123"
}
},
"network": {
"data": {
"type": "network",
"id": "net_ABC123"
}
}
}
},
{
"type": "inquiry-template",
"id": "itmpl_ABC123",
"attributes": {
"status": "active",
"name": "AAMVA",
"embedded-flow-domain-allowlist": [],
"hosted-flow-subdomains": [],
"hosted-flow-redirect-uri-schemes": []
},
"relationships": {
"latest-published-version": {
"data": {
"type": "inquiry-template-version",
"id": "itmplv_ABC123"
}
}
}
}
]
}
attributes
key
attributes
keyThe attributes
key includes all standard fields for a resource, including nested objects such as fields
. By default, Persona returns the full attribute set unless you use Sparse Fieldsets.
Within attributes
, the fields
object contains information defined in the resource’s field schema. In the Persona Dashboard, admins can configure and edit field schemas for certain objects. These schemas define which fields are collected, their labels, accepted formats and if they are required.
When a resource type supports field schemas, the fields
object mirrors the structure and keys defined in that schema. These field keys match what you see in the Dashboard’s schema editor, making it easier to correlate API response with your configured data model.
Even resources without editable field schemas (like Verifications or Reports) include a fields object that exposes structured data relevant to that object, though you can’t modify their schema in the Dashboard.
Learn more about field schemas for each object type in their field editor documentation: Inquiries, Accounts, Transactions, Cases.
relationships
key
relationships
keyThe relationships
key contains the type
and id
of related resources. These serve as lightweight pointers to objects listed in the included
array, which can be fully returned if requested. Each resource has different default relationships, and these may vary depending on your implementation. The core purpose remains consistent: to serve as lightweight pointers. In relationships, you’ll find the type
and id
of each object. To see more details, you can either use the ?included
parameter in your API response or make additional API calls directly to the resource.
Relationships can be:
- One-to-one: The
data
value is a single object withtype
andid
- One-to-many: The
data
value is an array of objects
All relationship keys (like
verifications
ortemplate
) are predefined and match what’s returned in the response schema. These relationships are predefined. You cannot add or modify them.
included
key
included
keyThe included
key contains fully serialized versions of resources related to the primary object. You will see the following:
- Fully serialized related resources
- Relationships explicitly requested via the
include
parameter, see theinclude
page for more. - An empty array if no relationships are included
meta
key
meta
keyThis key contains metadata not tied to the resource model. You’ll commonly see:
- Operation-specific info
- Information that may be pertinent to debugging
- Timestamps