Start

Before you send real data

Everything in these docs works exactly as written. Three things are true of a pilot or beta environment specifically, and we would rather you heard them from us than discovered them.

1. Send synthetic or scrubbed events

Payloads are stored in the clear today, and an event that has been sealed cannot be erased. Payload encryption and the key-destruction erasure path are built but not yet shipped. Until they are, treat anything you send as permanent and readable by anyone who can reach the box.

Nothing about your integration changes because of this. The API, the fields, the receipts and the verification are identical whether the payload is real or invented. It is purely a question of what you put inside it.

What to do instead, in the order that costs you least:

Keep the shape, change the content. Same field names, same volumes, same patterns, with invented identifiers. The mapping and sizing work you do stays valid for production.
Scrub before you send, not after. There is no after. A sealed event is sealed.
Hash instead of sending, where you only need to prove sameness. A hash of a customer reference proves two events concern the same customer without carrying who they are.

The one that catches people. Production log lines are usually copied into a pilot to make the test realistic. That is exactly the move to avoid. Generate events of the same shape instead.

2. Pilot signatures are pilot signatures

A development shard signs with a development key. Every mechanism is real and fully verifiable today: the chain, the signature, the published head, the anchor, and the tamper failure all behave as they will in production.

What differs is whose key stands behind it. Production signing keys are generated separately, once, and evidence sealed from then on is the evidence anyone would rely on in a dispute. So use a pilot to satisfy yourself the system does what it says. Do not use one to accumulate evidence you intend to produce later.

3. Anchoring is deliberately not instant

A head waits before it is offered to the OpenTimestamps calendars, then waits for Bitcoin to confirm. A receipt fetched minutes after sealing correctly reports that its anchor has not landed, and reports otherwise later with no action from you.

That wait is what makes the time bound worth anything: it is established by a network that has never heard of either of us. If you are demonstrating this to someone, seal your example the day before rather than during the meeting. More in verify a receipt.

When these stop applying

The first two are properties of pilot and beta environments, not of the product. When you move to a production box with production keys, and once payload encryption ships, both fall away. The third is permanent and by design.

Ask us where a particular box stands before you put anything real in it: info@entrail.io. It is a one-line answer and worth having in writing.