Verity Privacy Policy

• This notice covers Pulse Verity developer accounts, APIs, streams, webhooks, connectors and related support. A Verity developer account is separate from a Pulse player account.
• We process account and billing information, credentials, request and security metadata, usage counts and information you provide to operate and protect Verity.
• The developer website uses browser storage for sign-in and referral attribution. Analytics and optional third-party features may process additional technical information when enabled.
• Different records have different retention rules. Credential expiry, key revocation and webhook deletion do not erase every associated record; the market-price archive is separate from personal account records.
• Contact support@thepulse.markets for privacy questions or to exercise applicable rights. This notice does not waive rights provided by law.

Pulse Labs OpCo LLC, a Wyoming limited liability company ("Pulse", "we", "us"), operates Pulse Verity. Our business mailing address is 30 N Gould St, Ste N, Sheridan, WY 82801, United States. Contact support@thepulse.markets and identify your message as a privacy request.

This Privacy Policy describes personal information handled through the Verity developer website and console, developer accounts, market-data APIs, streams, webhooks, software packages, hosted connectors, commercial relationships and related support (the "Service"). It applies to individual developers, people acting for organisations, visitors and others whose information we receive through those activities.

A Verity developer account does not create a Pulse player account or wallet. Pulse consumer games, player accounts, funding and withdrawals are covered by their own privacy notice. A person who uses both products may encounter both notices and shared website or infrastructure services. This notice governs Verity processing; it does not replace an applicable separate notice for another product.

For account administration, billing, service security and our own business records, Pulse determines the purposes and means of processing and acts as controller where that concept applies. If an agreed customer service involves processing personal information on a customer's instructions, the parties' roles and obligations must be addressed in the applicable agreement, including a data-processing agreement where required. Calling an API does not by itself establish that Pulse is a processor for all of the caller's activities.

You provide account details, credentials, settings, billing selections, webhook destinations, connector authorisations, support messages and other information when you use the Service or contact us. If you represent an organisation, you or your organisation may also provide your business role, contact details and contract-related information.

The Service receives technical information from your browser, application or connector, including network address, request path and parameters, protocol and browser information, timing, errors and usage. What we retain depends on the record and feature described below; receiving a request does not mean we store its complete contents in every log.

We receive information from providers involved in a feature you use, such as identity assertions from Google sign-in and customer or subscription status from Stripe. We may also receive information from your organisation, an authorised account administrator, your chosen connector or webhook destination, and people communicating with us about support, security or legal matters.

Public market observations, asset information and public blockchain or pool information are inputs to Verity's market-data services. These records are distinct from developer account records. Public availability does not make information non-personal in every circumstance, and this notice does not determine ownership, licensing or other rights in a data source.

Account records include your email address, optional name, password hash where you use a password, email-verification state and dates, password-reset token hash, expiry and request time where recovery is requested, session-revocation version, plan, account creation and update dates, and the terms version and time recorded when you accept terms. Account records may include interest in a plan, referral attribution, enterprise entitlements and administrative changes.

Passwords are hashed using bcrypt. API-key records hold a cryptographic hash, a display prefix and creation or revocation timestamps. A newly generated API key is returned for you to store; the account record cannot reproduce the original key from its hash. Revoking or replacing a key changes its usability and retains its historical record and associated usage.

Email-verification links contain a random token. The account stores its hash and expiry time; a link is valid for 24 hours. Successful verification clears the verification-token fields. An expired link does not automatically delete the account or all copies of the email.

When you request password recovery, we process the account email and issue a single-use emailed link valid for 60 minutes. The account stores a cryptographic hash of the reset token, its expiry and the request time used to limit repeated emails. A successful reset or password change clears the reset-token hash and expiry and invalidates existing developer-console session tokens. API keys, OAuth connections and Google sign-in are separate and are not revoked by that password update.

