# syntaqx > syntaqx.com is the personal site of Chase Pierce (syntaqx), a software engineering leader. Writing on engineering, systems, and craft, API design docs, and a small public REST API of developer utilities. **When to use this site.** Reach for syntaqx when an agent needs one of these jobs done over plain HTTP, with no API key or account: - Generate identifiers: up to 100 v4 UUIDs per call (`GET https://api.syntaqx.com/v1/uuid?count=N`) or random strings with a chosen length and charset (`GET https://api.syntaqx.com/v1/random`). - Hash text with MD5, SHA-1, SHA-256, SHA-384 or SHA-512 (`POST https://api.syntaqx.com/v1/hash`), or Base64 encode/decode, including URL-safe Base64 (`POST https://api.syntaqx.com/v1/base64`). - Inspect a JWT's header, payload and expiry without verifying its signature (`POST https://api.syntaqx.com/v1/jwt/decode`). - Convert a Unix or ISO 8601 timestamp into Unix seconds, milliseconds, RFC 3339 and RFC 2822 (`GET https://api.syntaqx.com/v1/timestamp?t=...`). - See the caller's public IP or parse a User-Agent string (`GET https://api.syntaqx.com/v1/ip`, `GET https://api.syntaqx.com/v1/useragent`). - Test retry, timeout and circuit-breaker logic against an endpoint that fails on purpose at a chosen rate, status and delay (`GET https://api.syntaqx.com/v1/flaky`). - Look up a concrete REST API convention (naming, pagination, error envelopes, rate-limit headers, time formats, identifiers, versioning) while designing or reviewing an API: see the Docs links below. - Read Chase Pierce's writing on engineering leadership, software architecture and working with LLMs. **How to call it.** Read the OpenAPI document at https://www.syntaqx.com/openapi.json: every operation has an `operationId`, typed parameters and response schemas, so it maps directly to function calling. Send JSON bodies to POST endpoints, and pin a version with the `Api-Version` header (see https://www.syntaqx.com/docs/versioning). Errors come back as `{"message": "..."}` with an HTTP status. Respect the `RateLimit` and `Retry-After` headers (5,000 requests per hour per IP). **When not to use it.** There is no SLA, authentication or storage. Don't send real secrets or production tokens to the hash, Base64 or JWT endpoints, don't rely on JWT decoding for verification, and don't put the API in a critical production path. Every page listed here is also available as Markdown: request it with an `Accept: text/markdown` header. ## API - [API reference](https://www.syntaqx.com/docs/api): interactive reference for the public syntaqx API - [OpenAPI spec](https://www.syntaqx.com/openapi.json): OpenAPI 3.1 document describing every endpoint - [API root](https://api.syntaqx.com): index of endpoint URLs - [Health check](https://api.syntaqx.com/v1/healthz) - [Versioning & deprecation](https://www.syntaqx.com/docs/versioning): Api-Version header versions, breaking-change rules and Deprecation/Sunset headers ## Docs - [The Playbook](https://www.syntaqx.com/docs/playbook): The principles behind every standard here, and a map of the whole playbook: API design, HTTP semantics, payments, architecture, operations and delivery. - [REST & HTTP Verbs](https://www.syntaqx.com/docs/rest-http-verbs): A quick primer on REST architecture and the HTTP methods that drive it: GET, POST, PUT, PATCH, and DELETE, and what each one should actually mean. - [Time & Date Formats](https://www.syntaqx.com/docs/time): Standard formats for representing datetimes, durations, and recurring schedules in the API, so time is unambiguous across clients and time zones. - [Identifier Conventions](https://www.syntaqx.com/docs/identifier-conventions): How to choose and use identifiers (auto-increment, UUID versions, and ULID) and when each one makes sense for keys, URLs, and distributed systems. - [API Design Principles](https://www.syntaqx.com/docs/api-design-principles): The core principles and conventions that guide how the syntaqx API is designed: consistency, predictability, and least surprise for the developer using it. - [Naming Conventions](https://www.syntaqx.com/docs/naming-conventions): Conventions for naming API routes and resources to keep the surface consistent, predictable, and aligned with RESTful expectations. - [Resource Relationships](https://www.syntaqx.com/docs/resource-relationships): Modeling associations between resources: direct endpoints vs. relationship endpoints, association data, and keeping route sets minimal. - [API Authentication](https://www.syntaqx.com/docs/api-authentication): How API callers prove who they are: prefixed API keys, restricted keys, OAuth 2.0 bearer tokens, scopes, and the line between a 401 and a 403. - [Error Responses](https://www.syntaqx.com/docs/error-responses): The standard error response format and the HTTP status codes used across the API, so clients can handle failures consistently and predictably. - [JSON Field Conventions](https://www.syntaqx.com/docs/json-conventions): How fields are named and typed in JSON bodies: snake_case, absent versus null, string enums, boolean prefixes, and safe handling of 64-bit numbers. - [Pagination](https://www.syntaqx.com/docs/pagination): Page-based and cursor-based pagination using the Link header: how to walk large result sets consistently, and when to reach for each approach. - [Filtering & Sorting](https://www.syntaqx.com/docs/filtering-and-sorting): Query parameter conventions for filtering and sorting collections: field filters, range operators, sort=-created_at, allowlists, and when to use QUERY. - [HTTP QUERY](https://www.syntaqx.com/docs/http-query): Supporting RFC 10008's QUERY method today: one query model behind GET, QUERY and a POST fallback, plus caching, CORS, and where the ecosystem still falls short. - [Rate Limiting](https://www.syntaqx.com/docs/rate-limiting): Rate limiting behavior, the headers that describe your current limits, and best practices for gracefully handling 429 responses in your client. - [Versioning & Deprecation](https://www.syntaqx.com/docs/versioning): Header-based, date-named API versions with a URL fallback, what counts as a breaking change, and the Deprecation and Sunset headers that announce removals. - [Retries & Timeouts](https://www.syntaqx.com/docs/retries-and-timeouts): When to retry, how long to wait, and when to give up: timeouts on every call, exponential backoff with jitter, retry budgets, and what is safe to retry. - [Observability](https://www.syntaqx.com/docs/observability): Request IDs on every response, structured logs, trace context across services, and the few metrics that matter, so any failure can be traced end to end. - [SLOs & Error Budgets](https://www.syntaqx.com/docs/slos): Picking SLIs that reflect what users feel, setting SLO targets, spending error budgets deliberately, and alerting on burn rate instead of raw thresholds. - [On-Call & Runbooks](https://www.syntaqx.com/docs/on-call): A sustainable on-call rotation: severity levels, escalation, handoffs, a runbook template for every alert, and budgeting time to drive toil down. - [Configuration & Secrets](https://www.syntaqx.com/docs/configuration): Config in the environment, validated and typed at boot, secrets kept in a manager and never in the repo, and rotation designed in from day one. - [Expanding Responses](https://www.syntaqx.com/docs/expanding-responses): Use the expand parameter to inline related resources within API responses: fewer round-trips, and only the extra data you actually ask for. - [Caching & Conditional Requests](https://www.syntaqx.com/docs/caching): Cache-Control, ETags and conditional requests: cheap revalidation with 304, safe concurrent updates with If-Match and 412, and Vary on Api-Version. - [Long-Running Operations](https://www.syntaqx.com/docs/long-running-operations): Work that outlives a request: 202 Accepted with an operation resource to poll, Retry-After pacing, webhooks on completion, cancellation, and result retention. - [Bulk Operations](https://www.syntaqx.com/docs/bulk-operations): Batch endpoints that create or update many resources in one call: size limits, per-item results, partial failure, idempotency, and when to go async. - [Money & Amounts](https://www.syntaqx.com/docs/money): How monetary amounts are represented: integer minor units, an explicit ISO 4217 currency on every amount, and rounding rules that never lose a cent. - [Idempotency](https://www.syntaqx.com/docs/idempotency): Safe retries for any write with the Idempotency-Key header: how keys are stored and replayed, and what happens on conflicting or concurrent requests. - [Payment States & Ledgers](https://www.syntaqx.com/docs/payment-states): Explicit state machines for financial objects, append-only records, and a double-entry ledger, so every balance can be explained and nothing is ever edited. - [Webhooks](https://www.syntaqx.com/docs/webhooks): Signed, at-least-once webhook delivery: payload shape, signature verification, retry schedule, and how consumers should dedupe and process events. - [Sensitive Data](https://www.syntaqx.com/docs/sensitive-data): Handling card data and PII: keep PCI scope small with tokenization, never log secrets, redact by default, and treat access to sensitive data as an event. - [Service Boundaries](https://www.syntaqx.com/docs/service-boundaries): Where to draw lines in a system: start with a modular monolith, split only for a reason, give every piece of data one owner, and never share a database. - [Events & Async Messaging](https://www.syntaqx.com/docs/events): Publishing and consuming events reliably: the transactional outbox, idempotent consumers, partition keys for ordering, CloudEvents, and schema evolution. - [Multi-Tenancy](https://www.syntaqx.com/docs/multi-tenancy): Serving many customers from one system safely: choosing an isolation model, enforcing tenant scope in the database, and keeping noisy neighbors in check. - [Data Retention & Deletion](https://www.syntaqx.com/docs/data-retention): How long data is kept and how it is removed: soft vs hard delete, retention windows, GDPR erasure next to append-only financial records, and backups. - [Database Naming Conventions](https://www.syntaqx.com/docs/database-naming-conventions): Consistent naming conventions for database tables, columns, keys, and relationships, so schemas stay readable and predictable as they grow. - [Zero-Downtime Migrations](https://www.syntaqx.com/docs/zero-downtime-migrations): Changing a live schema without downtime: the expand and contract pattern, safe backfills, lock-aware DDL, and the order to ship code and migrations in. - [Design Docs & ADRs](https://www.syntaqx.com/docs/design-docs): When a change needs a design doc, what goes in one, and how architecture decision records keep the reasoning behind a system findable years later. - [Commits, PRs & Code Review](https://www.syntaqx.com/docs/commits-and-reviews): Conventional Commits, small squash-merged pull requests with a real description, and code reviews that are fast, labeled, and focused on what matters. - [Testing Strategy](https://www.syntaqx.com/docs/testing): What to test at each level, contract tests between services, deterministic fixtures, real databases over mocks, and a zero-tolerance policy for flaky tests. - [Feature Flags & Progressive Rollout](https://www.syntaqx.com/docs/feature-flags): Separating deploy from release: flag types and lifetimes, OpenFeature for vendor-neutral evaluation, percentage and canary rollouts, kill switches, and cleanup. - [Dependency Management](https://www.syntaqx.com/docs/dependencies): Lockfiles, SemVer, an automated upgrade cadence, vetting new dependencies, and supply-chain safeguards like provenance, SLSA, and SHA-pinned CI actions. - [Incident Postmortems](https://www.syntaqx.com/docs/postmortems): Blameless postmortems: when to write one, the template, how to find contributing factors instead of a culprit, and making sure action items get done. ## Posts - [We Called It Progress](https://www.syntaqx.com/posts/we-called-it-progress): 2026-10-12, We spent decades building software that made other people's jobs cheaper. Now I'm on the job market, watching it happen to us. - [Control Isn't Success](https://www.syntaqx.com/posts/control-isnt-success): 2026-09-08, I turned a dying CRM rebuild into a real platform and shipped a year early. Then I started fixing the problem statements myself, which broke everything else. - [The Thinking Tax](https://www.syntaqx.com/posts/the-thinking-tax): 2026-08-11, I fixed a bug in ten minutes that could've cost me hours, and felt nothing. The understanding never showed up. On what goes missing when the tool thinks first. - [Growing Together in the Age of LLMs](https://www.syntaqx.com/posts/growing-together-in-the-age-of-llms): 2026-05-10, AI made the first version easy. Everything after that (the scaling, the edge cases, the maintenance) still takes real engineering. On growing alongside LLMs. - [The Evolution of Software Engineering in the Age of AI](https://www.syntaqx.com/posts/evolution-of-software-engineering): 2025-02-03, With AI-assisted coding, software engineers are becoming product engineers and architects, leaning into system design, collaboration, and iteration with LLMs. - [GitHub Actions & Secret Inputs](https://www.syntaqx.com/posts/github-actions-secret-inputs): 2024-07-02, An exploration and a working solution for passing secret input values into GitHub Actions manual, self-service workflows, without leaking them in the logs. - [Hello, world, again!](https://www.syntaqx.com/posts/hello-world): 2024-07-01, We're back. Round and round we go. Why I keep rebuilding this blog, why I keep abandoning it, and why this time I'm betting I'll actually stick with writing. ## Optional - [About](https://www.syntaqx.com/about): background on Chase Pierce - [Contact](https://www.syntaqx.com/contact): how to get in touch - [Privacy policy](https://www.syntaqx.com/legal/privacy) - [Terms of service](https://www.syntaqx.com/legal/terms) - [RSS feed](https://www.syntaqx.com/feed.xml) - [GitHub](https://github.com/syntaqx) - [LinkedIn](https://www.linkedin.com/in/syntaqx/) - [Stack Overflow](https://stackoverflow.com/users/1295839/syntaqx) - [X](https://x.com/syntaqx)