Record the facts. Get the dates.

Create keys in the dashboard. A key is shown once and stored only as a SHA-256 digest, so a lost key is replaced rather than recovered.

Authorization: Bearer rf_live_XXXXXXXXXXXXXXXXXXXXXXXX

• POST/api/v1/cases

  Open a case when a contract is concluded.

  Goods require a delivery date; the request is refused without one rather than falling back to the order date, which would shorten the period.

• GET/api/v1/cases/{externalId}

  The case, its period, its deadlines and its full history.

  Never cached: whether the period is still open changes at midnight without anything being written.

• POST/api/v1/cases/{externalId}/events

  Move the case on — declare, return, refund, refuse.

  One endpoint for every transition, because the legal object is the transition: what happened, when, and on whose say-so.

• POST/api/v1/cases/{externalId}/confirmations

  Issue a durable-medium document.

  Returns the PDF base64-encoded with its SHA-256, so you can attach it to an email in the same request.

• GET/api/v1/confirmations/{id}

  Download an issued document.

  The stored bytes are re-checked against the stored digest before being served.

# Open a case when the contract is concluded
curl -X POST https://revokeflow.altixcode.com/api/v1/cases \
  -H "Authorization: Bearer rf_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "externalId": "ORD-10024",
    "kind": "GOODS",
    "consumerEmail": "consumer@example.com",
    "description": "Wollteppich 200x300",
    "amount": "249.00",
    "currency": "EUR",
    "deliveryPaid": "9.90",
    "concludedAt": "2026-03-01T10:00:00Z",
    "deliveredAt": "2026-03-09T14:30:00Z"
  }'

# Record that the consumer withdrew
curl -X POST https://revokeflow.altixcode.com/api/v1/cases/ORD-10024/events \
  -H "Authorization: Bearer rf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"event":"DECLARE"}'

# Refund, once you have paid it back
curl -X POST https://revokeflow.altixcode.com/api/v1/cases/ORD-10024/events \
  -H "Authorization: Bearer rf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"event":"REFUND","refundAmount":"258.90","meta":{"ref":"pi_3Abc"}}'

Every case comes back with a portalUrl. Put it in the order confirmation email: Directive (EU) 2023/2673 requires a withdrawal function the consumer can actually operate, and an address to write to is not one.

The link carries a capability token. Order references are guessable by design — knowing ORD-10024 tells you ORD-10025exists — so without a secret anyone could read a stranger’s contract or declare withdrawal on it. Treat the link like a password: it goes to the consumer, and nowhere else.

"portalUrl": "https://revokeflow.altixcode.com/w/your-org/ORD-10024?t=W1c…"

This is the first thing customers ask, so the answer is in the response. An Article 16 exemption is claimed by asserting each of its conditions by index. If any is missing, nothing is written — the case stays as it was — and the response names what was not confirmed.

POST /api/v1/cases/ORD-10024/events
{
  "event": "REFUSE",
  "exemption": {
    "code": "DIGITAL_CONTENT_PERFORMED",
    "satisfied": [0, 3],
    "evidence": "Consent recorded at checkout, log id 8812"
  }
}

422 Unprocessable Entity
{
  "error": {
    "code": "exemption_not_established",
    "message": "Art. 16(1)(m) requires every condition to be met. 2 were
      not confirmed. Claiming it for any digital purchase. All four
      conditions must be met, and the acknowledgement must be a
      separate, recorded act — not a line in the terms.",
    "details": {
      "missing": [
        "The consumer acknowledged that they thereby lose the right of
          withdrawal",
        "The trader provided confirmation of that consent on a durable
          medium"
      ],
      "article": "Art. 16(1)(m)"
    }
  }
}

This is deliberate. A refusal recorded on an incomplete claim would be worse than no record at all: it would launder a bad decision through something that looks like a compliance tool, and it would fall apart the moment it was examined.

Three kinds: the Annex I.B model withdrawal form reproduced verbatim, an acknowledgement that a withdrawal was received (Art. 11(2)), and a confirmation that the refund was made. Each is rendered from the case’s own facts, so the document and the record cannot disagree about a date.

Each is hashed at the moment of issue and the SHA-256 recorded. A document cannot contain its own hash — printing it would change the bytes being hashed — so it carries the reference and issue instant that address the register entry, and says so in plain words. Render the same facts twice and you get identical bytes, which is what makes a mismatch mean something.

POST /api/v1/cases/ORD-10024/confirmations
{"kind": "RECEIPT", "locale": "de"}

201 Created
{
  "confirmation": {
    "id": "clx…",
    "kind": "RECEIPT",
    "digest": "9f2c4a…",       // SHA-256 of the bytes below
    "bytes": 24518,
    "pdfBase64": "JVBERi0xLjcK…",
    "downloadUrl": "https://revokeflow.altixcode.com/api/v1/confirmations/clx…"
  }
}