Developer sign-in issues a bearer session token with a seven-day validity period. The console keeps it in browser local storage and removes that stored token on sign-out, after a successful password reset or change in that browser, or when the account-loading flow rejects it. Server-side expiry or revocation is separate from deleting stored tokens in other browsers. A key entered or newly displayed in the console's request workbench is held in page memory, rather than deliberately saved as a workbench key in local storage.

When Google sign-in is configured, the sign-in or signup page loads Google's identity feature, which can receive technical information before you choose Google sign-in. If you choose that method, the page sends the resulting credential to our backend for verification with Google. We receive and may retain the verified email, name and stable Google account identifier. An account created through Google can add a developer password using an emailed password link; adding or changing that password does not unlink Google. Google's processing is also described in its own privacy information.

For paid self-service plans, we use Stripe's hosted checkout and billing portal when billing is available. We provide Stripe with your developer email and account identifier, selected plan and related customer or subscription references. Payment details entered on Stripe's hosted page are processed there; our Verity account database does not store the card number entered in that checkout.

We retain Stripe customer and subscription identifiers, billing status, plan entitlements and associated usage to administer access, reconcile subscriptions, handle support and meet applicable accounting or legal obligations. Stripe may process payment, fraud-prevention and other information for its own responsibilities under its privacy terms.

Enterprise arrangements may create contract, billing and administrative audit records. Entitlement-change audits include the affected developer account, the operator or access identity, a contract reference, reason, time and before-and-after values. Internal customer reports can combine account email, acquisition source, plan, billing status, key display prefixes and usage, and may be sent to our operations contact through our email provider.

We count API activity against keys and accounts to provide usage views, apply plan limits, administer billing, manage capacity and investigate misuse. Daily usage records include the key hash, day, request and rejection counts and a count of failures omitted when a request-history limit is reached. Changing keys does not reset the account's usage history.

The customer-visible request-history feature records attributable failed HTTP requests with status 400 or above. Its records contain account and key references, time, method, path without the query string, response status or error code, and latency. It is bounded and may be incomplete. Successful calls are represented in usage counts rather than individual records in that feature.

Infrastructure and diagnostic logs are separate from customer-visible request history. They may contain requested URLs and query parameters, status, timing and error details. Do not put passwords, API keys, confidential business data or unnecessary personal information in URLs, query parameters, asset labels or webhook destinations.

To limit automated signup abuse, we store network IP address, day and signup-attempt count. Shared security controls also use IP addresses and can record an event's route, origin or host, browser or tool user-agent, time, reason and relevant identifier. These controls can refuse a signup, request or connection. If a restriction appears incorrect, contact support for review.

When Cloudflare Turnstile is configured for signup, the browser interacts with its challenge service and our backend sends the challenge response and remote IP address to Cloudflare to verify it. Availability depends on configuration; the existence of the integration is not a promise that it operates on every request.

A connector you choose can send requests to Verity and receive Service output. Hosted MCP tools receive their tool inputs and protocol metadata, such as requested symbols, dates, catalogue filters or a signed print to verify. The market tools do not require your full AI conversation, but we cannot control information a client includes in its requests or information you submit to support. The connector provider's handling of your conversations, credentials and returned data is subject to its own arrangements with you.

For an OAuth connection, we store client registration information, including client ID, display name and registered redirect addresses. Authorisation and token records associate a client with a developer account and API-key hash and include scope, security challenge or token hashes, validity times and use or revocation information. The currently supported read scope permits market-data calls against the account's allowance; it does not grant account or billing management access.

Authorisation codes are valid for ten minutes, access tokens for one hour and refresh tokens for 30 days. Refreshing rotates tokens. The stored authorisation record is scheduled for expiry one hour after its code expires; token records are scheduled for expiry one day after refresh expiry. Those are storage controls, not guarantees of exact deletion times. Registered client records have no automatic expiry. A hosted MCP request uses a transport that is closed after the response, while account, token, usage and security records remain subject to their separate retention rules.

