--- title: "Retrieve a Share Token" method: GET path: "/connect/share-tokens/{share-token-id}" tags: ["connect"] --- # Retrieve a Share Token `GET /connect/share-tokens/{share-token-id}` ## Request - Base URL: `https://api.withpersona.com/api/v1` - URL: `https://api.withpersona.com/api/v1/connect/share-tokens/{share-token-id}` - Auth: HTTP bearer Retrieve the information for an existing Share Token. ## Path parameters - `share-token-id` string, required ## Query parameters - `include` string - `fields` object - `peek-source-data` boolean ## Headers - `Key-Inflection` 'camel' | 'kebab' | 'snake' - `Persona-Version` '2026-09-29' | '2025-12-08' | '2025-10-27' | '2023-01-05' | '2022-09-01' | '2021-08-18' | '2021-07-05' | '2021-02-21' | '2020-05-18': Server API version. More info on versioning can be found [here](https://docs.withpersona.com/versioning). ## Response `200` This endpoint returns a Share Token resource. - ConnectRetrieveAShareTokenResponse200 - `data` ConnectShareToken, required: A Share Token resource. The specific attributes and relationships included may vary based on the requesting organization's context. - `type` 'connect/share-token' - `id` string - `attributes` ConnectShareTokenAttributes - `status` string: The status of the share token. One of `created`, `pending`, `redeemed`, `expired`, or `failed`. - `direction` string: Whether this share token is outbound (your organization is the source) or inbound (your organization is the destination). One of `outbound` or `inbound`. - `created-at` string, date-time: When this share token was created - `updated-at` string, date-time: When this share token was last updated - `pending-at` string, date-time, nullable: When this share token started processing - `redeemed-at` string, date-time, nullable: When this share token was redeemed - `expires-at` string, date-time, nullable: When this share token expires - `failed-at` string, date-time, nullable: When this share token failed - `failure-reason` string, nullable: The reason the share token failed, if applicable. One of `source_not_found`, `source_redacted`, `import_failed`, or `unrecoverable_error`. - `redeem-mode` string, nullable: How this Share Token was redeemed. Set to `hydrate` when `destination-id` is provided or `clone` when `destination-id` is omitted. Null until redemption is initiated. - `source-data` union: A PII-filtered snapshot of a Share Token's source object. `type` discriminates the underlying source-object type and dispatches to the matching per-subclass schema; see each subschema for shape details. - object: PII-filtered snapshot of an Inquiry source object. Carries the inquiry's filtered scalar attributes under `peekable-attributes`, the inquiry's standard and custom user-space fields under `peekable-attributes.fields`, and filtered snapshots of related source objects (verifications, accounts, etc.) inline under `related-objects`. - `type` 'connect/source-data/inquiry', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` SourceDataInquiryPeekableAttributes, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - `fields` object: Nested bag of standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields). Each entry is a `{visibility, value}` wrapper. The set of keys varies by the inquiry template and by the source organization's PII-share configuration; clients should handle unknown keys defensively. - `related-objects` SourceDataRelatedObject[]: Filtered snapshots of source objects related to this inquiry (e.g. attached verifications, the linked account). Each entry is itself a source-data envelope discriminated by its specific subtype. - union - … - object: PII-filtered snapshot of a Database verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows — see `Verification::Database` in the share-token PII filter for the current allowlist. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database TIN verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-tin', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database Business verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-business', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Brand Asset verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/brand-asset', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database VAT Number verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-vat-number', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database Business Footprint verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-business-footprint', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Business Website verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/business-website', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database UK DVLA verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-uk-dvla', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database Standard verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-standard', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Database Phone Carrier verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/database-phone-carrier', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Phone Number Silent Network Authentication verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/phone-number-silent-network-authentication', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Phone Number verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows — see `Verification::PhoneNumber` in the share-token PII filter for the current allowlist. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/phone-number', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of an Email Address verification. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows — see `Verification::EmailAddress` in the share-token PII filter for the current allowlist. Verification subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/verification/email-address', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of an Account source object. Carries the account's filtered scalar attributes under `peekable-attributes`, and the account's standard and custom user-space fields under `peekable-attributes.fields`. - `type` 'connect/source-data/account', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` SourceDataAccountPeekableAttributes, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - `fields` object: Nested bag of standard and custom user-space fields (e.g. `name-first`, `name-last`, org-defined fields). Each entry is a `{visibility, value}` wrapper. The set of keys varies by the account type and by the source organization's PII-share configuration; clients should handle unknown keys defensively. - object: PII-filtered snapshot of a Txn source object. Carries the txn's filtered scalar attributes under `peekable-attributes`, and the txn's standard and custom user-space fields under `peekable-attributes.fields`. - `type` 'connect/source-data/txn', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` SourceDataTxnPeekableAttributes, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - `fields` object: Nested bag of standard and custom user-space fields (e.g. `amount`, org-defined fields). Each entry is a `{visibility, value}` wrapper. The set of keys varies by the txn type and by the source organization's PII-share configuration; clients should handle unknown keys defensively. - object: PII-filtered snapshot of an Adverse Media report. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Report subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/report/adverse-media', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of an Email Address report. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Report subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/report/email-address', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Politically Exposed Person report. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Report subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/report/politically-exposed-person', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Screening report. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Report subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/report/screening', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - object: PII-filtered snapshot of a Watchlist report. The `peekable-attributes` bag carries whichever PII-filtered scalar attributes the source organization's configuration allows. Report subtypes do not expose a nested `fields` sub-bucket. - `type` 'connect/source-data/report/watchlist', required: Discriminator for the source-object type. Subtypes constrain this to a specific value via `const`. - `id` string, required: The underlying source object's token. - `peekable-attributes` object, required: Bag of source-object attributes exposed to the destination organization per the source organization's PII-share configuration. Each scalar entry (e.g. `status`, `country-code`, `id-class`) is a `{visibility, value}` wrapper; see `source-data-peekable-attribute.yaml`. Inquiry, Account, and Txn subtypes additionally expose a nested `fields` sub-bucket containing standard and custom user-space fields (e.g. `name-first`, `birthdate`, org-defined fields); verification subtypes do not. The source object's `status` (when applicable to the subtype) appears here as a peekable attribute, not as a top-level scalar. Entries stripped entirely by the configuration are omitted from the bag. The concrete shape — including which subtypes expose `fields` — is declared per-subtype. - `relationships` ConnectShareTokenRelationships - `connection` ConnectShareTokenRelationshipsConnection - `data` ConnectShareTokenRelationshipsConnectionData - `type` 'connect/connection' - `id` string - `creator` ConnectShareTokenRelationshipsCreator - `data` ConnectShareTokenRelationshipsCreatorData - `type` string - `id` string - `source` ConnectShareTokenRelationshipsSource: The object from which the shared data originated. - `data` ConnectShareTokenRelationshipsSourceData - `type` string - `id` string - `destination` ConnectShareTokenRelationshipsDestination: The destination object associated with redemption. For hydration, this is the object specified by `destination-id`. For cloning, no destination is set until Persona creates the destination object. - `data` ConnectShareTokenRelationshipsDestinationData - `type` string - `id` string - `included` unknown[]: Excluded from the response by default. Will be an empty array when the `include` query parameter in the request was explicitly set to empty. - unknown ## Other responses - `400`: The request was unacceptable, often due to invalid parameters. - `401`: An invalid API key was provided. - `403`: The given API key doesn’t have permissions to perform the request or a quota has been exceeded. - `404`: The requested resource doesn’t exist. - `409`: The request conflicts with another request, often due to attempting to create a duplicate resource. - `429`: Your organization’s rate limit has been exceeded. We recommend an exponential backoff on requests. ## Changes - **2026-10-31** `3683a7f9e1fe`: 1 breaking, 1 info - added `subschema #1, subschema #5, subschema #6, subschema #7` to the `data/attributes/source-data` response property `oneOf` list for the response status `200` - removed `subschema #1` from the `data/attributes/source-data` response property `oneOf` list for the response status `200` - **2026-10-20** `ca4f3ae4a2f0`: 1 breaking - added `subschema #15, subschema #16, subschema #17` to the `data/attributes/source-data` response property `oneOf` list for the response status `200` - **2026-10-17** `dd7a752779e7`: 1 breaking, 1 info - added `subschema #1, subschema #7, subschema #8, subschema #9` to the `data/attributes/source-data` response property `oneOf` list for the response status `200` - removed `subschema #1` from the `data/attributes/source-data` response property `oneOf` list for the response status `200` [Operation history](https://skmtc.dev/withpersona/apis/withpersona-8/changes/connect/share-tokens/:share-token-id/get.md) --- [API](https://skmtc.dev/withpersona/apis/withpersona-8.md) - [All operations](https://skmtc.dev/withpersona/apis/withpersona-8/llms.txt) - [OpenAPI document](https://skmtc.dev/withpersona/apis/withpersona-8/revisions/3683a7f9e1fe?raw)