How our applications use third-party APIs.

Purpose of API access

Projectix builds applications that connect to third-party platforms on behalf of the businesses that use them. API access exists for one reason: to provide the functionality the customer has asked for.

For MAP Protector, that purpose is monitoring advertised marketplace pricing against the Minimum Advertised Price policies the customer has configured, and presenting the results in a workspace their team can act on. Access is not used for unrelated research, resale or general data collection.

Data we access

The specific fields depend on the platform and on the permissions granted, but the categories are narrow and functional. For marketplace price monitoring, these are typically:

• Product and catalogue information, including marketplace identifiers and titles.
• Advertised pricing information associated with a listing or offer.
• Seller or offer attribution associated with an observed price, where the platform provides it.
• Timestamps and operational metadata needed to sequence and de-duplicate observations.

We do not request scopes or permissions a feature does not need. Where a platform offers a narrower permission that still supports the functionality, we use the narrower one.

How data is used

Data obtained through authorised marketplace integrations is used only for functionality associated with the service, and in accordance with the applicable platform and API policies.

• Comparing observed advertised prices against thresholds the customer has configured.
• Surfacing observations that appear to require compliance review.
• Retaining a history of observations so changes over time are visible.
• Generating alerts and reports for the customer’s own internal workflows.

Projectix does not sell third-party marketplace API data. We do not use one customer’s integration data to provide a service to another customer, and we do not build or sell market datasets from it.

Data minimisation

Minimisation is applied at three points: what we request, what we store and how long we keep it.

• Requests are scoped to the fields a feature uses, not to everything an endpoint can return.
• Where a derived value is sufficient, we store the derived value rather than the full payload.
• Personal data is avoided wherever the function can be delivered without it.

Data storage

Data is stored in managed cloud database and storage services. Environments are separated, and production data is not copied into development environments.

• Encryption in transit is used for all connections.
• Encryption at rest is enabled where the managed platform provides it.
• Application state is not persisted to ephemeral server filesystems.

Access controls

Access to integration data is restricted to the customer’s own workspace and to the Projectix personnel who need it to operate or support the service.

• Application access is role-based and attributable to an individual or named service.
• Administrative access requires multi-factor authentication.
• Access is reviewed when roles or project involvement change.

Security

Integration credentials are held in managed server-side configuration and are never exposed to the browser or committed to source control. Tokens are scoped to the minimum permissions required, and expiry and rotation are honoured where the provider supports them.

Our Security page describes our wider engineering and secure-development practices, including logging, dependency management and incident handling.

Data sharing

We do not sell integration data, and we do not share it for advertising or profiling. Data is disclosed only in these circumstances:

• To the customer whose account the data belongs to, and the users they authorise.
• To service providers that operate parts of our infrastructure — hosting, database, email delivery — acting on our instructions and only as needed to provide the service.
• Where disclosure is required by law, or to establish, exercise or defend legal rights.

Data retention

Integration data is retained while it is needed to provide the service, including the historical record a customer relies on to understand pricing changes over time.

• Retention periods are set per data category rather than applied indefinitely by default.
• Data that no longer supports a function is deleted or aggregated.
• Customers can request deletion of their integration data; we will confirm what has been removed.

Revoking access

Access is always the customer’s to withdraw. You can disconnect an integration from within the application, and you can also revoke authorisation directly from the third-party platform’s own settings.

• Once revoked, we stop requesting data from that platform.
• Stored credentials for the disconnected integration are deleted.
• On request, previously retrieved data associated with that integration is deleted.

Third-party platform requirements

Where a platform imposes requirements on how its API and data may be used — permitted purposes, retention limits, security controls, deletion obligations — those requirements apply in addition to everything on this page, and we design integrations to operate within them.

Amazon SP-API integration is being developed subject to applicable Amazon authorisation, permissions and API policies. Nothing on this page should be read as confirmation that such access has been granted.

Amazon and related marks are trademarks of Amazon.com, Inc. or its affiliates. Projectix is an independent technology company and is not affiliated with or endorsed by Amazon.

Contact

Questions about how a Projectix application handles third-party API data, or requests relating to data deletion or access revocation, can be sent to the Projectix contact form.

If you are reviewing Projectix as a platform or API provider and need detail that is not covered here, we are happy to answer specific questions directly.