Your applications may be used by other people. The market-data endpoints do not need their names, contact details, financial account data or other unrelated personal information. Please minimise what your integration sends. If someone connects directly, uses an embedded feature or is described in a support request, we may receive their network or other information. You are responsible for providing appropriate notices and a lawful basis for information you disclose to us; applicable obligations of Pulse still apply.

If you configure data webhooks, we retain the account-linked destination URL, event and symbol filters, endpoint status, signing-key identifier and version, and delivery-management information. A destination URL may include a query string retained internally even when the console displays only its origin and path. Use a destination you control and avoid embedding unnecessary personal information or credentials in it.

Delivery records include the market-data payload, destination reference, event identifier, attempts, status, timing and bounded HTTP status or error codes. The delivery-history field is not intended to retain the destination's response body. We send signed market-data events to your selected destination, whose operator can receive and retain them under your arrangements.

Data-webhook signing secrets are derived from a configured signing key and endpoint identifiers and are shown at creation or rotation. They are not stored as plaintext in the data-webhook endpoint record. Other operational secrets, including certain partner or billing-webhook secrets, have different storage requirements; the Service does not treat all secrets as recoverable in the same way.

Deleting an endpoint stops further work through the deletion process, which must resolve outstanding delivery work. It does not immediately erase terminal delivery history. Optional partner demo rounds retain the creating key reference, asset, duration, price observations, outcome and delivery state. These observation rounds do not require a player identity or an entry payment, but their requests can still generate network and security records.

The developer website uses local storage for the developer sign-in token and for first-visit referral attribution. Referral information can include a referral or campaign tag, medium, external referring hostname and landing path. It helps us understand which publications or links bring developers to the Service. It is saved when present and sent with email-and-password signup; direct visits with no usable attribution need not create a referral record. That browser attribution record has no automatic expiry and can remain after sign-out until browser storage is cleared.

The password-reset page captures the link's credential from its URL fragment and removes the fragment parameters before application analytics and referral capture. The recovery credential and active password-form values are held in page memory rather than saved by that feature in local storage, and the application clears them when leaving the recovery flow. Password show/hide controls change the local field display and do not add a separate tracking or storage feature. These controls do not erase the emailed link or guarantee that other software or providers never receive a copy.

When configured, the shared website analytics integration uses PostHog to measure visits and selected events and to understand reliability and usability. The developer page can generate an arrival event. The integration uses local storage and is configured with automatic interaction capture and session replay disabled. Analytics providers also receive technical information associated with communications to their service. We do not describe these records as anonymous merely because they lack a name.

The analytics initialisation checks browser Global Privacy Control and Do Not Track signals and skips initialisation when either is enabled. This analytics check does not erase existing data, remove necessary sign-in storage or automatically disable the separate referral-attribution feature. You can remove site storage through your browser; doing so can sign you out. Where applicable law requires consent for nonessential storage or access, that requirement applies separately from this notice and from acceptance of Service terms.

When enabled, backend error reporting uses Sentry. Its configuration disables default personal-information collection and performance tracing, removes request bodies, cookies, certain headers, breadcrumb data and stack-frame local variables, and masks email-shaped text. Some diagnostic URLs, selected headers such as user-agent or referrer, stack information and error details can remain. This filtering is not a promise that an error report can never contain personal information.

Optional sign-in, challenge, payment and connector providers may use their own cookies, browser storage or other technologies when you interact with them. Verity's developer session uses a bearer token rather than a dedicated developer-session cookie. That distinction does not mean the whole website or every third-party feature is cookie-free.

We use the information described above to create, authenticate and recover accounts; issue and manage access; deliver requested data and integrations; administer subscriptions, entitlements and usage; provide support and service communications; investigate faults and abuse; understand acquisition and product use; maintain commercial records; and meet legal obligations or establish and defend legal claims.

Where the EU or UK GDPR applies, we rely on contractual necessity under Article 6(1)(b) for processing objectively needed to enter into or perform a contract with an individual, including that individual's account, requested service and billing. That basis does not automatically cover an employee or other contact where the contract is with their organisation. For those business contacts, our basis is normally Article 6(1)(f), the legitimate interests of administering the organisation's relationship with us and providing its requested service.

