--- title: "List all Share Tokens" method: GET path: "/connect/share-tokens" tags: ["connect"] --- # List all Share Tokens `GET /connect/share-tokens` ## Request - Base URL: `https://api.withpersona.com/api/v1` - URL: `https://api.withpersona.com/api/v1/connect/share-tokens` - Auth: HTTP bearer Returns a list of your organization's Share Tokens. Results are returned in reverse chronological order, with the most recently created objects first. ## Query parameters - `page` ConnectShareTokensGetParametersPage - `after` string: Object ID for pagination cursor - `before` string: Object ID for pagination cursor - `size` number, double: Limit on the number of objects returned - `fields` object - `filter` ConnectShareTokensGetParametersFilter - `connection-id` string: Filter Share Tokens by connect connection ID - `status` string: Filter Share Tokens by status. One of `created`, `pending`, `redeemed`, `expired`, or `failed`. - `direction` string: Filter Share Tokens by direction. Defaults to returning both inbound and outbound. One of `inbound` or `outbound`. ## Headers - `Key-Inflection` 'camel' | 'kebab' | 'snake' - `Idempotency-Key` string - `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 collection of Share Token resources. - ConnectListAllShareTokensResponse200 - `data` ConnectShareToken[], required: An array of Share Tokens - `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 - `links` ConnectShareTokensGetResponsesContentApplicationJsonSchemaLinks, required - `next` string, nullable, required - `prev` string, nullable, required ## 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. - `429`: Your organization’s rate limit has been exceeded. We recommend an exponential backoff on requests. ## Changes - **2026-10-31** `2eddd7dae374`: 1 breaking, 1 info - added `subschema #1, subschema #5, subschema #6, subschema #7` to the `data/items/attributes/source-data` response property `oneOf` list for the response status `200` - removed `subschema #1` from the `data/items/attributes/source-data` response property `oneOf` list for the response status `200` - **2026-10-20** `c0c6b3934979`: 1 breaking - added `subschema #15, subschema #16, subschema #17` to the `data/items/attributes/source-data` response property `oneOf` list for the response status `200` - **2026-10-17** `52bbd6c77e3a`: 1 breaking, 1 info - added `subschema #1, subschema #7, subschema #8, subschema #9` to the `data/items/attributes/source-data` response property `oneOf` list for the response status `200` - removed `subschema #1` from the `data/items/attributes/source-data` response property `oneOf` list for the response status `200` [Operation history](https://skmtc.dev/withpersona/apis/withpersona-4/changes/connect/share-tokens/get.md) --- [API](https://skmtc.dev/withpersona/apis/withpersona-4.md) - [All operations](https://skmtc.dev/withpersona/apis/withpersona-4/llms.txt) - [OpenAPI document](https://skmtc.dev/withpersona/apis/withpersona-4/revisions/2eddd7dae374?raw)