TattooBookingDevelopers

Versioning

The API is on /v1/. We follow an additive-only versioning policy — your integration keeps working as we evolve the platform.

What's safe (no version bump)

  • Adding new endpoints
  • Adding new optional request fields
  • Adding new response fields (your code should ignore unknown fields)
  • Adding new event types
  • Adding new enum values (your code should default-case unknown values)
  • Adding new query-string filters
  • Looser validation (accepting requests that previously 400'd)

What's breaking (would require a v2)

  • Removing or renaming fields
  • Removing or renaming endpoints
  • Changing field types (e.g., string → integer)
  • Tighter validation that rejects previously-valid requests
  • Removing event types

Deprecation timeline

If we ever need to make a breaking change:

  1. Announce it via the changelog + email to everyone using the affected endpoint.
  2. Mark it deprecated in the OpenAPI spec — the field/endpoint includes"deprecated": true.
  3. Add a Sunset response header with the removal date.
  4. Run both old and new behavior in parallel for at least 6 months.
  5. Email reminders at 90, 30, 7, and 1 day before sunset.
  6. Only then remove.

SDK versioning

The @tattoobooking/sdk package follows semver. We bump:

  • Patch on bug fixes
  • Minor when we add new resources/endpoints/fields
  • Major only on breaking SDK API changes (rare — usually we deprecate, ship the new method in a minor, and remove in the next major)

How to stay informed

  • Subscribe to the changelog
  • Subscribe to status updates
  • Keep your API keys' contact email up to date — that's where deprecation notices go