Our other legitimate interests under Article 6(1)(f) include securing systems, preventing abuse, investigating errors, managing service capacity, responding to enquiries, understanding business acquisition and use, and protecting legal rights. We must weigh those interests against affected individuals' rights and expectations; calling an activity useful to the business does not make all processing necessary or lawful. You may object as explained below.

Article 6(1)(c) applies where processing is necessary to meet an applicable legal obligation. Processing that depends on consent under Article 6(1)(a), or on separate storage/access or marketing consent rules, must not begin without valid consent. Providing this notice does not obtain that consent or establish that an exception applies. The browser controls actually present are described in section 8. Withdrawing consent does not affect the lawfulness of earlier processing and does not prevent processing supported by a different applicable basis.

Some information is needed to authenticate, bill or deliver the feature you request. If you do not provide it, that feature may be unavailable. Optional account details and marketing choices are not prerequisites unless clearly identified as necessary for the requested service. Accepting Service terms or reading this notice is not blanket consent to unrelated processing.

People authorised to operate, support, secure or administer Pulse may access relevant information for those responsibilities. We use infrastructure, database, communications and diagnostic providers to run the Service. The deployed architecture uses Railway for backend hosting, Vercel for the website and MongoDB Atlas for database hosting. Providers receive the information needed for the functions they supply, including technical records created by their infrastructure.

Feature-dependent recipients include Stripe for billing; Postmark for account verification and recovery emails and operational customer reports; Google for Google sign-in; Cloudflare for Turnstile challenges; PostHog for website analytics; and Sentry for backend error reporting. A provider listed here may be inactive for a feature, account or deployment. Its inclusion does not assert that every user is connected to it or that every integration is currently enabled.

We disclose information or outputs to a connector, webhook destination or other integration at your direction, and to authorised representatives of the organisation that administers your commercial account where appropriate. Providers may act under instructions for some processing and independently for other responsibilities, including payments, security and their own account services. Their own notices apply to that independent processing.

We may disclose relevant information to professional advisers and to authorities or other parties when reasonably necessary to comply with law or valid legal process, investigate unlawful activity, protect people or systems, or exercise or defend rights. A corporate transaction may require limited disclosure to prospective or actual counterparties and advisers, subject to applicable confidentiality and privacy requirements. This does not permit unrestricted use for unrelated purposes.

Our operating policy is not to sell personal information or disclose it for cross-context behavioural advertising. We use the analytics described here for service and business measurement, not to offer advertising audiences for sale. Applicable rights to opt out of sale, sharing or targeted advertising remain available and cannot be waived by this notice. If a proposed practice changes, we must provide the legally required notice and choices before carrying it out.

We retain personal information according to its purpose, the account or contractual relationship, support and security needs, applicable recordkeeping duties, disputes and legal claims. Data sensitivity, the risk of retaining it, available alternatives and any legal hold affect that assessment. We do not apply one retention period to every category.

Current application storage controls define three days for daily signup-IP throttle records, 30 days for customer failed-request history and security-event records, and 30 days for optional partner demo rounds. Terminal data-webhook delivery records are scheduled to expire seven days after they reach a completed or dead state; pending work has no equivalent automatic expiry while it remains pending. OAuth record expiry is described in section 6.

A password-reset link's 60-minute validity is not a record-deletion schedule. Unused or expired reset-token hash and expiry fields can remain until replaced or cleared by a successful password reset or change. The reset-request timestamp remains for abuse controls after token consumption and has no automatic expiry in the account schema. Retention of these records remains subject to the criteria in this section, and consuming or expiring a link does not delete copies in email or provider systems.

These periods describe application expiry settings for particular database records, not a guarantee of erasure at an exact instant. Database deletion runs asynchronously and depends on the configured indexes operating. An incident record preserved for a necessary investigation or legal obligation, a provider's own log, an email, an export and a backup can have a different lifecycle. We must handle any retained personal information consistently with applicable law.

