Skip to content
Security
5 min read

Security overview

How Furcata protects your account, your data and your integrations — and what is up to you.

Share article

This page is a public-level overview of how Furcata protects your account and your data. It describes the controls that are visible to you as a customer, and the responsibilities that sit with you.

  • Traffic to the API and to the app is encrypted in transit over HTTPS.
  • Data is encrypted at rest in Furcata's managed cloud infrastructure.
  • Access to the API is granted through OAuth 2.0 with scopes, not by sharing a password.
  • Inbound integration requests are verified by signature before they are acted on.
  • Two-factor authentication is available on the identity provider you sign in with.

The Furcata API uses OAuth 2.0. A client is registered with the repository, the user approves the access, and the client receives tokens it can refresh. Scopes are declared by the client and granted by the user, so a client can be limited to exactly what it needs.

Two scopes cover the API today:

furcata.read    read access to your account data
furcata.write   write access to act on your account
A client that only needs to read reports should not hold write access.

The authorisation server advertises the scopes it supports, so a client can discover them rather than hard-code assumptions.

  • Treat a token as a password. It grants access to your account until it expires or is revoked.
  • Store tokens in a secret manager or environment configuration, never in source control.
  • Do not put tokens in URLs, in logs, or in error messages.
  • Rotate tokens on a schedule, and immediately if one may have been exposed.
  • Use separate clients for separate integrations, so revoking one does not break the others.

Never share your credentials

Nobody at Furcata will ask you for your password, your token, or a code sent to your phone. A request for any of those is an attempt to gain access to your account.

All communication with the API and the app is over HTTPS. Requests over plain HTTP are not supported. Webhook deliveries from Furcata are sent over HTTPS to the target you register, and a target must be an HTTPS URL.

Inbound requests from integration partners are signed, and Furcata verifies the signature before acting on the payload. A request that cannot be verified is discarded.

Sign-in is handled by established identity providers — Google Sign-in and Apple Sign-in. That means Furcata does not hold your password, and the protections those providers offer, including two-factor authentication, are available to you.

  • Turn on two-factor authentication on the Google or Apple account you use to sign in.
  • Use a strong, unique passcode on the device that holds your Furcata app.
  • Be sceptical of messages and links that ask you to sign in, even if they look like they come from us.
  • Report anything suspicious to support rather than investigating it yourself.

Furcata runs on managed cloud infrastructure, with encryption at rest and in transit, and undergoes regular audits. Payments are processed by Stripe, which means card details are handled by a dedicated payments provider and are not stored by Furcata.

Security is shared. Furcata is responsible for the platform, the encryption, the access controls and the integrity of the data you store with us. You are responsible for who you give access to, how you store your tokens, and how you configure your integrations.

The most common cause of a compromised account is not a flaw in the platform — it is a credential that was shared, reused or committed to a repository. The habits above prevent most of it.

Read the full security statement

The public security page covers infrastructure, app security and our commitments in more detail.

Security at Furcata