Data and privacy

Who answers for data once it leaves Hatcel

What personal information the API moves, who is responsible for it at each step, and what to do when something goes wrong. It adds to Hatcel's main Privacy policy and is part of the API terms.

Status

Draft - under legal review. This document has not yet been reviewed by a lawyer and may change before it takes effect.

Last updated 8 October 2026.

Agreeing to these terms

By creating an API key, or by accessing or using the Hatcel API or its documentation in any way, you - and the venue or workspace you act for - agree to all of the following: the API terms, the Acceptable use policy, the Data and privacy terms, and Hatcel's main Terms of service and Privacy policy. If you do not agree, do not create a key and do not use the API.

If you act for a venue, you confirm you are authorised to bind it. Every person, contractor, integration and AI agent that uses one of your venue's keys is bound by these documents through your venue.

These documents can change, as the API terms set out. Continuing to use the API after a change takes effect means you accept the change.

What the API returns

Objects	Personal information
Customers	Names, email, phone, date of birth (juniors' included), postal address, company, marketing consent, membership, tags and lists
Bookings, orders, tickets and gift cards	What a customer booked or bought, when, and what they paid or still owe
Venues, activities, packages and events	Your venue's own details, usually no personal information

Card numbers are never held by Hatcel and never returned.

Who is responsible

Inside Hatcel, your venue holds its customers' personal information and Hatcel handles it on your venue's behalf to run the platform, as the main Privacy policy says.

When a key reads that information, your venue is choosing to use it or pass it on. From then on, wherever it goes - a spreadsheet, a CRM, an email tool, an AI agent - your venue is responsible for it under the Privacy Act 1988 and the Australian Privacy Principles, as it is for anything else it holds. Hatcel does not control, and is not responsible for, a copy that has left Hatcel.

Take and use only what your purpose needs (APP 3 and APP 6).
Say in your own privacy policy what kinds of tools and providers receive your customers' information (APP 1 and APP 5).
Protect it with reasonable security, and delete or de-identify it when it is no longer needed (APP 11).
Keep it accurate: correct a record in Hatcel rather than keeping two versions (APP 10 and APP 13).

Some small businesses are exempt from the Privacy Act. Hatcel asks every venue to meet these standards for API data whatever its size.

How Hatcel protects API data

A key reaches only its own workspace, every request runs under the database's row-level security, keys are stored only as a fingerprint, and every change a key makes is kept and can be undone. Security sets out each safeguard.

Tools outside Australia

Many integrations and AI providers hold data outside Australia. Sending customers' personal information to one is a disclosure overseas under APP 8: before you do it, take reasonable steps to make sure the provider will handle it as the Australian Privacy Principles require - usually through its contract and data processing terms. Your venue can be accountable for what an overseas provider does with it.

When something goes wrong

If a key is exposed, or data taken out through the API is lost, stolen or seen by someone who should not have it, revoke the key and tell Hatcel within 24 hours at nigel@hatcel.com: what happened, which keys, and what data.
A breach of data your venue holds outside Hatcel is your venue's to assess under the Notifiable Data Breaches scheme, within 30 days of suspecting it. If it is likely to cause serious harm, your venue notifies the Office of the Australian Information Commissioner and the people affected as soon as practicable.
If a breach involves data inside Hatcel, Hatcel tells your venue without undue delay and works with you on the assessment. Where both hold the same information, one notification can cover both, and Hatcel and your venue agree who makes it.

What Hatcel records about API use

Every request made with a known key is recorded: the key, the request id, the method, the path, the answer's status and error code, how long it took, the IP address it came from and its user agent. The body, the query string, the headers and the key itself are never recorded.

A path can hold a record's id, such as a customer's, but never a name, an email address or a phone number.

Every change a key makes to a customer, a tag or a list is also kept, with what the record held before and after, so your venue can see and undo it.

Record	Kept for
Reads (GET)	30 days
Changes (POST, PUT, PATCH, DELETE)	365 days
What a change replaced	365 days

Hatcel uses these records to run, secure and support the API, to show your venue what each key did, and to answer your venue's questions about it. They are visible to whoever manages keys in your workspace.

Requests from your customers

A customer who asks to see, correct or delete their information asks your venue. Make the change in Hatcel, and in every system you sent their information to through the API - Hatcel cannot reach those copies.

When a customer withdraws marketing consent anywhere, record it in Hatcel too, so every system honours it.

When access ends

When a key is revoked or your venue's API access ends, nothing more leaves Hatcel through it. Copies your venue already took stay its responsibility: keep them only as long as your purpose and the law need, then delete or de-identify them.

Building and testing

Build against a test key and test data. Test data should never be a real person's information.

Acceptable use