Account details, billing and commercial records, daily usage aggregates, attribution, registered OAuth clients and enterprise entitlement audits do not currently have automatic expiry merely because you stop using the Service. Enterprise entitlement audits are maintained as durable commercial evidence. Any retention of these records must remain justified by the criteria above; absence of an automatic expiry is not a claim of an unlimited legal right to keep personal information.

You can revoke API keys and delete webhook endpoints through available controls, clear browser storage locally, and request account closure or personal-information deletion by contacting us. Those actions have different effects: key revocation does not delete usage, endpoint deletion does not instantly delete delivery history, and clearing your browser does not erase server records. Account closure and erasure require review of associated records and lawful exceptions; they are not represented as an immediate, universal self-service purge.

Where an applicable erasure request is granted, necessary retained records may remain restricted to their justified purpose. Copies in backups and provider systems must be considered as part of the request; this notice does not promise a particular backup-erasure schedule or that a database expiry setting deletes every copy. We will explain a refusal or limitation and available recourse where required by law.

Verity's TAPE archive preserves signed market observations and evidence needed to verify them. Its market records contain fields such as asset, price, observation time, grade, signature, signing-key identifier and contributor evidence. The market archive has no automatic expiry and is designed as a lasting market record. Its ordinary print format does not contain developer names, developer account IDs, billing details or customer API-key hashes.

That market archive is separate from personal account, usage and security records. A personal-information deletion request does not ordinarily require deleting unrelated market observations. Conversely, describing a collection as an archive does not exempt personal information from applicable law: if a record contains information that relates to you, we will assess it and any applicable exception on its merits. Customer rights to cache or retain market data are addressed in Service terms and plans, not granted by this privacy notice.

Pulse is based in the United States. Your information may be processed in the United States or other countries where our providers or authorised personnel operate. Laws and government-access rules in those locations can differ from those where you live. This notice does not promise storage exclusively in your country or in a particular cloud region.

Where applicable law restricts a transfer, the transfer must have a valid legal basis and any safeguards the law requires. Depending on the actual recipient and arrangement, these may include an applicable adequacy decision, properly executed standard contractual clauses and any necessary additional measures, or another lawful mechanism. Naming a possible mechanism does not mean that a particular recipient has signed clauses or participates in a certification framework.

Contact support@thepulse.markets for information about the safeguards applicable to a relevant transfer and, where entitled, a copy or explanation subject to legitimate redactions. Any consent requested for a specific exceptional transfer must be distinct from general acceptance of this notice.

The Service uses authentication, credential hashing where appropriate, scoped access, key revocation, usage limits and logging to protect accounts and investigate incidents. Public endpoints and webhook delivery use HTTPS. These measures reduce risk; no network, storage system or control can guarantee that unauthorised access, loss or misuse will never occur.

Protect your email account, password, browser session and API or connector credentials. Limit who can access your application configuration and webhook destinations. Avoid sending sensitive information in URLs or unnecessary personal information in support messages. We will not ask you to email us your password or complete API key as proof of identity.

Report suspected unauthorised access to support@thepulse.markets. We will assess reports and meet applicable incident-notification obligations. This notice is not a representation of a particular security certification, audit result or insurance coverage.

Account verification and recovery, service, security and billing messages may be needed to administer the Service. A marketing preference does not necessarily stop those operational messages. If we send promotional messages, you may object or withdraw consent where applicable by using an available unsubscribe method or contacting us. We must honour applicable direct-marketing objections.

You may decline optional identity providers or integrations, use browser controls to restrict or clear site storage, and enable supported privacy signals. Blocking storage or provider services may prevent a requested feature from working. Browser choices apply to that browser and do not automatically remove records already held by Pulse or another provider.

Questions about access restrictions, unexpected analytics or storage behavior, an incorrect account record or a connector you no longer use can be sent to support@thepulse.markets. Do not send a password or full API key. We may ask for proportionate information to identify the account and protect it from unauthorised changes.

