The difference

Not a curated subset of someone else’s schema

Farm platforms that offer an API generally expose the objects they designed, in the shape they chose, often behind an application form and a partner agreement.

Alffi has no fixed schema to expose. When you create a record type in the dashboard, it becomes an API resource in the same moment — readable, writable, filterable, and emitting webhooks. Nobody at Alffi decides which of your own data you’re allowed to reach.

Generate a token in settings and start. There is no approval step.

What’s available

Built for real integrations and for mobile clients, which means the unglamorous parts are done properly.

REST API

  • Full entity access Read, create, update and delete records of any type, including your own. Relationships and parentage are addressable too.
  • Token authentication Personal access tokens, exchanged for short-lived credentials. Every request runs under the permissions of its owner — the API cannot reach what its user couldn’t.
  • Cursor pagination Opaque cursors on every list endpoint, so pagination doesn’t break when records change underneath you.
  • A changes feed Ask what has changed since a cursor. This is the primitive a syncing client needs, and it exists because we intend to build one.
  • Idempotency keys on writes Required, not optional. A retry over a flaky connection cannot double-create a record.
  • ETags on detail reads Conditional requests return a not-modified response rather than the payload again.

Webhooks & MCP

  • Signed webhook delivery HMAC-SHA256 signatures in the same shape Stripe and GitHub use, so existing verification code works unchanged.
  • Retries with backoff Failed deliveries retry on an exponential schedule, with a delivery log in the dashboard showing what was sent and what came back.
  • No opt-in code required Events fire off database changes, so a record type you invent this afternoon emits webhooks this afternoon.
  • MCP access The platform is reachable by AI tooling through the Model Context Protocol, against the same permissions and the same data.
  • Push without a push backend A future mobile client can consume the same webhook delivery any third party does. No separate notification infrastructure.
Portable domain logic

The maths lives in packages, not in the app

Geometry, unit conversion, formula evaluation, conditional visibility and the module templates are all separate packages with zero external dependencies. That is a deliberate constraint, not an accident.

It means the calculation that works out a paddock’s area, or converts kilograms per hectare into pounds per acre, is the same code everywhere it runs — server, browser, and eventually a mobile client. Domain logic never gets reimplemented per platform and never drifts between them.

Straight answers

Current limits

If you’re evaluating this for an integration, these are the things you’d find out in week one anyway.

Not there yet

  • Personal access tokens only — no OAuth client credentials flow
  • Rate limit headers are reserved but not enforced
  • Schema is read-only over the API; record types are created in the dashboard, not programmatically
  • No published SDK — it’s plain REST, which we think is fine, but you’re writing the client
  • No sandbox environment separate from your own account

Solid today

  • Every record type, including yours, addressable
  • Permissions enforced in the database, not in application code
  • Signed, retrying webhooks with a delivery log
  • Idempotent writes and stable pagination
  • Self-serve tokens with no approval process

One more thing worth saying plainly: Alffi is an open platform, not open source. The API and your data are open to you. The source is proprietary.

Building something against it?

Design partners get direct access to whoever is writing the API, which at this stage is a short conversation rather than a support ticket.

How the platform works