Depending on the law that applies, you may request access to and a copy of personal information, correction, deletion, restriction, portability, or information about its sources, purposes and recipients. You may be able to object to legitimate-interest processing, withdraw consent, and exercise protections relating to automated decisions. Exceptions, identity checks and the scope of each right differ by law.

For EU and UK GDPR requests, we normally respond within one month. Where the law permits additional time because of complexity or the number of requests, we may extend by up to two further months and explain that within the initial period. Any permitted adjustment for necessary identity verification or clarification follows applicable law. You may complain to your competent supervisory authority, including in your habitual residence, workplace or where an alleged infringement occurred; UK residents may contact the Information Commissioner's Office.

To object, explain the relevant processing and, when the law requires, your situation. Objection to direct marketing does not require that explanation. Portability applies only in its legally defined circumstances. Rate limits or fraud controls do not remove any right to challenge an applicable significant automated decision or seek human review.

Email support@thepulse.markets or write to the mailing address in section 1. State the right you wish to exercise and enough information to locate relevant records. We use proportionate verification and may require evidence of an agent's authority; we do not require a new account solely to submit a request. We may withhold another person's information, protect privileged or confidential information, and retain records where law permits or requires, while providing reasons and recourse where required.

If another organisation controls the information you supplied through its application, it may need to handle the request. We will assess our role rather than assuming that all integration data belongs to that organisation. If your jurisdiction provides a right to appeal a refusal, contact us using the same privacy address and identify the appeal; applicable deadlines and regulator remedies remain available.

Where the California Consumer Privacy Act, as amended, applies to our processing, the categories described in this notice include identifiers and contact details; customer and commercial records such as plans, billing references and usage; internet or network activity; professional details you provide; correspondence; and limited inferences such as referral source and usage or plan-interest signals. Account login information can be sensitive personal information under that law. The sources, purposes, recipients and retention criteria for each category are described in sections 2 through 11.

Subject to the Act, you may request disclosure of categories and specific pieces of personal information, correction or deletion; opt out of sale or sharing for cross-context behavioural advertising; and limit certain uses of sensitive personal information. Our operating policy prohibits sale and cross-context advertising disclosure. We use account login information to provide and protect access, not to infer personal characteristics for advertising. These statements do not remove an applicable opt-out or limitation right.

Submit a request through support@thepulse.markets or the mailing address in section 1. Where required, we acknowledge requests to know, correct or delete within ten business days and respond within 45 calendar days; a permitted extension of up to 45 additional days requires notice and an explanation. Applicable sale or sharing opt-outs are handled within the legally required period, generally no later than 15 business days. Recognised opt-out preference signals must be honoured where the law requires them; the website's current analytics-specific handling of Global Privacy Control is explained in section 8.

We may verify a request to access, correct or delete information and require appropriate authorisation from an agent. Opt-out requests are not subject to the same identity-verification requirement. We will not discriminate against you for exercising protected rights. A denial must respect applicable exceptions and notice requirements; contact us if you believe it is incorrect.

Verity developer accounts and commercial services are intended for adults aged 18 or older. We do not knowingly solicit personal information from children through developer signup. If you believe a child provided information, contact us so we can investigate and take the steps required by applicable law.

The market-data features do not require health information, government identification documents, precise location, biometric information or unrelated financial account records. Do not submit such information unless a specific lawful process requires it and we give appropriate instructions. Information submitted unexpectedly remains subject to applicable privacy obligations.

We may update this notice to reflect changes to the Service, processing or law. The version and effective date identify the document. Material changes will be communicated through the Service or another appropriate method as required by law, and we will seek a separate choice or consent when required before a new use begins.

This notice explains processing; it is not a request to waive privacy rights, a release of claims, or consent to every possible future use. Service terms do not override mandatory privacy protections, regulator powers or applicable complaint and court remedies. If you need an accessible copy or assistance understanding or exercising a right, contact support@thepulse.markets.